Microsoft Power BI Quiz: Permissions
10 questions · exam conditions
0:00
PermissionsQuestion 1 of 10

A project team uses a Power BI workspace to develop reports. A new analyst must create, edit, and delete workspace content. The analyst must not manage workspace access, modify workspace settings, or control app audiences.

Which workspace role should you assign to the analyst while following the principle of least privilege?

Admin, because content deletion requires control of the workspace settings
Member, because report editing requires permission to manage the workspace app
Contributor, because it permits content authoring without workspace access administration
Viewer, because users can edit content after receiving Build permission
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Permissions

Practice Permissions in Microsoft Power BI with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Permissions, giving you a quick way to practice the rules, question types, and explanations that matter most for Microsoft Power BI.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A project team uses a Power BI workspace to develop reports. A new analyst must create, edit, and delete workspace content. The analyst must not manage workspace access, modify workspace settings, or control app audiences.

Which workspace role should you assign to the analyst while following the principle of least privilege?

  1. Admin, because content deletion requires control of the workspace settings
  2. Member, because report editing requires permission to manage the workspace app
  3. Contributor, because it permits content authoring without workspace access administration (correct answer)
  4. Viewer, because users can edit content after receiving Build permission
Explanation: When a question asks you to assign a workspace role while "following the principle of least privilege," your job is to find the role that grants exactly what's needed — no more, no less. In Power BI, the four workspace roles form a hierarchy: Admin > Member > Contributor > Viewer. A Contributor can create, edit, and delete workspace content (reports, datasets, dashboards) but cannot manage workspace access, change workspace settings, or control who sees the published app. That maps perfectly to the analyst's requirements, making C the correct answer. A is wrong because Admin is the most privileged role — it grants full control over workspace settings and access management, which the analyst is explicitly prohibited from having. The claim that "content deletion requires workspace settings control" is simply false; Contributors can delete content they've created. B is wrong because Members can manage the workspace app (including publishing and modifying app audiences), which directly violates the constraint that the analyst must not control app audiences. Member is more powerful than necessary. D is wrong because Viewers have read-only access. Build permission on a dataset allows a user to create new reports from that dataset in their own workspace, but it does not grant the ability to create, edit, or delete content inside the shared workspace itself. As a study tip, memorize the Contributor boundary: it's the highest role that keeps you purely in content creation without touching governance (access, settings, app publishing). Exam questions frequently test whether you know where that line falls between Contributor and Member.

Question 2

A workspace contains an existing published app. Several developers have the Contributor role. They must be able to update the app after changing reports, but they must not add users to app audiences or receive the broader permissions of the Member role.

What should a workspace administrator configure?

  1. Enable the workspace setting that allows Contributors to update the app (correct answer)
  2. Grant Contributors Build permission on every semantic model in the app
  3. Add the developers to every audience defined for the published app
  4. Change the developers to Members only while each app update is running
Explanation: When working with Power BI workspaces, role assignments and app update permissions are separate concepts — and this question tests whether you understand that distinction. The Contributor role alone does not grant permission to publish or update a published app; that capability must be explicitly unlocked. Workspace administrators can toggle a setting that allows Contributors to update the app without elevating them to the Member role. This is precisely what the scenario requires: developers can push changes to reports and refresh the app, but they cannot manage audiences or gain the broader administrative access that Members have. Enabling this workspace-level setting, answer A, is the clean, purpose-built solution. B is a distractor that confuses two different permission layers. Build permission controls who can connect to and use semantic models to create their own content — it has nothing to do with publishing or updating a workspace app. Granting it would be irrelevant to the problem described. C misunderstands the audience feature entirely. Adding developers to an app audience controls who can view the app, not who can update it. This solves the wrong problem and doesn't address publishing rights at all. D is operationally impractical and defeats the purpose of role-based access control. Temporarily promoting someone to Member during an update window gives them all Member permissions — not just app update rights — and violates the requirement to restrict broader permissions. Study tip: On Power BI exam questions, whenever you see a requirement that sounds like "less than Member but more than basic Contributor," think immediately of the workspace setting that bridges that gap for app updates.

Question 3

Marco can access a sales report in two ways: he is a Viewer in the report's workspace, and he is included in an audience for the published app. The report has never been shared with him directly, and he has no access through a Microsoft Entra security group. Marco is leaving the sales department and must lose access immediately.

