Microsoft Power BI Quiz: Apps For Distribution
10 questions · exam conditions
0:00
Apps For DistributionQuestion 1 of 10

An app distributes a certified semantic model and several reports. Analysts should view the reports and create their own reports from the semantic model. Other employees should only view the supplied reports. No consumer should receive a workspace role.

What should you configure?

Grant all consumers reshare permission, and use audiences to prevent employees from editing supplied reports.
Grant analysts the workspace Contributor role, and leave other employees as ordinary app consumers.
Grant Build permission to the analysts' audience, and omit that permission from the employees' audience.
Grant analysts Read permission on the reports, and grant employees Read permission on the semantic model.
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Apps For Distribution

Practice Apps For Distribution 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 Apps For Distribution, 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

An app distributes a certified semantic model and several reports. Analysts should view the reports and create their own reports from the semantic model. Other employees should only view the supplied reports. No consumer should receive a workspace role.

What should you configure?

  1. Grant all consumers reshare permission, and use audiences to prevent employees from editing supplied reports.
  2. Grant analysts the workspace Contributor role, and leave other employees as ordinary app consumers.
  3. Grant Build permission to the analysts' audience, and omit that permission from the employees' audience. (correct answer)
  4. Grant analysts Read permission on the reports, and grant employees Read permission on the semantic model.
Explanation: 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.

Question 2

A company wants to distribute a Power BI app to 700 employees. The employees have Microsoft Fabric Free licenses. The app's workspace is currently in shared capacity, and the employees must interact with its reports without receiving paid per-user licenses.

Which change can satisfy the requirement?

  1. Assign the workspace to qualifying Premium or Fabric capacity and retain the employees as app consumers. (correct answer)
  2. Grant every employee the workspace Viewer role while leaving the workspace in shared capacity.
  3. Enable automatic app installation and leave the workspace assigned to shared capacity.
  4. Publish the app to the entire organization and enable reshare permission for all employees.
Explanation: 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.

Question 3

The executive team wants a compliance app to appear automatically in every employee's Power BI Apps list. A workspace admin can publish the app but cannot select the option to install it automatically.

What should be done first?

  1. Ask a Power BI or Fabric administrator to enable the tenant setting that permits publishers to push apps. (correct answer)
  2. Assign the workspace admin the Contributor role so that automatic installation becomes available.
  3. Enable Build permission for every app audience before selecting the automatic-installation option.
  4. Publish the app publicly to the web so that it appears in each employee's Apps list.
Explanation: 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.

Question 4

A semantic model uses row-level security to restrict regional sales data. Regional managers receive a distributed app and are not workspace members. A developer is assigned the workspace Contributor role and is also included in the app audience.

Which access design best preserves row-level security for the regional managers?

  1. Grant managers Build permission, remove their RLS assignments, and filter each report by regional audience.
  2. Assign managers the Contributor role, include them in RLS roles, and distribute the same app to everyone.
  3. Assign managers the Member role, remove them from app audiences, and depend on RLS in the workspace.
  4. Keep managers as app consumers only, assign their identities to RLS roles, and avoid edit-capable workspace roles. (correct answer)
Explanation: 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.

Question 5

A workspace Member publishes a departmental app. The team wants a user with the Contributor role to update the app when report content changes, but the user must not manage workspace access or delete the workspace.

Which configuration best meets the requirement?

  1. Promote the user to Admin, publish the update, and then restore the Contributor role after every release.
  2. Enable the workspace option allowing Contributors to update the app, and retain the Contributor role. (correct answer)
  3. Grant the user Build and reshare permissions through the app, and retain the Contributor role.
  4. Assign the user the Viewer role and make the user an owner of each report included in the app.
Explanation: 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.

Question 6

A workspace contains reports for the Finance, Sales, and Operations departments. Each department must see only its own reports in the distributed app. Several users belong to both Finance and Operations. Consumers must not be able to edit workspace content.

How should you configure distribution while minimizing administrative effort?

  1. Create one app audience per department, assign security groups, and avoid granting consumers workspace roles. (correct answer)
  2. Create separate workspaces per department, grant consumers the Viewer role, and publish one shared app.
  3. Create one audience for all consumers, hide reports with report-level permissions, and grant the Viewer role.
  4. Publish one app for each department from the same workspace and assign users directly to each app.
Explanation: 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.

Question 7

A publisher sends the URL of a Power BI app to a project distribution list. One recipient opens the link and receives an access-request message. The publisher expected the link itself to provide access.

What is the most likely explanation?

  1. The app URL expires after publication unless the publisher enables automatic installation for the tenant.
  2. The recipient must first receive the workspace Viewer role before any distributed app URL can be opened.
  3. The app URL provides navigation, but the recipient or an assigned group must also be granted app access. (correct answer)
  4. The recipient must receive Build permission on every semantic model used by reports in the app.
Explanation: 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.

Question 8

A workspace admin plans to retire an obsolete app. The workspace still contains reports that authors need for historical analysis. Some reports were also shared directly with a small audit team.

What will occur if the admin unpublishes the app?

  1. The workspace is archived automatically, and direct report permissions are converted to app permissions.
  2. The app and all workspace items are deleted, but audit users retain cached copies of the reports.
  3. The app remains installed in read-only mode until every consumer manually removes it from Power BI.
  4. The app becomes unavailable, while workspace content and separately granted item access can remain intact. (correct answer)
Explanation: 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.

Question 9

A sales app contains a report connected to an imported semantic model. Overnight refresh changes the report's data values. Later, an author adds a new report page and changes two visual titles in the workspace report.

Which action is required to ensure app users receive all these changes?

  1. Refresh the semantic model again because app content updates only during a scheduled or manual refresh.
  2. Update the app after the report changes; refreshed data values do not independently require republishing. (correct answer)
  3. Republish the PBIX file from Power BI Desktop because an app cannot be updated from the service.
  4. Reinstall the app for each audience because report pages are cached when an app is first installed.
Explanation: 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.

Question 10

A contractor was removed from every audience of a procurement app. The contractor can no longer open the app, but a report previously shared directly with the contractor still opens from an old browser bookmark.

Which action is necessary to fully remove the contractor's access to that report?

  1. Update the app again because audience removals do not take effect until the second update.
  2. Remove the contractor's direct item permission in addition to removing the contractor from the app. (correct answer)
  3. Delete the report from the workspace and republish it under a new report display name.
  4. Disable Build permission on the semantic model while retaining the contractor's direct report access.
Explanation: 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.