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

A company uses a shared Power BI workspace for departmental reporting. An analyst must publish new reports, modify existing semantic models, and delete obsolete reports. The analyst must not manage workspace access or control publication of the workspace app.

Which workspace role should you assign to the analyst by using the principle of least privilege?

Admin, because publishing and deleting content require full control of workspace settings
Member, because only Members can modify semantic models and remove obsolete reports
Contributor, because it permits content management without workspace access administration
Viewer, because Build permission can be used to enable publishing and deletion
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Publishing And Workspace Management

Practice Publishing And Workspace 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 Publishing And Workspace 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 company uses a shared Power BI workspace for departmental reporting. An analyst must publish new reports, modify existing semantic models, and delete obsolete reports. The analyst must not manage workspace access or control publication of the workspace app.

Which workspace role should you assign to the analyst by using the principle of least privilege?

  1. Admin, because publishing and deleting content require full control of workspace settings
  2. Member, because only Members can modify semantic models and remove obsolete reports
  3. Contributor, because it permits content management without workspace access administration (correct answer)
  4. Viewer, because Build permission can be used to enable publishing and deletion
Explanation: When a Power BI question mentions "principle of least privilege," your job is to find the role that grants exactly what's needed — nothing more. Start by mapping the required tasks to role capabilities before evaluating the options. The analyst needs to publish reports, modify semantic models, and delete reports — but must not manage workspace access or control the workspace app. The Contributor role covers all three content tasks precisely. Contributors can publish content, edit and update semantic models, and remove reports they or others have added, but they cannot manage membership or publish/configure the workspace app. That restriction is intentional and matches the requirement perfectly, making C the correct answer. A is wrong because the Admin role grants full control, including managing workspace access and app publication — exactly what the analyst must not have. Assigning Admin violates the least-privilege requirement. B is a common trap. The Member role does allow semantic model modification and content deletion, but it also permits updating and publishing the workspace app, which goes beyond what the analyst is authorized to do. Member is one tier too permissive. D is incorrect because Viewer is a read-only role. Build permission on a dataset allows a Viewer to create their own reports in their personal workspace, but it does not grant the ability to publish to the shared workspace or delete existing content. Study tip: Memorize the Power BI workspace role hierarchy — Viewer, Contributor, Member, Admin — as a ladder of expanding permissions. On exam questions, eliminate any role that grants permissions the scenario explicitly forbids, then choose the lowest remaining role that covers all required tasks.

Question 2

A report is included in a published Power BI app. A developer republishes an updated version of the report from Power BI Desktop to the app's workspace. Workspace users immediately see the new version, but app consumers continue to see the previous version.

What should the app owner do to make the revised report available to the app consumers?

  1. Update the app from the workspace so the latest workspace content is published (correct answer)
  2. Refresh the report's semantic model so the app retrieves the revised report definition
  3. Republish the PBIX file with a different report name and remove the existing app
  4. Grant the app consumers Viewer access to the workspace containing the revised report
Explanation: When working with Power BI apps, it's critical to understand that workspaces and apps are two separate layers. A workspace is the development/collaboration environment, while an app is a curated, published snapshot of that workspace's content distributed to end users. Publishing a report to a workspace does not automatically update the app — these are intentionally decoupled so owners can control when consumers see changes. This means A is correct: the app owner must explicitly update the app from the workspace. This action pushes the latest workspace content into the app layer, making the revised report visible to app consumers. It's a deliberate, manual step that gives the owner control over release timing. B is wrong because refreshing the semantic model updates the data the report displays, not the report's structure or definition. Even a fully refreshed model won't surface a republished report to app consumers. C describes an unnecessarily destructive workaround — renaming the report and removing the existing app would break links, disrupt consumers, and create confusion. Power BI's update mechanism exists precisely so you don't need to do this. D is a common trap: granting workspace Viewer access would let consumers see workspace content directly, but this bypasses the app entirely and exposes the full workspace rather than the curated app experience. It also doesn't solve the problem for existing app consumers. Study tip: Memorize the two-step publishing lifecycle — (1) publish to workspace, (2) update the app. Exam questions frequently test whether you understand that workspace changes require a separate app update to reach app consumers.

Question 3

A user can view a report that uses a certified semantic model. The user must create a separate report in Power BI Desktop by connecting to that semantic model. The user must not be able to edit or delete items in the semantic model's workspace.

Which permission should you grant on the semantic model?

  1. Read permission only, because report visibility automatically permits creation of connected reports
  2. Build permission, while leaving the user without an edit-capable workspace role (correct answer)
  3. Write permission, while assigning the user the Viewer role in the workspace
  4. Reshare permission, while retaining the user's existing report-viewing access
