Microsoft Power BI Quiz: Publishing To Service
10 questions · exam conditions
0:00
Publishing To ServiceQuestion 1 of 10

A developer has a Power BI Pro license and is signed in to Power BI Desktop. The developer can open the Finance workspace in the Power BI service but has the Viewer role. The developer must publish a new PBIX file to that workspace without receiving help from a workspace administrator.

What should be changed before the developer attempts to publish?

Assign the developer the Contributor role or a higher workspace role.
Grant the developer Build permission on an existing semantic model.
Share an existing report in the workspace with the developer.
Install an on-premises data gateway on the developer's computer.
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Publishing To Service

Practice Publishing To Service 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 To Service, 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 developer has a Power BI Pro license and is signed in to Power BI Desktop. The developer can open the Finance workspace in the Power BI service but has the Viewer role. The developer must publish a new PBIX file to that workspace without receiving help from a workspace administrator.

What should be changed before the developer attempts to publish?

  1. Assign the developer the Contributor role or a higher workspace role. (correct answer)
  2. Grant the developer Build permission on an existing semantic model.
  3. Share an existing report in the workspace with the developer.
  4. Install an on-premises data gateway on the developer's computer.
Explanation: When a question involves publishing content to a Power BI workspace, you need to think about workspace roles — specifically, which roles grant permission to add or modify content. Publishing a PBIX file to a workspace is considered a content contribution action. In Power BI, workspace roles are tiered: Viewer, Contributor, Member, and Admin. The Viewer role is read-only — it lets someone consume reports and dashboards but does not allow publishing, editing, or adding new content. To publish a PBIX file independently, the developer needs at least the Contributor role, which explicitly grants the ability to publish reports to the workspace. That makes A the correct answer — simply elevating the role from Viewer to Contributor (or higher) resolves the problem without requiring admin intervention on every publish attempt. B is incorrect because Build permission applies to semantic models, allowing users to create new content based on an existing dataset (like connecting in Excel or building a new report). It does not grant the ability to publish a PBIX file into a workspace. C is wrong because sharing a report only gives access to view that specific report — it has no bearing on a developer's ability to publish new content to a workspace. D is a red herring entirely; an on-premises data gateway is used to connect cloud services to on-premises data sources, and has nothing to do with workspace publishing permissions. A useful pattern to remember: whenever a Power BI question involves who can do what inside a workspace, map the action to the minimum required workspace role. Publishing always requires Contributor or above.

Question 2

A developer publishes Sales.pbix to a workspace. A business analyst then edits the published report in the Power BI service. Later, the developer modifies the original PBIX file and publishes it again to the same workspace, accepting the replacement warning.

What should the team expect from the second publication?

  1. The local report and semantic model replace the corresponding published items, potentially overwriting service-side report edits. (correct answer)
  2. Only the semantic model is replaced, while all service-side report edits are merged into the local report.
  3. A second report is created automatically, while the original semantic model remains connected to both reports.
  4. Only changed report pages are uploaded, while the existing semantic model and service edits remain unchanged.
Explanation: When working with Power BI publishing workflows, you need to understand what happens to both the report and the semantic model (dataset) when a PBIX file is republished to the same workspace. This question tests whether you know the difference between local PBIX content and service-side edits made directly in the browser. When a developer publishes a PBIX file to a workspace where a report already exists and confirms the replacement warning, Power BI overwrites both the published report and the semantic model with the local versions from the PBIX file. Any edits the business analyst made to the report directly in the Power BI service — rearranging visuals, adding pages, changing formatting — are lost, because those changes exist only in the service-side copy, not in the developer's local PBIX file. Answer A correctly captures this behavior. Answer B is wrong because Power BI does not selectively preserve service-side report edits or "merge" them with local content — no such merge mechanism exists. Answer C is wrong because republishing to the same workspace replaces the existing items rather than creating a parallel second report; a new report is only created if you publish to a different name or workspace. Answer D is wrong because Power BI publishes the entire PBIX content, not a differential patch — it does not detect and upload only changed pages. As a study tip, remember the phrase "publish replaces both" — republishing always overwrites the full report and semantic model. This is a common team workflow pitfall on the exam, so watch for scenarios where service-side edits are at risk of being lost.

Question 3

A report author publishes a PBIX file to a production workspace. The publication succeeds. However, users who are not workspace members cannot find or open the report.

Which statement best explains the result?

  1. Publishing makes the report discoverable only after a dashboard is created from at least one report visual.
  2. Publishing grants access only after users receive Build permission on the report's semantic model.
  3. Publishing deploys content to the workspace, but access must still be granted by sharing or distributing an app. (correct answer)
  4. Publishing grants access automatically, but users must wait for the next scheduled semantic-model refresh.