Which action is required to ensure that Marco can no longer access the report?

  1. Remove Marco from the app audience only, because app permissions override workspace roles
  2. Remove Marco from the workspace only, because workspace removal revokes app access automatically
  3. Remove Marco from both the workspace role and the app audience (correct answer)
  4. Remove Marco's Build permission only, because reports require Build permission to open
Explanation: When managing access in Power BI, it's critical to understand that workspace roles and app audiences are two independent permission systems. A user can gain access to content through either path, and removing access from one does not affect the other. In Marco's case, he has two separate access channels: a Viewer role in the workspace and membership in the app's audience. These are maintained independently in Power BI's permission model. To guarantee he loses all access immediately, both must be revoked — making C the correct answer. Option A is wrong because app permissions do not "override" workspace roles — they coexist. Even if you remove Marco from the app audience, his Viewer role in the workspace still grants him direct access to the report there. Option B contains the most dangerous misconception: removing someone from a workspace does not automatically revoke their app access. App audiences are managed separately in the app's settings, so Marco could still open the report through the published app. Option D is a red herring — Build permission allows users to connect to or create content from a dataset, not simply to view a published report. Revoking Build permission would have no effect on Marco's viewing access through his workspace role or app audience. A useful rule of thumb: every access path must be closed individually. On the Power BI exam, whenever a question mentions multiple access routes — workspace role, app audience, direct share, security group — assume you must address each one independently. There is no single "master switch" that cascades across all permission types simultaneously.

Question 4

A semantic model uses row-level security to restrict regional sales data. Testers need to open reports from the workspace and verify exactly what ordinary regional users see. The testers must not bypass row-level security through an elevated workspace role.

Which workspace role should you assign to the testers?

  1. Admin, with each tester also assigned to the appropriate row-level security role
  2. Member, with report editing disabled through the app audience configuration
  3. Contributor, with Build permission removed from the semantic model
  4. Viewer, with each tester assigned to the appropriate row-level security role (correct answer)
Explanation: When a question asks about verifying row-level security (RLS) behavior in Power BI, you need to think about two separate permission systems working together: workspace roles (which control what actions a user can take) and RLS roles (which filter what data a user can see). The Viewer role is the lowest workspace role that still allows users to open and interact with reports. Critically, Viewers cannot edit reports, cannot access underlying datasets directly, and — most importantly — are subject to row-level security enforcement. When testers hold the Viewer role and are assigned to the appropriate RLS role, they see exactly what a regional user would see. That's why D is correct. A is wrong because Admin, Member, and Contributor roles all have elevated permissions that bypass row-level security entirely. Assigning testers to an RLS role doesn't matter if their workspace role exempts them from RLS enforcement — they'll still see unfiltered data. This is a classic trap: the RLS role assignment sounds correct, but the elevated workspace role overrides it. B is wrong because the Member role also bypasses RLS, and app audience configuration controls report visibility in apps, not RLS enforcement. This doesn't solve the core problem. C is wrong because the Contributor role similarly bypasses RLS. Removing Build permission from the semantic model restricts downstream use (like building new reports), but it doesn't restore RLS filtering for Contributors. Your study tip: memorize that Admin, Member, and Contributor roles bypass RLS, while the Viewer role respects it. On exam questions involving RLS verification, Viewer is almost always the right choice for the workspace role.

Question 5

A developer modifies a report in a workspace and confirms that the revised version appears when the report is opened directly from the workspace. Users who consume the report through the associated Power BI app still see the previous version. Their audience memberships have not changed.

What should the developer or an authorized publisher do?

  1. Update the published app so that it contains the revised workspace content (correct answer)
  2. Reassign every app consumer to the workspace Viewer role before refreshing
  3. Grant Build permission on the semantic model to every app audience member
  4. Delete and recreate the app audiences so that their content is synchronized
Explanation: Whenever you see a question about Power BI apps and content discrepancies, think about the two-layer publishing model: workspaces hold the "live" content, but apps are a separate, curated snapshot that must be explicitly published to consumers. Editing a report in the workspace does not automatically push those changes to the app — you must republish the app to make updates visible to app audiences. That's exactly why A is correct. The developer confirmed the revised report exists in the workspace, but app consumers see a frozen version from the last time the app was published. The fix is simply to update (republish) the app, which packages the current workspace content and delivers it to all existing audiences without requiring any changes to their memberships or permissions. B is wrong because workspace role assignments (like Viewer) control who can browse workspace content directly — they have no bearing on app delivery. Reassigning roles would not synchronize app content and would actually give consumers more direct workspace access than intended. C is wrong because Build permission relates to whether users can connect to or build new content on top of a semantic model (e.g., in Excel or their own reports). It has nothing to do with which version of a report an app displays. D is wrong because deleting and recreating audiences is unnecessary and disruptive. Audiences persist correctly through republishing; they don't need to be rebuilt to receive updated content. Study tip: Remember the mantra — workspace changes don't equal app changes. On the exam, any scenario where app users see stale content almost always points to a missed app republish step.