Explanation: When working with Power BI semantic models, you need to distinguish between two separate layers of access control: permissions on the semantic model itself and roles within the workspace. These operate independently, which is exactly what this scenario exploits. To create a new report in Power BI Desktop by connecting to an existing semantic model, a user needs Build permission on that model. Build permission is specifically designed for this use case — it lets users construct new reports, dashboards, or dataflows on top of the model without granting any ability to modify the model's underlying data, tables, or structure. That's why B is correct: granting Build permission satisfies the creation requirement, and leaving the user without an edit-capable workspace role (like Contributor, Member, or Admin) ensures they cannot edit or delete anything in the workspace. Answer A is wrong because Read permission alone only allows viewing reports — it does not grant the ability to create new connected reports in Power BI Desktop. Report visibility does not automatically unlock report creation. Answer C is incorrect because Write permission doesn't exist as a standalone semantic model permission in this context, and even if it did, the Viewer role alone wouldn't cleanly address the separation of concerns the scenario requires. Answer D conflates resharing access with creation access — Reshare permission allows a user to grant others access to the model, which is entirely unrelated to building new reports. A useful pattern to remember: on Power BI exam questions, whenever you see "create a report connected to a semantic model," think Build permission — it's the dedicated, least-privilege path for that exact task.

Question 4

A workspace contains Finance and Operations reports. Both departments must use a single published app, but Finance users must not receive access to Operations reports, and Operations users must not receive access to Finance reports. None of the users have workspace roles.

How should you configure the app?

  1. Create one audience, hide each department's unrelated reports, and grant all users app access
  2. Create separate audiences, assign department-specific content, and grant each group its audience (correct answer)
  3. Publish two copies of the app from the workspace and assign one copy to each department
  4. Grant both departments Viewer workspace access and use report navigation to separate their content
Explanation: When a single Power BI workspace needs to serve multiple audiences with different content permissions, the key feature to understand is app audiences. A published app can contain multiple audiences, each with its own curated set of reports and its own user group — this is precisely the mechanism designed for this scenario. Configuring separate audiences (answer B) is the correct approach. You create one audience for Finance users containing only Finance reports, and a separate audience for Operations users containing only Operations reports. Each group receives access only to their designated audience. This enforces content separation at the permission level without requiring separate workspaces or duplicate apps. Answer A is tempting but fundamentally flawed — hiding reports does not secure them. In a single audience with all users, hidden reports can still be accessed via direct URL or API. Hiding is a navigation convenience, not a permission boundary. Answer C misrepresents how Power BI works. You cannot publish two separate copies of an app from the same workspace; a workspace produces one app. Even if this were possible, it would create an administrative burden and synchronization problems, not a clean solution. Answer D is a common trap. Granting Viewer workspace access gives users access to the entire workspace, not just selected reports. This would actually remove the separation you're trying to enforce, since workspace roles apply to all content within it. Study tip: Remember that in Power BI apps, audiences are the correct tool for content segmentation within a single app — they provide true permission-level isolation, whereas hiding or navigation controls only affect visibility, not access.

Question 5

An analyst developed a report and imported semantic model in My workspace. The report is now an official departmental solution. Multiple developers must maintain it, access must be controlled through security groups, and consumers must receive the content through a Power BI app.

What should you do?

  1. Keep the content in My workspace, share the report, and assign individual users Build permission
  2. Publish the report to the web, distribute the generated link, and retain the source in My workspace
  3. Export the report to PDF, store it in SharePoint, and manage access with a department group
  4. Publish the PBIX file to a shared workspace, assign workspace roles, and publish an app (correct answer)
Explanation: When a Power BI solution graduates from a personal project to an official departmental asset, you need to think in terms of three pillars: collaboration, access control, and distribution. My workspace is a personal sandbox — it was never designed for team development or governed content delivery. Publishing the PBIX to a shared workspace (D) solves all three pillars at once. A shared workspace lets multiple developers collaborate on the same report and semantic model. Workspace roles (Admin, Member, Contributor, Viewer) give you granular, security-group-friendly access control. Finally, publishing a Power BI app from that workspace packages the content into a clean, controlled experience for consumers — exactly what the scenario requires. D is the correct path. Option A fails immediately because My workspace cannot be shared with multiple developers, and assigning Build permission to individual users doesn't scale or meet the security-group requirement. It also provides no app-based distribution. Option B — publishing to the web — creates a completely public, unauthenticated link. This is the opposite of controlled access and is inappropriate for any internal departmental solution. Option C exports a static PDF to SharePoint, which strips all interactivity, breaks live data refresh, and turns a Power BI solution into a document management problem. SharePoint groups can't manage Power BI app access anyway. Study tip: On Power BI exam questions, whenever you see the words "multiple developers," "security groups," and "app," that's a checklist pointing directly to a shared workspace + workspace roles + app publish workflow. My workspace is always a trap answer in enterprise scenarios.

