Microsoft Power BI Quiz: Using Shared Datasets
10 questions · exam conditions
0:00
Using Shared DatasetsQuestion 1 of 10

A user can view reports that use the Finance semantic model but cannot find the model when attempting to create a new report from the OneLake data hub. The user must be able to author reports from the model but must not modify or refresh the model.

Which permission should you grant the user?

The Reshare permission on the Finance semantic model, without changing the user's workspace role.
The Write permission on the Finance semantic model, without granting access to its workspace.
The Build permission on the Finance semantic model, while retaining read-only model access.
The Contributor role in the Finance workspace, while disabling semantic model downloads.
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Using Shared Datasets

Practice Using Shared Datasets 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 Using Shared Datasets, 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 user can view reports that use the Finance semantic model but cannot find the model when attempting to create a new report from the OneLake data hub. The user must be able to author reports from the model but must not modify or refresh the model.

Which permission should you grant the user?

  1. The Reshare permission on the Finance semantic model, without changing the user's workspace role.
  2. The Write permission on the Finance semantic model, without granting access to its workspace.
  3. The Build permission on the Finance semantic model, while retaining read-only model access. (correct answer)
  4. The Contributor role in the Finance workspace, while disabling semantic model downloads.
Explanation: When working with Power BI semantic models, it helps to distinguish between consuming a model (viewing reports built on it) and authoring new content from it. These require different permission levels, and the exam tests whether you understand that gap. The scenario tells you the user can already view reports — meaning they have Read access — but they cannot discover or connect to the Finance model from the OneLake data hub to build their own reports. The missing piece is the Build permission. Build grants the ability to create new reports, export underlying data, and use the model in tools like Excel or Dataflows, all without allowing the user to edit the model's structure or trigger refreshes. That makes option C exactly right: it closes the authoring gap while preserving read-only access to the model itself. Option A is a trap — Reshare simply lets a user grant others the permissions they already have. It does nothing to enable report creation. Option B is tempting because Write sounds powerful, but Write permission on a semantic model allows editing and publishing changes to the dataset, which directly violates the requirement to prevent model modification. It also introduces unnecessary risk. Option D goes too far in the other direction: granting a Contributor workspace role gives the user the ability to publish, edit, and delete content across the entire workspace, far exceeding what's needed and potentially breaking the "must not modify the model" constraint. A useful rule of thumb: whenever a question asks for the minimum permission to create reports from a model without modifying it, Build is almost always the right answer. Memorize that Build = author reports, Write = change the model.

Question 2

A thin report contains no imported tables and connects to a shared Operations semantic model. The report owner notices that yesterday's transactions are missing. The Operations model is configured for scheduled import refresh and is owned by another team.

Which action most directly addresses the missing transactions?

  1. Configure a separate scheduled refresh for the thin report so that it imports the latest model data.
  2. Verify and run the refresh of the shared Operations semantic model, then reopen or refresh the report. (correct answer)
  3. Republish the thin report so that its cached copy of the source tables is replaced with current data.
  4. Convert the report to a composite model so that report visuals can initiate source-system refreshes.
Explanation: When working with Power BI's shared semantic model architecture, the key distinction to understand is where data actually lives. A thin report (also called a live connection report) contains no imported data of its own — it queries the shared semantic model directly. This means the report's data freshness is entirely dependent on when that underlying semantic model was last refreshed, not on anything the report itself controls. Because of this, when yesterday's transactions are missing, the root cause is almost certainly a stale or failed refresh of the Operations semantic model — and that's exactly what answer B targets. Verifying and running the semantic model's refresh updates the actual data store, and reopening or refreshing the report will then reflect the current data immediately. Answer A is a fundamental misconception: thin reports don't import data, so scheduling a "refresh" on the report itself has no effect on the underlying data. There's nothing to refresh on the report side. Answer C falls into the same trap — thin reports have no cached copy of source tables to replace. Republishing simply redeploys the same connection; it doesn't move any data. Answer D converts the architecture to something more complex (composite models) and still doesn't resolve the immediate problem — it would require significant redesign and doesn't fix yesterday's missing transactions today. A useful rule of thumb: on Power BI exam questions, always trace the data flow back to its source. If a report uses a shared semantic model, any data freshness issue belongs to the semantic model's refresh pipeline, not the report layer.

Question 3

A semantic model has row-level security roles for the East and West regions. Morgan is assigned to the West role, has Read and Build permissions on the model, and has no Admin, Member, or Contributor role in the model's workspace. Morgan creates a personal report from the model.

Which data should Morgan see when viewing the new report?

  1. All regions, because Build permission permits unrestricted queries while a report is being authored.
  2. No regions, because row-level security prevents users with Build permission from creating reports.
  3. Only the West region, because row-level security remains enforced when Morgan queries the shared model. (correct answer)
  4. East and West regions, because personal reports do not inherit security roles from shared semantic models.
