Microsoft Power BI Quiz: Sharing And Access Management
10 questions · exam conditions
0:00
Sharing And Access ManagementQuestion 1 of 10

A report uses row-level security so that each regional contractor sees only the contractor's assigned region. Contractors must access the report through its workspace, but they must not edit content or bypass row-level security.

Which workspace role should you assign to the contractors?

Contributor, because contributors can view reports and their permissions are still constrained by row-level security filters.
Member, because members can consume reports while row-level security remains enforced for their sessions.
Viewer, because viewers have read-only access and remain subject to row-level security enforcement.
Admin, because administrators can impersonate assigned roles and verify that the report filters correctly.
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Sharing And Access Management

Practice Sharing And Access Management 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 Sharing And Access Management, 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 report uses row-level security so that each regional contractor sees only the contractor's assigned region. Contractors must access the report through its workspace, but they must not edit content or bypass row-level security.

Which workspace role should you assign to the contractors?

  1. Contributor, because contributors can view reports and their permissions are still constrained by row-level security filters.
  2. Member, because members can consume reports while row-level security remains enforced for their sessions.
  3. Viewer, because viewers have read-only access and remain subject to row-level security enforcement. (correct answer)
  4. Admin, because administrators can impersonate assigned roles and verify that the report filters correctly.
Explanation: When a question asks about workspace roles in Power BI, focus on two things: the minimum level of access needed and whether row-level security (RLS) remains enforced. RLS enforcement is tied to how a user accesses content — users who access reports through workspace roles (rather than building or publishing them) always have RLS applied to their sessions. The real decision is about privilege level. The Viewer role is designed exactly for this scenario. Viewers can open and interact with reports but cannot create, edit, or publish content. Critically, they cannot use the "View as" or role impersonation features, so they cannot bypass RLS — they see only the data their assigned RLS role permits. This satisfies all three requirements: workspace access, read-only behavior, and RLS enforcement. A is wrong because Contributors can publish and edit reports in the workspace, which directly violates the requirement that contractors must not edit content. Contributor access exceeds the minimum necessary privilege. B is wrong for a similar reason — Members have even broader permissions, including the ability to share content and modify apps. Assigning Member access would unnecessarily expose workspace management capabilities to contractors. D is wrong because Admins have full control over the workspace, including impersonating RLS roles themselves. This is the opposite of what you want; an Admin could actively bypass RLS, creating a security risk. As a study tip, remember the Power BI role hierarchy — Admin > Member > Contributor > Viewer — and always choose the least privileged role that still meets the stated requirements. Exam questions frequently test whether you over-provision access.

Question 2

Analysts can view a sales report, but they cannot use Analyze in Excel or create their own reports from its semantic model. They must retain read-only access to the existing report and must not be allowed to modify workspace content.

Which additional permission should you grant?

  1. Build permission on the semantic model, while retaining their existing report-consumption access. (correct answer)
  2. Contributor access to the workspace, while removing their direct permission to the report.
  3. Reshare permission on the report, while retaining their existing semantic-model access.
  4. Admin access to the semantic model, while limiting their workspace role to Viewer.
Explanation: When a question describes users who can view a report but cannot use Analyze in Excel or build their own visuals from a dataset, you're being tested on the distinction between report consumption and semantic model access. These are controlled by separate permissions in Power BI. The ability to use Analyze in Excel, create reports in Power BI Desktop, or build custom visuals against a semantic model all require Build permission on that model. Read access to a report does not automatically grant Build permission — they are intentionally separate. Granting Build permission on the semantic model, as option A describes, gives analysts exactly what they need without touching workspace roles or modifying their existing report access. This satisfies every constraint in the scenario: read-only report access is retained, workspace content remains unmodified by them, and they gain the ability to connect and analyze. Option B is wrong because assigning Contributor access to the workspace would allow analysts to edit and publish content — directly violating the requirement that they must not modify workspace content. Option C is a trap: Reshare permission only lets users share the report with others; it has nothing to do with building new content or using Analyze in Excel, so it solves the wrong problem entirely. Option D fails because there is no "Admin access to the semantic model" as a standalone permission type — Admin is a workspace role, not a model-level permission — making this option both inaccurate and insufficient. A useful pattern to remember: Build permission lives on the semantic model, not the workspace role. On the exam, whenever analysts need to create content from a dataset without gaining workspace editing rights, Build permission is almost always the correct lever to pull.