Explanation: Whenever you see a question about publishing reports in Power BI, keep the workspace vs. access distinction front of mind. Publishing and sharing are two completely separate actions — one moves content into a workspace, the other determines who can see it. When a report author publishes a PBIX file, Power BI deploys that report and its underlying semantic model into the target workspace. That's it. The workspace itself has its own membership (Admin, Member, Contributor, Viewer roles), but users outside that membership have no visibility into the content. To reach a broader audience, the author must either share the report directly, share the dataset, or — most commonly at scale — bundle workspace content into a Power BI App and publish it to end users. This is exactly what C describes, making it the correct answer. A is incorrect because dashboards have no role in making reports discoverable. Creating a dashboard from report visuals is a design choice, not an access mechanism. B gets closer to real Power BI concepts — Build permission does exist and controls the ability to create new content from a semantic model — but it doesn't grant the ability to view a published report. D is a classic distractor that confuses data freshness with access control; scheduled refresh updates the data, but it has absolutely no bearing on who can open the report. As a study tip, remember this clean mental model: publish = deploy, share/app = distribute. On the exam, any answer that conflates publishing with automatic end-user access is almost certainly a trap.

Question 4

A workspace contains a report that is distributed through a Power BI app. A developer adds a new report page in Power BI Desktop and republishes the PBIX file to the workspace. Workspace members see the new page, but app consumers continue to see the previous version.

What should a workspace administrator or app manager do next?

  1. Update the Power BI app so the revised workspace content is republished to its audience. (correct answer)
  2. Republish the PBIX file from Desktop after changing the report's display name.
  3. Refresh the semantic model so the app reconstructs its report pages from the imported data.
  4. Grant app consumers Contributor access so they can synchronize the workspace report themselves.
Explanation: When working with Power BI apps, it's essential to understand that a workspace and its published app are two distinct layers. The workspace is a collaborative environment where content is built and edited; the app is a curated, packaged snapshot of that content distributed to end users. These two layers do not automatically stay in sync — publishing a new PBIX to the workspace updates the workspace content, but the app remains frozen at whatever version was last explicitly published to consumers. This is exactly why A is correct. After republishing the PBIX, a workspace administrator or app manager must go into the app settings and select "Update app" to push the revised workspace content out to the app's audience. Only then will consumers see the new report page. B is a trap — changing a report's display name and republishing the PBIX has no effect on the app's published state. The app still won't update until it's explicitly republished through the app management interface. C confuses two separate processes. Refreshing the semantic model updates the underlying data, not the report structure or pages. Adding a new report page is a structural change, not a data change, so a dataset refresh does nothing here. D is both incorrect and a security risk. Granting consumers Contributor access would give them edit permissions across the entire workspace — far beyond what's needed, and contrary to the purpose of apps, which are designed to provide read-only, controlled access to specific content. A good rule of thumb: workspace changes require an app republish before consumers ever see them. Think of the app as a separate "publish to audience" step that always follows workspace edits.

Question 5

A consultant belongs to both the consultant's employer tenant and a client's Microsoft Entra tenant. In a browser, the consultant can access the client's workspace as a Member. In Power BI Desktop, selecting Publish shows only workspaces from the employer tenant.

What should the consultant do first?

  1. Save the PBIX file to a folder synchronized with the client's SharePoint Online site.
  2. Open the client's workspace in a browser before selecting Publish again in the existing Desktop session.
  3. Request Build permission on every semantic model already stored in the client's workspace.
  4. Sign out of Desktop and sign back in using the organizational context for the client's tenant. (correct answer)
Explanation: When working across multiple Microsoft Entra tenants in Power BI, the key concept is authentication context. Power BI Desktop signs you into exactly one tenant at a time, and that session determines which workspaces appear when you publish. If Desktop is authenticated against your employer's tenant, it will only surface your employer's workspaces — regardless of what you can access in a browser. The fix is straightforward: sign out of Power BI Desktop entirely and sign back in using your client's organizational account (or the guest account tied to their tenant). Once Desktop's authentication context matches the client's tenant, their workspaces will appear in the Publish dialog. That's why D is correct — it directly resolves the mismatch between where Desktop is authenticated and where the consultant needs to publish. A is a workaround for a different scenario — uploading a file via SharePoint sync doesn't use the Publish workflow and introduces unnecessary complexity. It sidesteps the real problem rather than solving it. B reflects a common misconception: opening a browser session in the client's tenant has no effect on Desktop's authentication context. The two applications maintain completely independent sessions. C addresses dataset permissions, which govern whether you can connect to or build on existing models — it has nothing to do with which workspaces appear in the Publish dialog. As a study tip, remember that Power BI Desktop and your browser are completely separate authentication sessions. Whenever a question describes a mismatch between what you see in Desktop versus a browser, your first instinct should be to check which tenant Desktop is signed into.

