Task 4.2: Secure and govern Power BI items

• AAdd her to the Region role a second time with her email address

  Incorrect

  She's already a member; the problem is that her workspace role bypasses RLS.

• BRewrite the role filter for the workspace's reports to use USERNAME() instead of USERPRINCIPALNAME()

  Incorrect

  The function in the filter doesn't matter here, because role filters don't apply to Members.

• CChange her workspace role to Viewer so the Region role's filter applies to her when she reads the reports

  Correct

  RLS restricts only users with Viewer permissions; Members see all data.

• DGive her Build permission on the semantic model

  Incorrect

  Build permission doesn't change how RLS treats a workspace Member.

Row-level security restricts data access only for users with Viewer permissions; it doesn't apply to workspace Admins, Members or Contributors. To enforce RLS for people who browse content, give them the Viewer role, or distribute the content through an app or sharing without a higher workspace role.

• ACreate one role per region and add each SalesRep email to the matching role

  Incorrect

  This needs role membership edits every week, which you want to avoid.

• BFilter the Sales table with [Region] = USERNAME()

  Incorrect

  USERNAME returns the user's identity, not a region, so nothing matches.

• CRelate the SalesRep table to the Region table so its filter reaches the sales data

  Correct

  The rep's rows then filter regions and, through them, the sales facts.

• DCreate one role whose DAX filter on SalesRep is [Email] = USERPRINCIPALNAME()

  Correct

  Each signed-in user sees only their own rows of SalesRep, which drive the filter.

• EGive each salesperson Build permission on the model

  Incorrect

  Build permission doesn't filter any rows.

Dynamic RLS uses a single role whose DAX filter compares a column with the signed-in user's identity, for example [Email] = USERPRINCIPALNAME(), on a table that maps users to the entities they may see. Relationships propagate that filter to the fact tables, so changing access means changing data, not roles.

• ABuild permission on the Budget semantic model, granted from its Manage permissions page

  Correct

  Viewers need Build permission to use Analyze in Excel, and it doesn't let them edit workspace content.

• BThe Contributor role in the workspace

  Incorrect

  Contributor includes Build but also lets her edit content, which isn't wanted.

• CReshare permission on the reports

  Incorrect

  Resharing lets her share reports; it doesn't enable Analyze in Excel.

• DA certified endorsement on the Budget semantic model

  Incorrect

  Endorsement signals quality; it grants no permission.

To let users with the Viewer role use Analyze in Excel or export underlying data from a workspace's semantic models, give them Build permission on those models. Build permission can be granted on the model's Manage permissions page, through sharing or through an app, without giving a higher workspace role.

• AA default label policy that sets Confidential on new items

  Incorrect

  A default label is a fixed label for unlabeled items, not the source's label.

• BA mandatory label policy for Power BI content

  Incorrect

  A mandatory label policy doesn't copy the source's label to the model.

• CThe Power BI admin setting that applies sensitivity labels from data sources to their data in Power BI

  Correct

  Inheritance from data sources must be enabled on the tenant for the service to apply source labels.

• DDownstream inheritance of sensitivity labels turned on for the workspace's reports

  Incorrect

  Downstream inheritance passes labels from a model to its reports, not from the data source to the model.

Semantic models that connect to labeled data in supported sources, such as Azure SQL Database, can inherit those labels. In the service this requires the tenant setting Apply sensitivity labels from data sources to their data in Power BI; changes in the source are then inherited on refresh.

• AAdmin

  Incorrect

  Admins can also update and delete the workspace and remove any user.

• BContributor

  Incorrect

  Contributors can update the app only if allowed, and can't publish it or change its permissions.

• CViewer

  Incorrect

  Viewers can't publish or manage the app.

• DMember

  Correct

  Members can publish and update the app, share items and add users with lower permissions, but can't delete the workspace or remove users.

Workspace roles grant cumulative capabilities: Contributors create, edit and delete content and can update the app only if an admin allows it; Members also publish, unpublish and change permissions for the app, share items and add users with lower permissions; Admins can additionally update and delete the workspace and add or remove any user.

• AIn Power BI Desktop, in the Manage roles dialog next to each role

  Incorrect

  You can't assign users to roles in Power BI Desktop.

• BIn Power Query Editor

  Incorrect

  Power Query shapes data, not security.

• CIn the report's Filters pane

  Incorrect

  Report filters aren't security roles.

• DIn the Power BI service, on the semantic model's security page

  Correct

  Members are assigned to roles in the service, not in Desktop.

You define RLS roles and their DAX filters in Power BI Desktop (or the service), but you can't assign users to roles in Desktop; you add members to roles in the Power BI service.

• ACreate and edit reports in the workspace

  Incorrect

  Viewers can't create or edit content in the workspace.

• BPublish the workspace app

  Incorrect

  Viewers can't publish or update the workspace's app.

• CView and interact with the workspace's content

  Correct

  Viewers can view and interact with items, but not create or edit them.

• DAdd other users to the workspace

  Incorrect

  Viewers can't add people to the workspace.

Workspace roles are Admin, Member, Contributor and Viewer. Viewer is the most limited: viewers can view and interact with items, but they can't create, edit or delete content, publish the app or add users.

• AConfidential, taken from the .pbix file

  Correct

  The file's label is applied to both the report and the semantic model created in the service.

• BNo Confidential label until someone applies one in the service

  Incorrect

  The label travels with the file when it's published.

• CThe workspace's default label

  Incorrect

  The new items take the label of the published file, not a label chosen by the workspace.

• DGeneral, because publishing the .pbix file resets labels

  Incorrect

  Publishing doesn't reset the file's label.

Sensitivity labels can be applied in Power BI Desktop. When you publish a .pbix file, its label is applied to both the report and the semantic model that are created in the service.

• AA Free license and Read permission on the report

  Incorrect

  With a Free license you can label items only in My workspace, and reading the report isn't enough.

• BA Pro or Premium Per User license and Edit permission on the report

  Correct

  These are the license and permission requirements for applying labels in the service.

• CThe Fabric administrator role for the tenant

  Incorrect

  Labeling isn't limited to admins; users who meet the requirements apply labels themselves.

• DA workspace that is assigned to a Fabric capacity

  Incorrect

  The requirement is a Pro or PPU license with Edit permission, not a capacity.

To apply sensitivity labels in the Power BI service, you need a Power BI Pro or Premium Per User license and Edit permission on the content you want to label, and you must belong to a group that the label policy allows. With a Free license, you can apply labels only to items in My workspace.