Question 6

A scheduled refresh for a semantic model fails after the employee who published and configured it leaves the company. The on-premises data gateway is online, and the workspace administrator has verified that a gateway data source exists. The administrator cannot update the stored credentials while the former employee remains the semantic model owner.

Which sequence of actions should the administrator perform?

  1. Delete the semantic model, retain its reports, and reconnect them to the gateway data source
  2. Republish the report only, restart the gateway service, and reuse the former owner's credentials
  3. Change the workspace contact, refresh the app, and assign Build permission to the administrator
  4. Take over the semantic model, map it to the gateway data source, and update its credentials (correct answer)
Explanation: When a semantic model's owner leaves an organization, Power BI preserves a critical security boundary: only the owner can update stored credentials for that model. This means scheduled refresh breaks not because of a gateway problem, but because of an ownership and credential problem. Recognizing this distinction is key to answering questions like this one. The correct sequence in D directly resolves the root cause. First, the administrator takes ownership of the semantic model — Power BI allows workspace admins to do this without the original owner's involvement. Once ownership transfers, the admin gains full control, can map the model to the correct gateway data source, and finally update the stored credentials so scheduled refresh resumes. Each step unlocks the next; the order matters. A is a destructive workaround that doesn't solve the real problem. Deleting the semantic model to "retain its reports" is risky and unnecessary — reports lose their data connection, and you'd still need to reconfigure credentials anyway. Nothing about this approach is cleaner or faster than D. B is wrong on multiple levels. Republishing a report file doesn't transfer semantic model ownership or fix credentials. Restarting the gateway service addresses infrastructure, not permissions. Using a former employee's credentials violates security policy and is typically impossible once their account is disabled. C confuses workspace-level settings with semantic model ownership. Changing the workspace contact and assigning Build permission are governance actions unrelated to fixing a broken credential chain on a specific semantic model. Study tip: On Power BI exam questions involving refresh failures, always diagnose whether the issue is gateway infrastructure or ownership/credentials — the fix is completely different for each.

Question 7

A semantic model has row-level security roles for the East and West regions. Regional managers currently have the Contributor role in the workspace and are also assigned to the appropriate row-level security roles. Testing shows that the managers can view data for both regions. The managers only need to consume a published app.

What should you do to enforce row-level security while applying least privilege?

  1. Change each manager to the Member role and retain the existing security-role assignments
  2. Remove workspace access and grant each manager access to the appropriate app audience (correct answer)
  3. Retain the Contributor role and disable Build permission on the underlying semantic model
  4. Change each manager to the Admin role and configure the app to hide unrelated reports
Explanation: When dealing with row-level security (RLS) in Power BI, always think about two separate layers: workspace roles and RLS roles. The critical rule is that workspace roles of Contributor, Member, or Admin bypass RLS entirely — users with these roles can see all data regardless of their RLS assignments. RLS only enforces on users who access content through a published app or who have direct dataset access without an elevated workspace role. Because the managers only need to consume a published app (not build or edit content), the correct fix is B: remove their workspace access and grant them access through the appropriate app audience. This strips their elevated workspace permissions, meaning RLS kicks in and restricts their data view to the correct region. It also follows least privilege — they get exactly what they need and nothing more. A is wrong because changing managers to the Member role still grants a workspace role that bypasses RLS. They'd still see all regional data, so the problem isn't solved. C is wrong because disabling Build permission controls whether users can create new reports on top of the dataset — it does nothing to enforce RLS for users who already have Contributor-level workspace access. D is wrong because promoting managers to Admin actually increases their privilege, which is the opposite of least privilege, and hiding reports in the app doesn't restrict underlying data access. Study tip: Remember this pattern — if a question mentions RLS not working, check whether users have a workspace role above Viewer. Elevated workspace roles always override RLS in Power BI.

Question 8

A deployment pipeline contains Development, Test, and Production workspaces. A semantic model uses a text parameter named ServerName. The Development value must remain dev-sql, while deployments to Test must use test-sql without manually editing the semantic model after every deployment.

What should you configure before deploying the semantic model from Development to Test?

  1. A parameter deployment rule in the Test stage that changes ServerName to test-sql (correct answer)
  2. A parameter deployment rule in the Development stage that changes ServerName to test-sql
  3. A scheduled refresh in the Test workspace that substitutes test-sql during processing
  4. A workspace contact in the Test stage that is associated with the test-sql server
