This section of the exam accounts for 15-20% and covers Creating and Managing Workspaces and Assets, as well as Securing and Governing Power BI Items. In this blog I'll go over some of the important aspects that stood out to me.
Roles and permissions
To start of something that confused me is that there are workspace roles alongside semantic model permissions. I've included a table below to show the different roles and what permissions each role has:
| Admin | Member | Contributor | Viewer | |
|---|---|---|---|---|
| Read | ✓ | ✓ | ✓ | ✓ |
| Build | ✓ | ✓ | ✓ | × |
| Reshare | ✓ | ✓ | × | × |
| Write | ✓ | ✓ | ✓ | × |
Permission descriptions as seen on Microsoft Learn:
| Permission | Description |
|---|---|
| Read |
Allows users to access and interact with reports and other solutions (such as composite models on Premium/PPU workspaces) that read data from the semantic model.
This includes the ability to use the Explore feature to interact with the data in these semantic models.
|
| Build |
Allows users to:
• Build new content from the semantic model and find content that uses it.
• Access reports that access composite models on Power BI Pro workspaces.
• Build composite models.
• Pull data into Analyze in Excel.
• Query using external APIs such as XMLA.
• See hidden data fields.
|
| Reshare | Allows user to grant semantic model access. |
| Write |
Allows users to:
• Republish the semantic model.
• Backup and restore the semantic model.
• Make changes to the semantic model via XMLA.
• Manually trigger a refresh using Refresh now.
• Edit semantic model settings (except scheduled refresh, credentials, and automatic aggregations).
|
| Owner |
The semantic model owner isn't a permission in itself, but rather a conceptual role that has all the permissions on a semantic model. The first owner is the person who created the model, or the last person to configure it after taking ownership in settings.
In addition to standard permissions, only an owner can configure scheduled refreshes, credentials, and automatic aggregations.
|
Security
RLS
The first form of security is Row level security which allows for filtering which specific rows of data a user can view in the report. You can perform static Row filtering by creating Roles on the the Manage Roles button and creating filters for said Roles. Dax also enables us to perform dynamic row filtering based on a users email.
For example here if we have an email column we can use USERPRINCIPALNAME This will take the email that was used to login to PowerBI service and compare it to the email in our table allowing us to filter to just show rows based on the user and whether their login email matches the email for the row of data.
You can then use the view as role button to test these filters.
SSO
If the semantic model is using DirectQuery you can use single sign-on to use the same row level security from the data source.
OSL
Finally there is Object level security which requires using the preview feature TMDL view which will then appear on the left side under the Dax query view. OSL allows for restricting columns or entire tables from the report and is based on roles like RLS.