Explanation: Whenever you see a Power BI question involving row-level security (RLS) and shared semantic models, the core principle to hold onto is this: RLS is enforced at the model level, not the report level. It doesn't matter how a user accesses the model — through a published report, a personal report, or a direct query — the security roles assigned to that user travel with them. Morgan is assigned to the West role, so every query Morgan runs against the model returns only West region data. This makes C correct. The personal report Morgan creates is simply a lens into the semantic model; it doesn't bypass or reset the security context. Morgan will only ever see West region data, regardless of how the report was built or where it lives. A is wrong because it confuses the Build permission's purpose with its security implications. Build permission allows a user to create new reports, composite models, or exports on top of a semantic model — it says nothing about lifting RLS restrictions. Those are entirely separate concerns. B is wrong in the opposite direction. Build permission absolutely allows report creation; RLS doesn't block authoring. It only filters which data is returned. Morgan can build a report just fine — she just won't see East region data in it. D is wrong because it invents a distinction that doesn't exist. Personal reports inherit the same RLS context as any other report connected to that semantic model. There is no special "personal report exemption" from row-level security. Your study tip: think of RLS as a filter baked into the model itself — no permission level, report type, or workspace role overrides it.

Question 4

A semantic model is certified, but employees who do not already have access cannot find it when searching for organizational semantic models. Governance requires employees to discover the model and submit an access request, but they must not receive data access automatically.

Which configuration should you use?

  1. Grant Build permission to the entire organization and rely on certification to restrict unauthorized queries.
  2. Publish the model in an organizational app and assign every employee to the app's audience.
  3. Enable public web publishing for the model and direct employees to request access from the report owner.
  4. Make the endorsed semantic model discoverable and configure the model's access-request instructions or workflow. (correct answer)
Explanation: When a question describes a need to let employees find a dataset without automatically receiving data access, you're being tested on Power BI's discoverability and access-request features — two separate controls that work together. Power BI allows endorsed (promoted or certified) semantic models to be marked as discoverable, meaning users can find them in the data hub even without existing permissions. Crucially, discoverability alone doesn't grant any data access. You can pair this with a configured access-request workflow — such as a custom message, a link to a form, or a specific contact — so users know exactly how to request access. This is precisely what option D describes, making it the correct configuration. Option A is flawed because granting Build permission to the entire organization immediately gives everyone the ability to query and build reports on the data — that's automatic data access, which directly violates the governance requirement. Option B also grants access automatically. Publishing to an organizational app and assigning all employees to the audience means every employee can consume the content from the moment they open the app — no request workflow involved. Option C introduces public web publishing, which is a feature designed for embedding reports on public websites. It exposes data to anyone on the internet, which is a serious security risk and completely misaligned with a controlled, internal governance process. The key study tip here: on Power BI governance questions, always separate discoverability (can users find it?) from access (can users read the data?). The exam frequently tests whether you understand that these are independent settings — finding a model should never automatically mean accessing it.

Question 5

A report is live-connected to a shared Inventory semantic model. The report author must add a small Excel table containing locally maintained reorder targets and relate it to a product table from the shared model. The existing semantic model cannot be modified.

Which approach should the report author use?

  1. Export the shared model's data to Excel, combine it with the targets, and import the combined file into a new model.
  2. Create a dataflow from the Excel file, because a live-connected report automatically relates dataflow entities to remote tables.
  3. Add the Excel file to the shared model's refresh settings, and define the relationship within the report canvas.
  4. Select Make changes to this model, add the Excel table, and create a composite model with a local relationship. (correct answer)
Explanation: When a report has a live connection to a shared semantic model that you cannot edit, the challenge is extending it with local data without breaking the connection or requiring model changes. This scenario tests your understanding of composite models in Power BI. The right move is D: selecting Make changes to this model upgrades your live connection into a composite model. This lets you import the Excel table locally, then draw a relationship between that local table and the remote product table from the shared model — all within the same report, without touching the original semantic model. The result is a hybrid model where some tables come from the remote source and others are stored locally. A is a dead end because exporting and recombining data creates a completely separate, static import model. You lose the live connection entirely, which defeats the purpose and creates maintenance overhead. B describes a feature that simply doesn't exist — live-connected reports do not automatically relate dataflow entities to remote tables. Dataflows are a staging layer, not a magic bridge for relationships. C is doubly wrong: you cannot add an external file to a shared model's refresh settings from inside a report, and relationships cannot be defined on the report canvas — they must exist in the data model layer. A good study tip: whenever a question mentions a live connection plus a need to add local data, your immediate instinct should be "composite model." The phrase "shared model cannot be modified" is a signal that option D — not exporting or reshaping data elsewhere — is the clean, supported path.

