- Which data should Morgan see when viewing the new report?
Answer: Only the West region, because row-level security remains enforced when Morgan queries the shared model.
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.
- What is the expected result of publishing the file?
Answer: A thin report is created and remains connected to the existing Human Resources semantic model.
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.
- What should the owner do before making the change?
Answer: Review lineage and impact information, contact affected owners, and coordinate the schema change before deployment.
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?"
- Which configuration should you use?
Answer: Make the endorsed semantic model discoverable and configure the model's access-request instructions or workflow.
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.
- What should you do?
Answer: Correct Net Revenue in the shared semantic model, validate downstream dependencies, and republish or deploy the model.
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.
- Which permission should you grant the user?
Answer: The Build permission on the Finance semantic model, while retaining read-only model access.
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.
- What should you do while following the principle of least privilege?
Answer: Grant the executives Read access to the Finance semantic model and preserve any applicable row-level security assignments.
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.
- Which approach should the report author use?
Answer: Select Make changes to this model, add the Excel table, and create a composite model with a local relationship.
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.
- Which action most directly addresses the missing transactions?
Answer: Verify and run the refresh of the shared Operations semantic model, then reopen or refresh the report.
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.
- Which action should the analyst take in Power BI Desktop?
Answer: Select Get data > Power BI semantic models, connect to the certified model, and build a thin report.
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.
