- What should the developer or an authorized publisher do?
Answer: Update the published app so that it contains the revised workspace content
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.
- Which additional permission should you grant Elena?
Answer: Reshare permission on the report that Elena can already read
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.
- What should you conclude?
Answer: Build permission grants model usage, but the report must be shared separately
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.
- Which workspace role should you assign to the analyst while following the principle of least privilege?
Answer: Contributor, because it permits content authoring without workspace access administration
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.
- Which action is required to ensure that Marco can no longer access the report?
Answer: Remove Marco from both the workspace role and the app audience
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.
- Which permission should you grant the business analysts on the semantic model?
Answer: Build, because it permits new content to be created from the model
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.
- Which workspace role should you assign to the testers?
Answer: Viewer, with each tester assigned to the appropriate row-level security role
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.
- What should a workspace administrator configure?
Answer: Enable the workspace setting that allows Contributors to update the app
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.
- What should you do with the least effect on other app users?
Answer: Remove Priya from the Executives audience and update the app
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.
- What happens when the analyst creates a new report from the semantic model?
Answer: The analyst can create the report, and queries remain restricted to West-region rows
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.