Question 6

A report in the Executive workspace uses a semantic model in the Finance workspace. Executives need only to view and interact with the report. After the report is shared, they can open the report shell but receive an error indicating that the underlying semantic model cannot be accessed.

What should you do while following the principle of least privilege?

  1. Grant the executives Read access to the Finance semantic model and preserve any applicable row-level security assignments. (correct answer)
  2. Grant the executives Build access to the Finance semantic model and make them Contributors in the Executive workspace.
  3. Grant the executives the Member role in the Finance workspace and remove row-level security from the model.
  4. Publish a duplicate Finance semantic model to the Executive workspace and redirect the report to that copy.
Explanation: When a user can see a report but gets an error loading its data, the issue is almost always semantic model permissions, not workspace membership. Power BI separates report access from data access — opening a report shell requires workspace or sharing permissions, but querying the underlying data requires explicit permission on the semantic model itself. The fix is granting Read access to the Finance semantic model, which is exactly what option A prescribes. Read access lets users query the model's data without giving them any authoring rights. Critically, A also preserves row-level security (RLS), which restricts which rows each user sees — this is how "least privilege" is enforced at the data level. Executives get exactly what they need: the ability to view report data, filtered appropriately. Option B is too permissive. Build access lets users create new reports, export underlying data, and connect external tools to the model — none of which executives need just to view a report. Making them Contributors in the Executive workspace adds unnecessary write permissions on top of that. Option C violates least privilege in two ways: the Member role grants broad workspace permissions far beyond viewing, and removing RLS eliminates data-level security restrictions entirely — a significant security risk. Option D creates maintenance overhead and data governance problems. Duplicating a semantic model means two copies of truth, synchronization challenges, and wasted capacity — all avoidable with a simple permission grant. Your study tip: on Power BI permission questions, always distinguish workspace roles (govern workspace content management) from semantic model permissions (govern data access). Most "least privilege" scenarios want the narrowest semantic model permission that solves the problem.

Question 7

A sales analyst must create a new report by using an existing certified semantic model in the Power BI service. The report must use the model's existing relationships, measures, and row-level security rules. The analyst must not create another copy of the model.

Which action should the analyst take in Power BI Desktop?

  1. Import the model's source tables by using the SQL Server connector, and then recreate its relationships and measures.
  2. Select Get data > Power BI semantic models, connect to the certified model, and build a thin report. (correct answer)
  3. Download the semantic model as a PBIX file, rename the file, and publish it as a separate model.
  4. Create a blank import model, connect to each published report, and copy the required visual definitions.
Explanation: When you see a scenario involving reusing an existing certified semantic model without duplicating it, think about Power BI's live connection and shared dataset architecture. The key constraints here are: inherit existing relationships, measures, and RLS — and create zero additional copies of the model. Connecting via Get data > Power BI semantic models in Power BI Desktop establishes a live connection to the published certified model. This means your report reads directly from that model — all measures, relationships, and RLS rules are automatically inherited. You build a "thin report," meaning only the report layer (.pbix without embedded data) is published back to the service. This is exactly what option B describes, making it the correct choice. Option A fails on multiple levels: importing source tables via SQL Server recreates the entire data model from scratch, producing a duplicate and requiring you to manually rebuild relationships and measures — directly violating the stated requirements. Option C is equally problematic; downloading the model as a PBIX and republishing it creates a separate, independent copy of the model, which the analyst is explicitly told not to do. This approach also risks losing certified status and diverging from the original. Option D is a nonsensical approach — you cannot connect to published reports to copy visual definitions in a way that inherits a model's RLS or measures, and this creates no structured semantic connection at all. As a study tip: on Power BI exam questions, whenever you see the phrase "must not create another copy of the model," immediately look for the live connection to a Power BI semantic model option — that's the architectural pattern designed precisely for this scenario.

Question 8

Fifteen thin reports connect to a shared Sales semantic model. The source system confirms that shipping revenue is omitted from the model's Net Revenue measure. All fifteen reports must use the corrected definition, and future reports must inherit the same calculation.

What should you do?

  1. Correct Net Revenue in the shared semantic model, validate downstream dependencies, and republish or deploy the model. (correct answer)
  2. Create a replacement measure in each thin report, and hide the original measure in every report.
  3. Add a Power Query transformation to each thin report, and calculate shipping revenue during report refresh.
  4. Copy the shared model into each report workspace, and correct the measure separately in every copied model.