Question 3

A report owner wants to send a link in a broad email distribution. Some recipients already have report access through an app or a security group, but the email link itself must not grant access to anyone new.

Which link type should the owner use?

  1. People in your organization, because the link grants read access only after organizational authentication.
  2. Specific people, because recipients not named in the link will automatically receive Viewer access.
  3. People with existing access, because opening the link does not create a new permission grant. (correct answer)
  4. Publish to web, because the generated link preserves the report's existing Power BI permissions.
Explanation: When sharing Power BI reports broadly, you need to understand what each link type actually does to permissions — specifically whether the link itself creates new access or simply serves as a doorway for people who already have it. The right choice here is C. The "People with existing access" link type is designed exactly for this scenario: it generates a shareable URL that works only for users who already have permission to the report through some other means (an app, a security group, direct sharing, etc.). Opening the link does not trigger any new permission grant — it simply lets existing permitted users navigate directly to the report. This makes it ideal for broad distributions where you don't want to accidentally expand your audience. A is tempting but incorrect. "People in your organization" grants read access to any authenticated user within your Azure AD tenant — even those who never had access before. It effectively opens the report to your entire organization, which is the opposite of what the scenario requires. B is also wrong. "Specific people" requires you to name individual recipients, and it does grant access to those named individuals if they didn't already have it. It's not a passive link — it actively creates permissions, and it doesn't scale well for broad email distributions. D is the most dangerous distractor. Publish to web creates a fully public link with no authentication whatsoever, bypassing Power BI permissions entirely. It doesn't preserve existing permissions — it ignores them. As a study tip, memorize this hierarchy: Publish to web = public, People in your org = all AAD users, Specific people = named users, Existing access = no new grants. Questions about link scope almost always hinge on whether new permissions are created.

Question 4

A company must share a confidential report with a consultant from another organization. The consultant must authenticate, row-level security must apply, and the report must not become publicly discoverable. The report is hosted in a capacity that supports consumption by eligible free viewers.

Which approach should the company use?

  1. Use Publish to web, send the consultant the generated URL, and rely on row-level security to filter the public report.
  2. Add or invite the consultant as a Microsoft Entra B2B guest, permit external Power BI sharing, and grant the guest report or app access. (correct answer)
  3. Export the report to PDF, store it in a public SharePoint folder, and require the consultant to authenticate to Power BI.
  4. Assign the consultant as a workspace Contributor, because guest users cannot consume reports through direct sharing or apps.
Explanation: When a question asks how to securely share a Power BI report with an external user while enforcing authentication and row-level security, you should immediately think about Microsoft Entra B2B (formerly Azure AD B2B) guest access — the platform's purpose-built mechanism for exactly this scenario. Inviting the consultant as a B2B guest (option B) satisfies every requirement: the guest authenticates with their own organizational credentials, row-level security applies because the user has a verified identity that RLS rules can target, and the report remains private — it never becomes publicly discoverable. When the capacity supports free viewers (such as Premium or Fabric capacity), the guest can consume content without needing a paid Power BI license of their own. Option A is a serious security flaw. Publish to web generates an anonymous, public URL that anyone can access without authentication — RLS does not apply to anonymous embeds, so confidential data would be fully exposed. This violates every constraint in the scenario. Option C fails for multiple reasons: exporting to PDF strips out all dynamic RLS filtering (it captures a static snapshot), and placing the file in a public SharePoint folder means authentication to Power BI is irrelevant — the file itself is publicly accessible. Option D is simply false. Guest users can consume reports through direct sharing, apps, or workspace access. Assigning a guest as a Contributor actually grants more permissions than necessary and is not required for consumption. As a study tip, remember that on Power BI exam questions, "Publish to web" is almost always a trap whenever security, authentication, or confidentiality is mentioned — it is exclusively for fully public, anonymous content.