Question 6

A developer creates a thin report in Power BI Desktop by using a live connection to a certified semantic model that already exists in the Corporate Data workspace. The developer then publishes the report to the Executive Reports workspace.

What is the expected publishing result?

  1. A report and a complete copy of the certified semantic model are created in Executive Reports.
  2. A report is created in Executive Reports and remains connected to the existing certified semantic model. (correct answer)
  3. Only a semantic model shortcut is created because live-connected reports cannot be published separately.
  4. The certified semantic model is moved to Executive Reports so the report and model share one workspace.
Explanation: When working with live connections in Power BI, the critical concept to understand is workspace separation: a report and its underlying semantic model can live in different workspaces independently. When you publish a thin report built on a live connection to an existing certified semantic model, Power BI is smart enough to keep those two artifacts separate. The report lands in the destination workspace — Executive Reports in this case — while the semantic model stays exactly where it already lives, in the Corporate Data workspace. The published report simply maintains its live connection pointer to the original model. This is actually a deliberate design feature, because it lets organizations centralize governed, certified semantic models while allowing report authors to publish outputs wherever stakeholders need them. Answer B correctly captures this behavior. Answer A is wrong because publishing a live-connected report does not duplicate the semantic model. No copy is created in Executive Reports — the whole point of live connections is to avoid redundant copies of data. Answer C is incorrect because live-connected reports absolutely can be published as standalone reports; there is no restriction that prevents this, and no "shortcut" artifact is created in its place. Answer D is wrong because the semantic model is never moved — it stays in its original workspace. Power BI doesn't relocate certified models during publishing; that would break governance controls and any other reports already depending on it. As a study tip, remember the phrase "reports travel, models stay." On Power BI exam questions involving live connections and workspace publishing, always ask yourself whether the action would affect the semantic model's location — in almost every case, it won't.

Question 7

A PBIX file contains an imported data model and three report pages. No report or semantic model with the same name currently exists in the selected workspace.

After the file is published successfully from Power BI Desktop, which artifacts should normally appear in the workspace?

  1. A report and a semantic model containing the imported data. (correct answer)
  2. A dashboard and a dataflow containing the imported data.
  3. A report and a gateway connection containing the imported data.
  4. A dashboard and a semantic model containing only query definitions.
Explanation: When you publish a PBIX file from Power BI Desktop to the Power BI service, it's important to understand what gets created behind the scenes. Power BI separates your data from your visuals by generating two distinct artifacts: a semantic model (formerly called a dataset) that holds the imported data and its relationships, and a report that contains the visual pages you built. This is exactly what answer A describes, making it the correct choice. Answer B is wrong on both counts. A dashboard is not automatically created during publishing — dashboards are manually assembled in the Power BI service by pinning visuals from reports. A dataflow is a separate ETL artifact you create explicitly in the service; it is never a byproduct of publishing a PBIX file. Answer C incorrectly mentions a gateway connection. A gateway is only relevant when your data source requires on-premises connectivity for scheduled refresh — it's a configuration step, not an artifact that appears in the workspace upon publishing. Answer D is a subtle trap. It mentions a semantic model "containing only query definitions," which describes a DirectQuery or live-connection model. However, the passage specifies an imported data model, meaning the actual data is loaded into memory and stored in the semantic model — not just query definitions. A useful study tip: memorize the publish formula — one PBIX = one report + one semantic model in the workspace. Dashboards are always manual, dataflows are standalone, and gateways are infrastructure — none of these appear automatically when you hit Publish.

Question 8

A PBIX file contains row-level security roles named East and West. The author publishes the file to a new workspace and expects employees to see only their region. No users or groups have yet been assigned to the roles in the Power BI service.

Which action is required to enforce the intended user-to-region mapping?

  1. Grant each employee Build permission and rely on the role definitions imported from the PBIX file.
  2. Republish once for each region while selecting the corresponding role in Power BI Desktop.
  3. Assign the appropriate users or groups to the published semantic model's security roles in the service. (correct answer)
  4. Create separate workspace Viewer roles named East and West and associate them with report pages.