Explanation: When you see a question about fixing a shared semantic model in Power BI, think about the single source of truth principle. A shared semantic model (a published dataset) exists precisely so that many reports can consume a single, centrally managed set of measures. Your corrective action should happen at that central source, not scattered across consumers. Fixing Net Revenue directly in the shared semantic model — then validating that downstream thin reports still connect and render correctly before republishing — is exactly what option A prescribes. Because all fifteen reports connect to this one model, a single correction automatically propagates to every report. Future reports that connect to the same model will inherit the corrected definition without any extra work. That's the architectural advantage of a shared semantic model, and A leverages it fully. Option B is a classic trap: creating a replacement measure in each thin report means duplicating logic across fifteen files. This is error-prone, inconsistent, and defeats the purpose of a shared model. Hiding the original measure doesn't eliminate it or prevent its accidental use. Option C misunderstands the problem — shipping revenue is missing from a measure, not from the underlying data loaded via Power Query. Applying a Power Query transformation wouldn't fix a DAX calculation, and doing it fifteen times is redundant anyway. Option D is the worst approach: copying the model into each report workspace destroys the shared model architecture entirely, creates fifteen separate maintenance burdens, and ensures future drift between definitions. Study tip: On Power BI exam questions, whenever a change must be inherited by multiple reports simultaneously, the correct action almost always targets the shared semantic model, not the individual reports consuming it.

Question 9

A model owner plans to rename the Customer Segment field in a widely shared semantic model. Several reports are maintained by teams in other workspaces, and the owner does not know which reports use the field.

What should the owner do before making the change?

  1. Rename the field immediately because live-connected reports automatically rewrite every visual and expression that references it.
  2. Review lineage and impact information, contact affected owners, and coordinate the schema change before deployment. (correct answer)
  3. Disable scheduled refresh because schema changes can affect reports only while the semantic model is refreshing.
  4. Remove Build permission from report authors because doing so converts dependent reports into independent models.
Explanation: When a semantic model is shared across multiple workspaces, schema changes like renaming a field can silently break reports that reference it — visuals may go blank, measures may fail, and report authors may not even know why. This question is testing your understanding of change management and impact analysis in Power BI's shared dataset ecosystem. The right approach, captured in B, is to use Power BI's built-in lineage view and impact analysis tools before touching anything. These features show you exactly which reports, dashboards, and dataflows depend on the semantic model. From there, you reach out to affected report owners, coordinate a transition window, and deploy the rename only after stakeholders are prepared. This protects downstream consumers and maintains trust in shared infrastructure. A is a dangerous misconception — live-connected reports do not automatically rewrite field references. If a visual or DAX expression hard-references "Customer Segment" by name, renaming the field breaks that reference immediately, and nothing fixes it automatically. C misunderstands what scheduled refresh does. Refresh pulls fresh data into the model; it has no role in managing schema changes or protecting reports from them. Disabling refresh wouldn't shield any report from a renamed field. D describes a real Power BI concept — removing Build permission does affect what users can do with a dataset — but it does not convert dependent reports into independent models. Reports remain connected, and the action would restrict authors rather than protect them. As a study tip: on Power BI governance questions, always think about who gets notified and when. Lineage and impact analysis exist precisely to answer "what breaks if I change this?"

Question 10

A developer creates a PBIX file that contains only report pages and a live connection to a published Human Resources semantic model. The developer publishes the file to a different workspace. The organization wants to avoid another copy of the Human Resources data and model logic.

What is the expected result of publishing the file?

  1. A new imported semantic model is created by copying all tables, relationships, and measures from Human Resources.
  2. A new dataflow is created to refresh Human Resources data independently for the published report.
  3. A thin report is created and remains connected to the existing Human Resources semantic model. (correct answer)
  4. A paginated report is created and embeds a static snapshot of the Human Resources semantic model.
Explanation: When working with live connections in Power BI, understanding the difference between a thin report and a full semantic model is essential. A live connection means the PBIX file contains no local data or model — it simply points to an existing published semantic model. When you publish such a file, Power BI recognizes this and handles it differently than a file with imported data. Because the developer's PBIX file contains only report pages and a live connection, publishing it creates a thin report — a report artifact that remains bound to the already-published Human Resources semantic model. No new semantic model is generated in the destination workspace. This is exactly what the organization wants: one copy of the data and model logic, shared across reports. Answer C correctly describes this outcome. Answer A is wrong because a new imported semantic model would only be created if the PBIX contained imported or DirectQuery tables with their own model. Since there's no local model here, nothing gets copied. Answer B is incorrect because dataflows are a separate Power BI artifact used for data preparation and ETL — publishing a thin report has no relationship to dataflow creation. Answer D is a trap that confuses report types: paginated reports (.rdl files) are a distinct format built in Power BI Report Builder, not a PBIX with a live connection, and they don't embed static snapshots in this way. As a study tip, remember that live connection = thin report on publish. Whenever a question mentions a PBIX with only a live connection, expect that publishing it creates a report artifact only — never a new semantic model.