Question 5

A report is distributed only through a published Power BI app. It has not been shared directly and consumers do not have workspace access. The report is removed from one app audience's content selection in the workspace, but a user in that audience can still see the report in the installed app.

What should the app owner do next?

  1. Remove the user's semantic-model Build permission so that the report disappears from the app.
  2. Refresh the report's semantic model so that audience permissions are recalculated for the app.
  3. Delete the user's cached browser data so that the workspace change becomes effective immediately.
  4. Update the published app so that the revised audience content is distributed to consumers. (correct answer)
Explanation: When working with Power BI apps, you need to understand the two-step publish model: changes made in the workspace do not automatically reach app consumers. The app is a separate, packaged distribution layer — editing the workspace content or audience settings is only the first step. Those changes remain "staged" until the owner explicitly republishes the app. This is exactly what makes D correct. Removing a report from an audience's content selection in the workspace only modifies the draft configuration. To push that change to consumers, the app owner must click Update app, which republishes the app with the revised audience settings. Only after that update will the affected users lose access to the removed report. Choice A is a trap because Build permission governs who can connect to and build content from the semantic model — it has nothing to do with what appears inside a published app for a given audience. Revoking it would not hide the report from the app. Choice B confuses semantic model refresh (which updates data) with permission recalculation. Refreshing the model processes new data rows; it has no effect on app audience configuration or content visibility. Choice C mistakes a browser caching issue for a platform publishing issue. Browser cache affects locally stored web assets, not Power BI's server-side access control. Clearing it would accomplish nothing here. The key study takeaway: on this exam, remember the two-step app lifecycle — configure in workspace, then publish to consumers. Any time a question describes a workspace change that isn't reflected in the app, the answer almost always involves republishing the app.

Question 6

An operations team wants to display a near-real-time Power BI report on monitors at several secured company sites. The report contains confidential production information. Site employees already authenticate with organizational accounts, and access must remain revocable through Power BI.

Which publishing approach should the team use?

  1. Publish to web and restrict knowledge of the public URL to employees who work at the secured sites.
  2. Embed the report in an authenticated service such as SharePoint or Teams and grant users Power BI access. (correct answer)
  3. Export the report to PowerPoint on a schedule and allow site supervisors to control access to the files.
  4. Create an anonymous embed code and apply row-level security roles to the monitor browser sessions.
Explanation: When a question combines secure access, revocability, and organizational accounts, your focus should shift to Power BI's authenticated embedding options rather than any public-facing or file-based distribution method. Embedding the report in an authenticated platform like SharePoint Online or Microsoft Teams (answer B) is the right approach here. Users sign in with their existing organizational accounts, Power BI enforces access control directly, and an administrator can revoke permissions at any time through the Power BI service. The report stays live and near-real-time without manual intervention, which satisfies the operational display requirement perfectly. Answer A fails because "Publish to web" generates a fully public embed code — anyone with the URL can view the report, regardless of organizational membership. Restricting knowledge of a URL is not a security control; it's security through obscurity, which Power BI's own warnings explicitly caution against for confidential data. Answer C abandons Power BI's access management entirely. Exporting to PowerPoint creates static snapshots, loses near-real-time updates, and hands access control to individual supervisors rather than keeping it centralized and revocable through the platform. Answer D is tempting because it mentions row-level security (RLS), but anonymous embed codes bypass authentication entirely. RLS can restrict what data a user sees, but it cannot verify who the user is when there's no login. Combining anonymity with RLS does not create a secure, revocable access model. Study tip: On Power BI exam questions, watch for the word "revocable" — it signals that the correct answer must keep access management inside Power BI's permission system, ruling out any public or file-export approach.