Explanation: When you see a question about deployment pipelines in Power BI, focus on where deployment rules are configured and when they take effect. A deployment rule is applied to a target stage — it tells Power BI what to substitute in the destination workspace when content arrives there. A parameter deployment rule set on the Test stage intercepts the incoming semantic model and replaces the ServerName parameter value with test-sql automatically. This means the Development workspace keeps dev-sql untouched, and every time you deploy to Test, the substitution happens without any manual editing. That makes A the correct answer. B is wrong because placing the rule on the Development stage would attempt to change the value in the source workspace, not the destination. Deployment rules govern what happens when content lands in a stage, not what leaves the previous one — and this would corrupt your Development environment's intended value. C is a misconception about what scheduled refresh does. Refresh re-loads data from the source; it has no mechanism to substitute parameter values. You cannot use it as a workaround for pipeline configuration. D describes a workspace contact, which is simply an administrative setting for identifying who manages a workspace. It has no connection to server name resolution or parameter overrides. Study tip: Always remember that in Power BI deployment pipelines, rules are configured on the receiving stage, not the sending stage. A quick memory trick: the rule lives where the content is going, not where it came from.

Question 9

A workspace contains a report and imported semantic model originally published from Sales.pbix. Several other reports connect to this semantic model. A developer removes a column from the model, modifies the original report, and republishes Sales.pbix to the same workspace using the existing item names.

What is the expected result if the developer confirms the replacement prompt?

  1. Only the report definition is replaced, because connected reports prevent replacement of the semantic model
  2. A second report and semantic model are created automatically with versioned names
  3. The report and semantic model are replaced, and dependent reports may fail if they use the removed column (correct answer)
  4. Only the semantic model is replaced, while the original report retains its previous visual definitions
Explanation: When you publish a Power BI file (.pbix) to a workspace where a report and semantic model with the same names already exist, Power BI prompts you to confirm whether you want to replace them. Understanding what "replace" actually means here is the core of this question. When you confirm the replacement, Power BI overwrites both the existing report and the existing semantic model with the new versions from the republished file. This is the publish-overwrite behavior — it's an in-place replacement, not a duplication. Because the semantic model is replaced, any other reports in the workspace that connect to it via a live connection now point to the updated model. If those dependent reports reference a column that the developer removed, they will break — visuals, filters, or measures relying on that column will return errors. So option C correctly describes the outcome: both artifacts are replaced, and downstream reports are at risk. Option A is wrong because Power BI does not protect the semantic model from replacement just because other reports depend on it — it replaces both items without regard for downstream dependencies. Option B is wrong because Power BI does not auto-create versioned duplicates; that would only happen if you published to a different name or location. Option D is wrong because the original report is also overwritten — you cannot replace just the semantic model while keeping the old report definition intact through a standard republish. As a study tip, remember that in Power BI, republishing to the same workspace with the same names is a destructive overwrite of both artifacts — always audit dependent reports before removing model columns to avoid breaking connected content.

Question 10

A Power BI app is stored in a workspace assigned to shared capacity. The app owner has a Power BI Pro license. Most intended consumers have free licenses and currently receive a licensing prompt when they open the app. The organization wants the consumers to view the app without purchasing individual Pro licenses.

Which action should you take?

  1. Move the workspace to an eligible Premium or Fabric capacity and retain the users' app access (correct answer)
  2. Assign the app owner a Premium Per User license and retain the workspace in shared capacity
  3. Grant the consumers Build permission on each semantic model included in the published app
  4. Change the consumers to workspace Viewers while leaving the workspace in shared capacity
Explanation: When you see a question about licensing and app consumption in Power BI, focus on one key rule: free-license users can only consume published apps without a prompt when the workspace hosting that app sits on Premium or Fabric capacity. Shared capacity requires every consumer to hold at least a Pro license. That's exactly why A is correct. Moving the workspace to a Premium capacity (Premium per capacity, Fabric F-SKU, etc.) unlocks the ability for free-license users to view published apps with no individual Pro requirement — as long as their existing app access permissions remain intact. This is the designed solution for broad, cost-effective distribution. B is a common trap. Premium Per User (PPU) is a per-person license, not a capacity license. It elevates what that individual can do, but it does not extend consumption rights to free-license users viewing content in a shared workspace. The workspace itself still needs a capacity upgrade for free users to benefit. C is a permissions solution, not a licensing solution. Build permission allows users to create new content from a semantic model, but it does nothing to satisfy the licensing requirement for viewing a published app. Free users will still hit the licensing prompt. D is another permissions-only approach. Making consumers workspace Viewers gives them a role within the workspace, but the workspace remains on shared capacity — so free-license users still cannot view content without a Pro license. Study tip: Always separate permissions (who can see/build what) from capacity licensing (what infrastructure enables free-user consumption). Exam questions often mix the two to test whether you understand that both must be correct simultaneously.