- Which action is necessary to fully remove the contractor's access to that report?
Answer: Remove the contractor's direct item permission in addition to removing the contractor from the app.
When working with Power BI access control, you need to recognize that there are two independent layers of permissions: app audience membership and direct item permissions. These layers don't automatically cancel each other out — each must be managed separately.
Removing a contractor from an app audience revokes their ability to access content through the app, but it does nothing about permissions granted directly on individual items like reports. If someone previously shared a report directly with that contractor (outside of the app), that direct permission remains fully intact. That's exactly why the contractor can still open the report via a bookmark — they're bypassing the app entirely and accessing the report through its direct share link. To fully revoke access, you must go into the report's permission settings and explicitly remove the contractor's direct item permission. That's what makes B the correct answer.
A is wrong because app audience removals take effect immediately upon publishing — there's no "second update" requirement. This is a fictional rule designed to trip you up. C is a drastic and unnecessary action; deleting and republishing the report under a new name doesn't revoke existing permissions and would disrupt other users. D is a red herring — Build permission controls the ability to create content from a semantic model, not whether someone can view a report they already have direct access to. Disabling Build permission while retaining direct report access would still leave the contractor able to open the report.
As a study tip, remember: in Power BI, app access and direct item access are separate permission channels. Always check both when revoking someone's access completely.
- What will occur if the admin unpublishes the app?
Answer: The app becomes unavailable, while workspace content and separately granted item access can remain intact.
When you see a question about Power BI app lifecycle management, the key distinction to understand is that apps and workspaces are separate layers. An app is essentially a published "package" of workspace content distributed to consumers — but the underlying workspace items (reports, datasets, dashboards) exist independently of the app itself.
Unpublishing an app removes the app from consumers' Power BI home and app lists, making it inaccessible through that channel. However, it does nothing to the workspace itself — reports and datasets remain exactly where they are, fully accessible to workspace members. Crucially, any direct sharing or item-level permissions granted separately (like those given to the audit team) are also unaffected. Those permissions exist outside the app layer. This makes D the correct answer: the app becomes unavailable, but workspace content and separately granted access stay intact.
A is wrong because unpublishing an app triggers no automatic archiving of the workspace, and direct permissions are never "converted" to app permissions — they operate on entirely different mechanisms. B is dangerously incorrect: unpublishing deletes nothing. No workspace items are removed, and there are no "cached copies" — this confuses unpublishing with deleting. C is wrong because once unpublished, the app doesn't persist in a read-only state waiting for users to remove it; it simply becomes unavailable immediately without any user action required.
A useful mental model: think of the app as a storefront window and the workspace as the back warehouse. Closing the window doesn't empty the warehouse or revoke employee badges.
- How should you configure distribution while minimizing administrative effort?
Answer: Create one app audience per department, assign security groups, and avoid granting consumers workspace roles.
When distributing a Power BI app to multiple audience segments from a single workspace, the key concept to understand is app audiences. A single published app can have multiple audience configurations, each showing a different subset of content to different user groups — all without creating redundant workspaces or duplicating reports.
Option A is the right approach because it leverages Power BI's built-in audience feature to segment content by department within one app and one workspace. Assigning security groups (rather than individual users) handles the overlap between Finance and Operations cleanly — a user in both groups simply sees both departments' content. Crucially, keeping consumers out of workspace roles prevents them from editing content, satisfying that requirement while keeping administration centralized.
Option B creates unnecessary overhead by splitting into separate workspaces per department. This multiplies your publishing, maintenance, and governance effort — the opposite of minimizing administrative burden. It also doesn't elegantly handle users who belong to multiple departments.
Option C is tempting but flawed. Report-level permissions don't replace proper audience segmentation; hiding reports from a shared audience is fragile and harder to maintain. Granting the Viewer workspace role also gives consumers access to the workspace itself, not just the app, which violates the requirement to prevent editing of workspace content.
Option D is not a real Power BI capability — you cannot publish multiple separate apps from the same workspace simultaneously. Each workspace supports only one published app at a time.
Your study tip: remember that one workspace = one app, but one app can have many audiences. When you see content segmentation requirements, think audiences first before considering workspace sprawl.
- What should be done first?
Answer: Ask a Power BI or Fabric administrator to enable the tenant setting that permits publishers to push apps.
When you see a question about features being unavailable to workspace admins, think about tenant-level governance settings in Power BI. Many powerful features — especially those that affect all users organization-wide — are locked behind administrator-controlled toggles that must be enabled before anyone can use them, regardless of their workspace role.
The "install app automatically" option is controlled by a tenant setting called "Push apps to end users" (or similar wording in the Admin portal). Until a Power BI or Fabric administrator enables this setting, the checkbox simply won't appear or won't function for publishers — no matter how high their workspace role is. That's exactly what's happening here: the workspace admin can publish but can't trigger automatic installation because the tenant setting is off. Answer A correctly identifies that the very first step is getting an administrator to enable that tenant-level permission.
Answer B is a trap — upgrading someone from workspace Admin to Contributor would actually reduce their permissions, and workspace roles don't control this feature at all. Answer C confuses Build permissions (which govern who can connect to a dataset to build new reports) with app distribution settings — they're completely separate concepts. Answer D, publishing to the web, makes content publicly accessible on the internet and has nothing to do with pushing apps to internal employees' Apps lists; it's also a significant security risk.
The study tip here: whenever a feature appears "grayed out" or unavailable in Power BI, check whether a tenant-level setting needs to be enabled first — this is a recurring pattern on the exam.
- Which configuration best meets the requirement?
Answer: Enable the workspace option allowing Contributors to update the app, and retain the Contributor role.
When working with Power BI workspaces, questions about role permissions often hinge on understanding the granular capabilities built into each role — not just the broad hierarchy. The key here is identifying the minimum permission needed to accomplish a specific task without granting unnecessary elevated access.
The Contributor role in Power BI workspaces includes the ability to publish and update content, but by default, only Members and Admins can update a published app. However, workspace settings include a dedicated toggle that explicitly allows Contributors to update the app. Enabling this option is precisely what the scenario requires — the user gains app-update capability while remaining a Contributor, meaning they cannot manage workspace access or delete the workspace. Option B perfectly matches this requirement.
Option A introduces unnecessary risk and operational overhead. Temporarily promoting someone to Admin grants full workspace control — including managing membership and deletion rights — which directly violates the stated constraint. Cycling roles after every release is also impractical and error-prone.
Option C confuses app consumption permissions with app publishing permissions. Build and reshare permissions control whether users can interact with or redistribute underlying datasets, not whether they can update the app itself. This wouldn't give the user the ability to push app updates.
Option D is a fundamental mismatch. The Viewer role is read-only at the workspace level, and owning individual reports doesn't grant the ability to update a published app. Report ownership and app publishing are separate concepts entirely.
Your study tip: memorize the specific workspace settings that extend default role capabilities — like the Contributors-can-update-app toggle — because exam questions frequently test these edge cases rather than just the standard role hierarchy.
- What is the most likely explanation?
Answer: The app URL provides navigation, but the recipient or an assigned group must also be granted app access.
When working with Power BI apps, it helps to understand that publishing and sharing access are two separate actions. A Power BI app URL is essentially a navigation link — it tells the recipient where to go, but it doesn't automatically grant permission to enter. The publisher must explicitly grant app access to specific users or groups through the app's permission settings. That's exactly what answer C describes, and it's the most likely reason the recipient saw an access-request message instead of the app content.
Answer A is incorrect because app URLs do not have an expiration mechanism tied to automatic installation settings. There is no such tenant-level toggle that keeps a URL "active." Answer B introduces a real concept — workspace roles — but misapplies it. Workspace Viewer is a role for collaborators inside the workspace, not a prerequisite for end users consuming a published app. App consumers and workspace members are managed through entirely separate permission paths, which is a critical distinction on this exam. Answer D brings up Build permission, which is relevant when a user needs to create new content from a semantic model (like building their own reports). Simply viewing a published app does not require Build permission on the underlying models.
The key takeaway here is to remember the publish vs. share distinction: publishing an app makes it available, but you must separately grant users or groups access to it. On the Power BI exam, watch for scenarios where someone conflates the app URL with a permission grant — they test this pattern frequently because it's a common real-world mistake.
- Which access design best preserves row-level security for the regional managers?
Answer: Keep managers as app consumers only, assign their identities to RLS roles, and avoid edit-capable workspace roles.
When Power BI distributes content through apps, workspace roles and RLS interact in a critical way: workspace roles like Member or Contributor bypass RLS entirely, because those roles grant edit or view access to the underlying semantic model directly, not through the app's permission layer. This makes role assignment the most dangerous lever when RLS is in play.
The safest design, confirmed as option D, keeps regional managers completely outside the workspace by assigning them no workspace role at all. They consume the app as end users, and their Azure AD identities are mapped to RLS roles in the semantic model. This means Power BI enforces row-level filtering at query time based on who they are — exactly what RLS is designed to do.
Option A is flawed because Build permission allows users to connect to and analyze the underlying dataset outside the app, potentially bypassing report-level filters. Removing RLS assignments makes this even more dangerous. Option B is the most harmful choice: giving managers the Contributor role means they can edit workspace content and will not have RLS applied to them at all, since workspace members with edit roles see all data regardless of RLS mappings. Option C has the same core problem as B — the Member role grants full data visibility and nullifies RLS, so moving managers there defeats the entire security model.
The key study tip here: workspace roles trump RLS. Any time a user holds a Member, Contributor, or Admin role in a workspace, RLS does not apply to them. For enforced data segmentation, keep restricted users as app consumers only, never as workspace members.
- Which action is required to ensure app users receive all these changes?
Answer: Update the app after the report changes; refreshed data values do not independently require republishing.
When working with Power BI apps, you need to distinguish between two separate layers: the semantic model (data) and the report content (pages, visuals, layout). These layers update independently, and understanding which changes require which action is exactly what this question tests.
In Power BI, a scheduled or manual dataset refresh automatically flows through to app users for data value changes — no republishing is required. So when the overnight refresh updates sales figures, app users will see the new numbers the next time they open the app without any author intervention. However, structural report changes — like adding a new page or renaming visual titles — are workspace-level edits that do not automatically push to the app. The author must explicitly select Update app in the service to publish those changes to app users. This is why B is correct: the report edits require an app update, but the refreshed data does not independently require one.
A is wrong because it implies the author must trigger another data refresh to distribute changes — refreshes handle data, not report structure, and a refresh already occurred overnight. C is wrong because authors absolutely can update an app directly from the Power BI service without ever opening Power BI Desktop; republishing a PBIX file is not required. D is wrong because apps are not locally cached installations like traditional software — users access a live, centrally hosted version, so there is nothing to "reinstall."
A useful study habit: think of refresh = data, Update app = structure. Any time a question mixes both types of changes, ask yourself which layer each change belongs to before choosing your action.
- Which change can satisfy the requirement?
Answer: Assign the workspace to qualifying Premium or Fabric capacity and retain the employees as app consumers.
Whenever you see a question about distributing Power BI content to users with Free licenses, the key constraint to keep in mind is this: Free-license users can only consume Power BI content hosted in Premium or Fabric capacity. Shared capacity requires at least a Pro or PPU license to view published content.
This is exactly why A is correct. By moving the workspace to a qualifying Premium or Fabric capacity, the organization unlocks the ability for Free-license holders to consume published apps without needing paid per-user licenses. The employees remain app consumers — no role changes, no license upgrades required — because the capacity itself covers the cost of content delivery.
B is a common trap. Granting the Viewer role gives users access to the workspace directly, but the workspace is still in shared capacity. Free-license users cannot interact with content in shared capacity regardless of their role assignment — they'd still need at least a Pro license.
C misunderstands what automatic app installation does. That feature controls how the app is delivered to users (pushed automatically vs. manually installed), not whether Free-license users can view it. Leaving the workspace in shared capacity still blocks Free-license consumption.
D publishing to the entire organization and enabling reshare doesn't change the licensing constraint either. Reshare permission controls what consumers can do with the app, not whether they're licensed to access it in the first place.
Your study tip: on licensing questions, always ask yourself two things — what license does the user have, and what capacity is the content in? Both must align for access to work.
- What should you configure?
Answer: Grant Build permission to the analysts' audience, and omit that permission from the employees' audience.
When distributing Power BI apps, you need to distinguish between two separate layers of permission: what consumers can see (app content) and what they can build (new reports from a semantic model). Apps support multiple audiences, letting you tailor each group's experience without assigning workspace roles.
The scenario asks you to give analysts the ability to create their own reports — which requires Build permission on the semantic model — while regular employees only view the supplied reports. Answer C solves this cleanly: you configure two audiences within the app, grant the analysts' audience Build permission on the semantic model, and omit that permission from the employees' audience. Build permission is the specific Power BI capability that allows a user to connect to a semantic model and author new content from it. No workspace role is needed for either group, satisfying that constraint explicitly.
A is wrong because reshare permission controls whether consumers can share the app with others — it has nothing to do with enabling report creation from a semantic model. Audiences, not reshare permissions, control content visibility.
B violates the core requirement. Assigning analysts the Contributor workspace role gives them access to the workspace itself, not just the app — directly contradicting the instruction that no consumer should receive a workspace role.
D inverts the logic. Analysts need Build permission (not just Read) on the semantic model to create reports, and employees need Read permission on the reports (not the semantic model). Swapping these breaks both groups' access.
As a study tip: on Power BI exam questions, Build permission is the keyword that signals "can create new reports from this dataset." Whenever a question mentions analysts building content, look for that term in the correct answer.