Question 6

A semantic model implements row-level security for East and West regions. An external analyst is assigned to the West RLS role and receives Read and Build permissions directly on the semantic model. The analyst is not an Admin, Member, or Contributor in the model's workspace.

What happens when the analyst creates a new report from the semantic model?

  1. The analyst can create the report, and queries remain restricted to West-region rows (correct answer)
  2. The analyst can create the report, and Build permission bypasses all RLS filters
  3. The analyst cannot create the report unless assigned the workspace Contributor role
  4. The analyst can create the report only after receiving Reshare permission as well
Explanation: When a question involves both workspace roles and semantic model permissions in Power BI, you need to track two separate security layers: access to the workspace itself versus access to a specific artifact within it. In Power BI, you don't need a workspace role to use a semantic model that's been shared directly with you. When someone grants you Read and Build permissions on a semantic model, Read lets you query it and Build lets you create new content (reports, dashboards, etc.) derived from it — no workspace role required. That's exactly the scenario here: the analyst has Build permission, so they can create a new report by connecting to the shared model. Now, critically, RLS is enforced based on role assignment, not permission level. Because the analyst is assigned to the West RLS role, every query they run against the model will be filtered to West-region data only — even in their newly created report. That makes A correct. B is wrong because Build permission has nothing to do with bypassing RLS. Build only controls whether you can create derivative content; RLS filters apply regardless of how you're accessing the model. C is a common trap. Workspace Contributor (or higher) roles are needed to publish or edit content within the workspace, but an external analyst can create reports from a shared model entirely outside that workspace context. D confuses Reshare permission with Build permission. Reshare would allow the analyst to grant others access to the model, which is unrelated to their own ability to create reports. Remember: in Power BI, Build = create, RLS = always enforced by role, and workspace roles ≠ model-level permissions.

Question 7

Noah receives Build permission on a semantic model used by an executive report. He is not a member of the report's workspace, is not included in the app audience, and has not been granted direct access to the executive report. Noah reports that the report does not appear in his Power BI content.

What should you conclude?

  1. Build permission should display every report connected to the semantic model after refresh
  2. Build permission displays reports only after Noah receives Reshare permission
  3. Build permission is inactive until Noah receives workspace Contributor access
  4. Build permission grants model usage, but the report must be shared separately (correct answer)
Explanation: When working with Power BI permissions, it's critical to distinguish between access to a semantic model and access to the reports built on top of it. These are governed independently, and confusing them is one of the most common mistakes on permission-related exam questions. Build permission gives Noah the ability to connect to the semantic model and create his own content — think new reports, Excel analyses, or Analyze in Excel sessions. What it does not do is automatically surface existing reports that happen to use that model. Since Noah isn't a workspace member, isn't included in the app audience, and hasn't been granted direct report access, there is simply no pathway through which the executive report becomes visible to him. This confirms that D is correct: Build permission governs model usage, while the report itself must be shared through a separate mechanism (direct access, workspace membership, or an app). Option A is wrong because Build permission has no relationship to report visibility — refreshing the semantic model doesn't change who can see reports connected to it. Option B introduces "Reshare permission," which is a real concept but has nothing to do with making reports visible to a user who lacks report access; Reshare only allows someone who already has access to share it further. Option C incorrectly implies Build permission is dormant without Contributor workspace access — Build is a standalone permission that works independently of workspace roles. A useful rule of thumb: semantic model permissions and report permissions are separate layers. Granting one never implies the other. Keep this boundary clear, and permission questions become much more straightforward.

Question 8

A centralized analytics team owns a certified semantic model. Business analysts must use the semantic model to create new reports in their own workspaces. They must not edit the semantic model or manage its permissions.

Which permission should you grant the business analysts on the semantic model?

  1. Read, because viewing data automatically permits creation of new reports
  2. Build, because it permits new content to be created from the model (correct answer)
  3. Reshare, because creating a report requires redistributing the source model
  4. Write, because report creation modifies the source model's metadata