Question 7

A department report must be available to a changing set of employees. The department owner can maintain Microsoft Entra group membership, but individual report recipients must not be able to grant access to coworkers. The Power BI administrator wants to minimize recurring permission changes.

Which sharing design best meets the requirements?

  1. Generate an organization-wide sharing link and rely on employees to limit distribution within the department.
  2. Share the report individually with each employee and grant each recipient permission to manage access for replacements.
  3. Assign the security group the Contributor workspace role so that members can view and distribute report links as needed.
  4. Share the report with a managed security group and disable the option that allows recipients to reshare it. (correct answer)
Explanation: When a question describes access that needs to scale with group membership while preventing recipients from spreading permissions further, you're being tested on Power BI's sharing mechanisms and the principle of least privilege. The scenario has three clear requirements: membership changes are handled externally (via Microsoft Entra/Azure AD groups), individual recipients must not be able to reshare, and the admin wants minimal ongoing maintenance. Sharing a report with a security group satisfies the first and third requirements — when the department owner adds or removes group members, access automatically follows without any Power BI admin involvement. Disabling the reshare option directly addresses the second requirement, preventing recipients from granting access to coworkers. Option D satisfies all three requirements cleanly. Option A fails immediately because an organization-wide link gives everyone in the company potential access, and "relying on employees" to limit distribution is not a technical control — it's wishful thinking. Option B contradicts the requirement that recipients cannot grant access to others; sharing individually and granting "manage access" permission does exactly what the scenario forbids, and it also creates the recurring permission burden the admin wants to avoid. Option C is tempting because it uses a group, but assigning the Contributor workspace role gives members write permissions to the workspace (publishing, editing content), which far exceeds simple report viewing. It also doesn't restrict resharing — Contributors can share workspace content with others. A useful pattern to remember: whenever a Power BI question mentions "minimum admin effort" plus "controlled access," think security groups plus restricted sharing settings. Workspace roles grant workspace-level permissions and are almost always too broad when the goal is read-only report distribution.

Question 8

A salesperson received a report through both a direct share and a Power BI app audience assigned to the Sales-Team Microsoft Entra security group. An administrator removes the salesperson's direct report permission, but the salesperson can still open the report. Other salespeople must retain access.

What additional action is required to revoke the salesperson's effective access?

  1. Remove the salesperson from the Sales-Team group or redesign the group-based app assignment for that user. (correct answer)
  2. Delete the salesperson's Power BI sharing link and republish the report to the existing workspace.
  3. Remove Build permission from the semantic model while retaining the salesperson's app audience membership.
  4. Disable reshare permission for the report while retaining both the direct and group-based assignments.
Explanation: When a user has access to a Power BI report through multiple permission pathways, revoking one pathway doesn't eliminate access if another remains active. This is the core concept being tested: effective access is the union of all permission sources, so you must close every open door. In this scenario, the salesperson retains access because even after the direct share was removed, they still belong to the Sales-Team security group, which has an app audience assignment granting report access. Removing only the direct permission leaves the group-based channel fully intact. To completely revoke access without affecting other salespeople, you must either remove the salesperson from the Sales-Team group, or restructure the app audience so that individual is excluded — making A the correct action. Choice B is a trap. Republishing the report or deleting a sharing link targets the direct-share mechanism, which was already removed. It does nothing to the app audience assignment flowing through the security group. Choice C confuses Build permission (which allows users to create content from a semantic model) with view/access permission to the report itself. Removing Build permission wouldn't prevent the salesperson from opening the report through the app. Choice D addresses resharing rights, which controls whether a user can forward access to others — it has no effect on the salesperson's own ability to view the report. Study tip: On Power BI access questions, always mentally list every permission pathway a user has (direct share, app audience, workspace role, group membership). Effective access persists as long as any single valid pathway remains open — you must eliminate all of them to fully revoke access.