Explanation: When you see a question about row-level security (RLS) in Power BI, remember that there are two distinct phases: defining the roles and assigning users to them. Publishing a PBIX file only completes the first phase — the role definitions travel with the semantic model into the service, but they remain empty containers until someone populates them with actual users or groups. That's exactly what makes C correct. After publishing, an administrator or dataset owner must navigate to the semantic model's security settings in the Power BI service and assign users or groups to the East and West roles. Only then does the service know which employee belongs to which region and can enforce the data filters accordingly. A is a trap because Build permission controls who can connect to or create content from a dataset — it has nothing to do with RLS enforcement. Granting Build access to everyone would actually give them broader data access, not restricted access. B misunderstands how RLS publishing works. You don't republish once per region; the role definitions are already embedded in the PBIX. Republishing repeatedly doesn't assign users — it just overwrites the same model with the same empty roles. D confuses workspace roles with RLS roles. Workspace Viewer is a collaboration permission level that controls access to the workspace itself, not a mechanism for filtering data by region. You cannot create custom-named workspace roles, and they have no connection to report-level data filtering. A useful rule of thumb: defining RLS happens in Desktop; enforcing RLS requires user assignment in the service. Expect the exam to test whether you know both steps exist.

Question 9

A report imports data from an on-premises SQL Server. Refresh works in Power BI Desktop by using the developer's Windows credentials. The developer publishes the PBIX file successfully, but scheduled refresh cannot be enabled for the semantic model.

Which action most directly completes the publishing workflow for scheduled refresh?

  1. Create a dashboard from the report so the service can cache the SQL Server data.
  2. Republish the PBIX file while connected to the corporate network through Windows authentication.
  3. Grant report viewers Build permission so the service can reuse their SQL credentials.
  4. Configure a gateway data source and map the semantic model to it in the service. (correct answer)
Explanation: Whenever you see a question about publishing a Power BI report that connects to on-premises data, your first instinct should be: who handles the connection once the report lives in the cloud? Power BI Desktop runs on your local machine and can use your Windows credentials directly. The Power BI Service, however, runs in Microsoft's cloud and has no path to your corporate network — that bridge must be explicitly built. That bridge is the on-premises data gateway. Configuring a gateway data source and mapping the semantic model to it (answer D) is the required step. The gateway acts as a secure relay between the Power BI Service and your SQL Server, using credentials you register in the gateway configuration. Once mapped, the service can authenticate to SQL Server on a schedule and refresh the data automatically. Without this mapping, the service simply has no way to reach the on-premises source — which is exactly why scheduled refresh is blocked. Answer A is a red herring; creating a dashboard caches visuals for fast loading but does nothing to establish a data connection. Answer B misunderstands where the problem lives — republishing from the corporate network doesn't help because the service still can't reach SQL Server after publishing, regardless of how you were connected when you published. Answer C confuses viewer permissions (which control who can explore the semantic model) with service-level data source credentials (which control how the service authenticates to SQL Server). Study tip: On Power BI exam questions, if the scenario involves on-premises data and the cloud service, the answer almost always involves a gateway. Treat "on-premises + scheduled refresh" as a gateway trigger.

Question 10

A PBIX report uses Import mode to load a cloud-based sales table. The report is published on Monday. On Tuesday, new rows are added to the source, but the PBIX report structure, measures, and queries are unchanged. The published report must display the new rows.

Which action is most appropriate?

  1. Republish the unchanged PBIX file from Power BI Desktop so the service receives the updated source rows.
  2. Refresh the published semantic model manually or through a configured scheduled refresh in the Power BI service. (correct answer)
  3. Update the Power BI app because publishing the app causes the service to reload data from every connected cloud source.
  4. Share the report again with existing users because a new share operation retrieves the latest records from the cloud source.
Explanation: When working with Import mode in Power BI, you need to understand a fundamental concept: the published semantic model holds a snapshot of the source data taken at the moment of the last refresh. The live cloud source and the model are completely decoupled after that snapshot is captured. So when new rows appear in the source, nothing in the service automatically knows about them — you must explicitly trigger a data refresh. That makes B the correct action. Refreshing the semantic model in the Power BI service re-executes the stored queries against the source, pulls in the new rows, and updates the in-memory dataset — all without touching the PBIX file. You can do this manually on demand or configure a scheduled refresh to run automatically on a recurring basis. A is a common trap. Republishing the PBIX file replaces the semantic model definition (queries, measures, schema), but the published file itself contains the same stale snapshot from Monday. You'd still end up with old data unless a refresh is also triggered afterward. Republishing is for structural changes, not data updates. C is incorrect because publishing or updating a Power BI app is a distribution action — it controls which version of reports and dashboards users see. It does not initiate a dataset refresh or pull new rows from any source. D is incorrect because sharing a report is purely a permissions operation. It grants access to existing content; it has no connection to data retrieval from the source whatsoever. Your study tip: whenever a question describes Import mode + new source data, the answer almost always involves refreshing the semantic model, not republishing or redistribution actions.