Explanation: When working with shared semantic models in Power BI, you need to understand the distinct permission levels and what each one actually unlocks for the recipient. The core question here is: what permission allows someone to consume a model to build new content, without giving them control over the model itself? The Build permission is specifically designed for this scenario. It grants users the ability to connect to a semantic model and create new reports, Excel pivot tables, or other downstream content — all without touching the model's structure or managing who else can access it. This makes B the correct answer and the right fit for business analysts who need creative freedom without administrative access. A is wrong because Read permission alone only lets users view existing reports and dashboards. It does not automatically enable report creation from the underlying model. This is a common misconception — "seeing" the data and "building on" the data are treated as separate privileges in Power BI. C is incorrect because Reshare permission relates to forwarding access to others, not to creating content. Report creation has nothing to do with redistributing the model's permissions. D misrepresents how report creation works. Building a new report does not modify the source semantic model's metadata — the model remains entirely intact. Write permission is reserved for scenarios where someone needs to actually change the model itself, which directly contradicts the scenario's requirement. A useful rule of thumb: on Power BI permission questions, Build = create content from the model, Read = consume existing content, and Write = modify the model. Keep that hierarchy clear and these questions become straightforward.

Question 9

Elena has direct Read access to a report but is not a workspace member. She must be able to grant other employees access to that same report. She must not edit the report, create reports from its semantic model, or receive access to unrelated workspace content.

Which additional permission should you grant Elena?

  1. Build permission on the semantic model used by the report
  2. Reshare permission on the report that Elena can already read (correct answer)
  3. Contributor access to the workspace containing the report
  4. Membership in the audience of the app containing the report
Explanation: When dealing with Power BI sharing and permissions, the key is to match the exact capability needed — no more, no less — to the right permission type. Here, Elena needs one specific thing: the ability to share the report with others. She already has Read access, so the missing piece is the right to reshare that access. In Power BI, when someone shares a report directly (outside of a workspace or app), the sharer can optionally enable "Allow recipients to share this report" — this is the Reshare permission. Granting Elena this permission on the report she can already read is precisely what enables her to forward access to other employees. It's a targeted, additive permission on a single artifact. B is correct. A is a trap. Build permission lets a user create new content — like reports or dashboards — from the underlying semantic model. Elena is explicitly not allowed to do this, so Build permission would overstep the requirements and still wouldn't let her reshare the report itself. C would give Elena Contributor-level workspace access, which allows editing reports and accessing all workspace content. This violates two constraints: she must not edit the report, and she must not gain access to unrelated workspace content. D adds Elena to an app audience, which controls what she can view through the app experience. App membership doesn't grant the ability to share the original report with others — that's a separate mechanism entirely. The study tip here: on permission questions, watch for options that give too much access. Power BI has granular sharing controls precisely to avoid over-permissioning — and the exam tests whether you know the difference between Reshare, Build, workspace roles, and app distribution.

Question 10

A Power BI app has two audiences. The Finance audience can access the Revenue and Forecast reports. The Executives audience can access the Revenue and Acquisition reports. Priya belongs to both audiences. She should retain access to Revenue and Forecast but must no longer access Acquisition.

What should you do with the least effect on other app users?

  1. Remove Acquisition from the app and republish it for all audiences
  2. Remove Priya from the Executives audience and update the app (correct answer)
  3. Remove Priya from the Finance audience and update the app
  4. Assign Priya the Viewer role in the underlying app workspace
Explanation: When managing Power BI app audiences, your goal is always to make the most targeted change possible — one that fixes the specific problem without disrupting anyone else's access. Think of audiences as permission groups: a user who belongs to multiple audiences inherits the combined access of all of them. Here, Priya belongs to both Finance (Revenue + Forecast) and Executives (Revenue + Acquisition). The problem is that her Executives membership is granting her Acquisition access she shouldn't have. The cleanest fix is to remove her from the Executives audience and republish the app — this is exactly what B does. She retains her Finance membership, keeping Revenue and Forecast, and loses Acquisition because she's no longer in Executives. No other Executives or Finance members are affected at all. A is too broad — removing Acquisition from the app entirely strips it from every Executive user, which is a major disruption to others who legitimately need it. C makes the problem worse: removing Priya from Finance takes away her Forecast access, which she's supposed to keep, and still leaves her in Executives with Acquisition access untouched. D is a distractor that conflates workspace roles with app audiences. The Viewer workspace role controls access to the underlying workspace, not to specific reports within a published app — it wouldn't surgically remove Acquisition from Priya's view. As a study tip, remember that app audiences are the right tool for per-user report filtering in published apps — workspace roles are a broader, blunter instrument. Questions about least-impact changes almost always point toward the most narrowly scoped option.