Question 9

A company publishes a Power BI app containing a company dashboard, an operations report, and a confidential finance report. All employees belong to the All-Employees group, and finance employees also belong to the Finance group. Finance employees must see all three items, while other employees must see only the dashboard and operations report.

Which app configuration best meets the requirements with the least administrative overhead?

  1. Create a General audience for All-Employees with the dashboard and operations report, and a Finance audience for Finance with the finance report. (correct answer)
  2. Create one audience for All-Employees containing all three items, and apply row-level security to the confidential finance report.
  3. Grant All-Employees the Viewer workspace role, and directly share the confidential finance report only with the Finance group.
  4. Create one audience for Finance containing all three items, and directly share the dashboard and operations report with All-Employees.
Explanation: When a Power BI app needs to show different content to different groups of users, app audiences are the right tool. An audience is a named group of users assigned a specific set of app items — think of it as a customized "view" of the app per user segment. The goal is to use audiences in a way that's both secure and easy to maintain. The cleanest solution here is A: create a General audience for All-Employees containing the dashboard and operations report, and a separate Finance audience for the Finance group containing all three items. Finance employees see everything they need, other employees never see the confidential report, and the entire setup lives within the app's audience configuration — no extra sharing steps required. B is tempting but flawed. Row-level security (RLS) filters data rows, not entire report pages or items. Applying RLS to a finance report wouldn't hide the report's existence from non-finance employees — they could still open it and see filtered (or empty) data, which is inadequate for a confidential report. C bypasses the app model entirely by using workspace roles and direct sharing. This creates administrative overhead because you're now managing permissions in two separate places, and workspace roles expose more than just reports — they grant access to the entire workspace. D puts all three items in a Finance audience and separately shares the dashboard and operations report with All-Employees. This fragments the experience, requires direct sharing steps, and increases ongoing maintenance. Study tip: On Power BI exam questions, when you see "least administrative overhead" paired with per-group content visibility, audiences are almost always the answer — RLS is for row-level data filtering, not item-level access control.

Question 10

A project manager adds a Power BI report as a tab in a Microsoft Teams channel. Every channel member can open the channel, but several members receive an access-request message when they select the report tab.

What should the project manager do to resolve the issue without granting report-editing rights?

  1. Share the report or its published app with the channel members and give them only consumption access. (correct answer)
  2. Make the channel public so that Teams automatically grants Viewer access to the Power BI workspace.
  3. Republish the report from Power BI Desktop while signed in with the Teams channel owner's account.
  4. Assign the channel members the Contributor role because embedded report tabs require workspace membership.
Explanation: When a Power BI report is embedded as a Teams tab, Teams membership alone does not grant Power BI access. The two platforms have separate permission systems. A user can be a full Teams channel member yet still lack the Power BI license or report permissions needed to view the embedded content — which is exactly what triggers the access-request message. The cleanest fix is A: share the report directly with the affected members, or publish it as a Power BI app and distribute that app to them. Both methods grant view-only (consumption) access, meaning members can read the report without being able to edit, republish, or modify the underlying dataset. This resolves the issue without elevating their privileges. B is incorrect because making a Teams channel public has no effect on Power BI permissions. Power BI does not read Teams channel visibility settings to auto-assign workspace roles — these are entirely separate systems. C is a red herring. Republishing from Desktop doesn't change who has access to the report in the Power BI service. Report permissions are managed in the service itself, not through Desktop publishing accounts. D is wrong because the Contributor workspace role actually does grant editing rights — it allows users to create and modify content in the workspace. The question specifically asks for a solution that avoids granting editing rights, so this directly contradicts the requirement. Study tip: On Power BI exam questions, always watch for the distinction between workspace roles (Admin, Member, Contributor, Viewer) and report/app sharing. Sharing and apps are the right tool for read-only distribution to end users outside your workspace team.