Microsoft Power BI Quiz: Datasets Dataflows And Semantic Models
10 questions · exam conditions
0:00
Datasets Dataflows And Semantic ModelsQuestion 1 of 10

Two analytics teams use the same sales source. Both teams must standardize product codes, remove invalid orders, and derive fiscal-period columns. However, each team requires different relationships, DAX measures, and row-level security rules.

Which architecture best minimizes duplicated data preparation while supporting the teams' different analytical requirements?

Create one shared dataflow for the standardized tables, then create a separate semantic model for each team.
Create one shared semantic model containing all measures, then create a separate dataflow for each team.
Create one report for each team and repeat the transformations in each report's Power Query queries.
Create one dashboard containing standardized data, then connect each team's semantic model to the dashboard.
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Datasets Dataflows And Semantic Models

Practice Datasets Dataflows And Semantic Models 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 Datasets Dataflows And Semantic Models, 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

Two analytics teams use the same sales source. Both teams must standardize product codes, remove invalid orders, and derive fiscal-period columns. However, each team requires different relationships, DAX measures, and row-level security rules.

Which architecture best minimizes duplicated data preparation while supporting the teams' different analytical requirements?

  1. Create one shared dataflow for the standardized tables, then create a separate semantic model for each team. (correct answer)
  2. Create one shared semantic model containing all measures, then create a separate dataflow for each team.
  3. Create one report for each team and repeat the transformations in each report's Power Query queries.
  4. Create one dashboard containing standardized data, then connect each team's semantic model to the dashboard.
Explanation: When designing a Power BI architecture for multiple teams sharing the same source data, the key principle is separation of concerns: centralize what's common, isolate what's different. Ask yourself — what do the teams share, and what is unique to each? The teams share data preparation logic (standardizing product codes, removing invalid orders, deriving fiscal columns). They differ in relationships, DAX measures, and row-level security. This maps perfectly to Power BI's layered architecture: dataflows handle reusable transformation logic, while semantic models encapsulate team-specific analytical structures. Answer A implements this correctly — one shared dataflow eliminates duplicated Power Query transformations, and each team gets its own semantic model to define the relationships, measures, and RLS rules they need independently. Answer B inverts the logic fatally. A single shared semantic model cannot simultaneously satisfy conflicting relationship structures and RLS rules for both teams without creating an overly complex, unmanageable model — and separate dataflows would still duplicate transformation logic rather than centralizing it. Answer C is the worst option architecturally. Repeating transformations in each report's Power Query means maintenance doubles immediately: any source change must be fixed in every report individually, violating the DRY (Don't Repeat Yourself) principle that Power BI dataflows exist to solve. Answer D misidentifies dashboards as a data-layer component. Dashboards in Power BI are visualization surfaces that pin tiles from reports — they cannot serve as a shared data source for semantic models. A useful rule of thumb: dataflows = shared transformation layer, semantic models = team-specific analytical layer. When you see questions about multi-team architectures, map each requirement to the correct layer first.

Question 2

After a Power BI service update, an administrator notices that an item previously labeled as a dataset is now labeled as a semantic model. The administrator plans a migration because reports are still connected to the item.

What should you tell the administrator?

  1. The item must be migrated to a dataflow before existing reports can continue querying its tables and measures.
  2. The item must be republished from Power BI Desktop because semantic models use a different storage format.
  3. The terminology changed; the existing item remains the modeling layer used by the connected reports. (correct answer)
  4. The terminology changed only for DirectQuery items; imported datasets must still be converted manually.
Explanation: When Microsoft rebrands a feature in Power BI, it's worth asking: did anything functional change, or just the name? That distinction is exactly what this question tests. In a recent Power BI service update, Microsoft renamed "datasets" to "semantic models." This was purely a terminology change — no migration, republishing, or conversion is required. The item you see labeled "semantic model" is the exact same artifact that was previously called a dataset. It still serves as the modeling layer containing tables, relationships, and measures, and all reports already connected to it continue working without any intervention. C is correct: the label changed, the functionality did not. Answer A is wrong because dataflows are a separate concept entirely — they handle data ingestion and transformation (ETL), not the modeling layer that reports query directly. Migrating to a dataflow would actually break the existing report connections, not preserve them. Answer B is incorrect because the storage format did not change. Semantic models use the same underlying format as datasets; republishing from Power BI Desktop would be unnecessary work and implies a structural difference that simply doesn't exist. Answer D introduces a false distinction — the rename applies universally across all connectivity modes (Import, DirectQuery, Live Connection, etc.), not exclusively to DirectQuery items. No manual conversion of imported datasets is required. A useful study tip for the Power BI exam: when you see questions referencing a "new" feature name alongside an "old" one, first ask whether the change is cosmetic (terminology only) or architectural (new behavior/format). Microsoft frequently rebrands features, and exams like to test whether you understand the difference.

Question 3

A semantic model imports tables from a dataflow. The dataflow and semantic model are both scheduled to refresh at 6:00 AM. On some days, the semantic model refresh completes before the dataflow refresh and therefore contains the previous day's data.

Which action best resolves the issue?

  1. Configure an ordered process that refreshes the semantic model only after the dataflow refresh succeeds. (correct answer)
  2. Assign both items to the same workspace so Power BI automatically enforces their refresh dependency.
  3. Change the report connection to DirectQuery so the dataflow refresh always begins before model queries run.
  4. Enable incremental refresh on the semantic model so it waits for all upstream transformations to finish.
Explanation: When you see a question about refresh timing conflicts between dataflows and semantic models, think about dependency management — specifically, how to ensure upstream data sources finish before downstream consumers begin. The core problem here is a race condition: both items are scheduled at the same time (6:00 AM), so there's no guarantee the dataflow finishes first. The reliable fix is to create an ordered refresh chain, where the semantic model refresh is explicitly triggered only after the dataflow refresh completes successfully. This is exactly what answer A describes — configuring an ordered process (achievable through tools like Power Automate or Power BI's deployment pipeline triggers) that enforces a sequential dependency. If the dataflow fails, the semantic model won't refresh with stale or incorrect data. Answer B is a common misconception trap. Placing items in the same workspace does not automatically create refresh dependencies — Power BI workspaces are organizational containers, not dependency engines. You must explicitly configure the ordering. Answer C misunderstands what DirectQuery does. Switching to DirectQuery means queries hit the dataflow's storage at report-open time, but it doesn't control when the dataflow refresh starts or ensure it finishes before semantic model refresh begins. It also introduces latency and performance tradeoffs. Answer D confuses incremental refresh with dependency management. Incremental refresh controls how much data is refreshed (only recent partitions), not when a refresh begins relative to upstream sources. It has no waiting or synchronization behavior. Your study tip: on Power BI exam questions about refresh conflicts, always look for answers that explicitly establish a sequential dependency rather than answers that change unrelated settings like storage mode or workspace organization.

Question 4

A data engineer publishes a dataflow containing cleaned Customer and Order tables. A report author must analyze sales by customer segment using a one-to-many relationship and a reusable total-sales measure.

What should the report author do next?

  1. Export both dataflow tables to separate files, then calculate totals independently in each report visual.
  2. Define the relationship and DAX measure directly in the dataflow, then use the dataflow as the report.
  3. Create a dashboard from the dataflow tables, then define the relationship between the dashboard tiles.
  4. Create a semantic model from the dataflow tables, then define the relationship and measure in that model. (correct answer)
Explanation: When working with Power BI dataflows, it helps to understand the layered architecture: dataflows handle data preparation, while semantic models (formerly datasets) handle data modeling — relationships, measures, and business logic. Keeping these responsibilities separate is a core Power BI best practice. In this scenario, the report author needs two things: a one-to-many relationship between Customer and Order, and a reusable DAX measure for total sales. Both of these belong in a semantic model. The correct move is D — connect to the published dataflow tables, build a semantic model on top of them, define the relationship there, and write the DAX measure once so it can be reused across any report built from that model. A is wrong because exporting tables to files abandons the connected, refreshable dataflow entirely and breaks the data pipeline. Calculating totals independently in each visual is inefficient and inconsistent — the opposite of reusability. B misunderstands what dataflows can do. Dataflows are Power Query-based transformation tools; they don't support DAX measures or inter-table relationships in the way a semantic model does. You cannot "use the dataflow as the report" either — dataflows don't render visuals. C confuses dashboards with models. Dashboards in Power BI are collections of pinned report visuals — you cannot define relationships between dashboard tiles. Relationships are a modeling concept, not a dashboard concept. A good study tip: on Power BI exam questions, watch for answer choices that assign responsibilities to the wrong layer. Dataflows = transform, semantic models = model, reports = visualize, dashboards = aggregate/monitor.

Question 5

Twenty thin reports use one shared semantic model. A developer plans to rename several model columns and delete a measure that appears obsolete. The developer confirms that the model refresh succeeds after the changes.

What additional action is most important before deploying the changes?

  1. Move the deleted measure into the dataflow because dataflows automatically preserve report references to removed measures.
  2. Refresh the upstream dataflow twice because successful consecutive refreshes validate all downstream report expressions.
  3. Republish every thin report first because reports must be deployed before any semantic model metadata changes.
  4. Review downstream dependencies and test the thin reports because model metadata changes can break their visuals. (correct answer)
Explanation: Whenever you see a question involving shared semantic models in Power BI, think about the ripple effects: one model feeds many reports, so any structural change — renaming columns, deleting measures — can silently break downstream visuals without triggering an obvious error during model refresh. A successful model refresh only confirms that the data pipeline is intact; it says nothing about whether the twenty thin reports built on top of that model still function correctly. Renamed columns create broken field references in visuals, and deleted measures leave report visuals with unresolvable expressions. These issues only surface when you actually open or test the affected reports. That's exactly why D is correct — reviewing dependencies and testing the thin reports is the critical pre-deployment step, because it catches breakage before end users do. A is wrong because dataflows have no mechanism to automatically preserve or remap report references to deleted measures. Measures live in the semantic model layer, not the dataflow, and no automatic preservation exists anywhere in the Power BI service for this scenario. B is wrong because running consecutive dataflow refreshes validates data pipeline reliability, not the health of report expressions referencing model metadata. Two successful refreshes tell you nothing about broken visuals downstream. C is wrong because republishing reports before the semantic model is updated would have no protective effect — reports are consumers of the model, not prerequisites for deploying model changes. As a study tip, remember that in Power BI's layered architecture, changes to a shared semantic model create a one-to-many risk: one metadata change can break many reports simultaneously, so dependency impact analysis is always the most important pre-deployment step.

Question 6

A dataflow reads an operational database and refreshes at 2:00 AM. An Import-mode semantic model reads the dataflow and refreshes at 6:00 AM. A transaction is added to the operational database at 5:00 AM, and a user opens a report at 9:00 AM. No other refreshes occur.

Will the 5:00 AM transaction appear in the report, and why?

  1. Yes, because the semantic model refreshed after the transaction was added to the operational database.
  2. Yes, because opening the report causes the dataflow and semantic model to refresh their upstream data.
  3. No, because the model imported the dataflow's 2:00 AM output, which did not include the transaction. (correct answer)
  4. No, because Import-mode semantic models can display data only after the report itself is republished.
Explanation: When you see a question about data freshness in Power BI, trace the data pipeline step by step and match each refresh timestamp against when the new data actually entered the system. Here, the pipeline flows in two stages: the dataflow reads the operational database at 2:00 AM, then the Import-mode semantic model reads that dataflow's output at 6:00 AM. The critical detail is that the transaction enters the operational database at 5:00 AM — after the dataflow already ran. So when the semantic model refreshes at 6:00 AM, it pulls from the dataflow's 2:00 AM snapshot, which never captured the 5:00 AM transaction. The user opening the report at 9:00 AM sees stale data. Answer C correctly identifies this chain of events. Answer A contains a tempting half-truth: yes, the semantic model refreshed after the transaction was added, but it refreshed from the dataflow — not directly from the operational database. The dataflow is the bottleneck, and its snapshot predates the transaction. Answer B describes behavior that simply doesn't exist in Power BI; opening a report never triggers upstream dataflow or semantic model refreshes automatically (that would require DirectQuery or a configured on-demand refresh). Answer D is entirely fabricated — Import-mode models do not require report republishing to display updated data; a scheduled or manual refresh is sufficient. The study tip to take away: in a multi-stage pipeline, data freshness is only as current as the oldest upstream refresh in the chain. Always identify which stage ran last and whether the new data existed at that moment.

Question 7

A finance semantic model contains certified measures and row-level security roles. An analyst must create a new report from the model but must not edit the model. The analyst should remain subject to row-level security.

Which access approach should you recommend?

  1. Grant Build permission on the semantic model without assigning a workspace role that permits model editing. (correct answer)
  2. Grant Contributor access to the model's workspace and remove Build permission from the semantic model.
  3. Grant access to the upstream dataflow and allow the analyst to recreate the finance model locally.
  4. Grant Read permission on the report only and allow report creation without access to the semantic model.
Explanation: When a question involves sharing a Power BI semantic model with a collaborator who needs to build content but not modify the model itself, you should focus on the distinction between Build permission and workspace roles. Build permission is a granular, model-level permission that allows a user to create new reports, dashboards, or composite models on top of a semantic model — without granting any ability to edit the underlying model's measures, relationships, or schema. Critically, row-level security (RLS) is always enforced based on the user's identity, regardless of how they access the model. This makes A the correct recommendation: granting Build permission alone lets the analyst create a new report while remaining fully subject to RLS and unable to alter the certified measures. B is wrong because Contributor workspace access includes the ability to edit datasets and publish content in that workspace, which would allow the analyst to modify the model — directly violating the requirement. Removing Build permission separately doesn't fix this since the workspace role already grants broader rights. C is wrong because redirecting the analyst to the upstream dataflow means they would rebuild the model themselves locally, bypassing certified measures and RLS entirely — defeating the purpose of a governed, certified model. D is wrong because Read permission on a report only lets the analyst view an existing report; it does not enable them to create a new report from the semantic model at all. As a study tip, remember this pattern: Build permission = create from the model, not change it. Workspace roles (Viewer, Contributor, Member, Admin) are broader — when a question asks for least-privilege report creation, Build permission is usually the precise tool.

Question 8

An organization has twelve reports that calculate revenue, margin, and year-to-date sales. Each report imports the same source tables and defines its own versions of the measures. Users have identified inconsistent totals across reports.

Which change most directly addresses the inconsistency while preserving the ability to create different report layouts?

  1. Move the source-table transformations into a shared dataflow but retain separate measures in every report.
  2. Create a shared semantic model containing the approved measures and build thin reports connected to that model. (correct answer)
  3. Publish all twelve reports to the same workspace and configure them with identical refresh schedules.
  4. Pin visuals from all twelve reports to one dashboard and use the dashboard as the governed data layer.
Explanation: When you see a question about report inconsistency across multiple files, the core issue is almost always single source of truth — specifically, whether business logic (measures) lives in one governed place or is duplicated everywhere. Duplicated measures drift over time, which is exactly what's happening here with twelve reports each defining their own version of revenue and margin. The solution is a shared semantic model (formerly called a shared dataset in Power BI). By centralizing the approved DAX measures in one published model, every report that connects to it automatically uses the same calculation logic. Critically, each report can still arrange visuals, apply filters, and choose layouts independently — so report authors aren't constrained. This is what makes B correct: it solves the root cause (inconsistent measure definitions) without sacrificing flexibility. Option A misses the mark because moving transformations into a dataflow only standardizes the raw data shape, not the measure calculations. Each report still defines its own revenue formula, so totals can still diverge. Option C is a governance distraction — putting reports in the same workspace with matching refresh schedules ensures they're updated at the same time, but does nothing about mismatched measure definitions. Option D might make inconsistencies less visible by showing all numbers on one surface, but a dashboard is a display layer, not a data governance layer; pinning conflicting visuals together doesn't reconcile them. The study tip to remember: on Power BI exam questions, distinguish between data shape (handled by dataflows/Power Query), business logic (handled by measures in a semantic model), and presentation (handled by report layouts and dashboards). Inconsistency questions almost always point to the business logic layer.

Question 9

An on-premises database is accessed through a gateway by a dataflow. A semantic model imports only the prepared output of that dataflow and has no direct connection to the database. The database password changes.

Where must the on-premises database credentials be updated to restore the upstream data refresh?

  1. Only in every report that displays visuals based on the semantic model.
  2. In the dataflow's gateway connection, because the dataflow directly accesses the database. (correct answer)
  3. Only in the semantic model, because all report refreshes originate from the modeling layer.
  4. In every dashboard that contains tiles pinned from reports using the semantic model.
Explanation: When data flows through multiple layers in Power BI — a database → gateway → dataflow → semantic model → reports — credentials must be updated at the layer that actually authenticates against the source. Think of it like a chain: break any link, and everything downstream stops working. Here, the dataflow is the component that directly connects to the on-premises database through the gateway. It's the one presenting credentials to authenticate that connection. When the database password changes, the dataflow's gateway connection settings are where those credentials live and where they must be updated. Once the dataflow can refresh successfully again, its output flows cleanly into the semantic model, and reports refresh normally — the fix ripples downstream automatically. That makes B correct. A is wrong because reports don't store database credentials at all. Reports consume visuals built on semantic models; they have no knowledge of, or connection to, the underlying database. Updating anything at the report layer wouldn't touch the authentication problem. C is wrong because the semantic model imports prepared output from the dataflow — it never connects directly to the database. The semantic model's credentials govern its connection to the dataflow, not to the on-premises database. Changing something there wouldn't fix the broken dataflow-to-database handshake. D is wrong for a similar reason as A. Dashboards are display surfaces that show tiles pinned from reports. They hold no connection settings whatsoever and play no role in data refresh authentication. Study tip: On Power BI questions involving layered architectures, always trace the data back to its origin — the credential fix always belongs to the component that directly touches the source.

Question 10

A report author downloads a report that is connected to a centrally managed semantic model. The report file contains pages and visuals but no imported business tables. Source-system credentials and scheduled refresh are managed centrally.

Which statement best describes this report's relationship to the data?

  1. The report is a thin report that queries the shared semantic model, so data refresh is managed on that model. (correct answer)
  2. The report is a dataflow that stores transformed tables, so its refresh is managed independently of the model.
  3. The report contains a duplicated semantic model, so central refresh settings are copied into the report file.
  4. The report is a dashboard that caches source tables, so credentials are inherited from pinned visual tiles.
Explanation: When you see a question about report architecture in Power BI, focus on where the data actually lives and who controls the refresh cycle. A key distinction on this exam is between a thin report (a .pbix or published report with no embedded data model) and a full report that bundles its own semantic model. A thin report connects to a shared, centrally published semantic model — sometimes called a live connection or DirectQuery connection to a Power BI dataset. Because the report file contains no imported business tables of its own, all data refresh, credentials, and gateway configuration are managed at the semantic model level, not inside the report. This makes A correct: the report simply queries the shared model, so whoever owns that model controls the refresh schedule and source credentials. B is wrong because a dataflow is a separate Power BI artifact that stores transformed tables in Azure Data Lake Storage and has its own refresh schedule — it is not a report file, and the scenario never mentions dataflows. C is wrong because thin reports do not duplicate or copy the semantic model; they reference it by connection, so no refresh settings are embedded in the report file. D confuses the concept with Power BI dashboards and pinned tiles, which are a display layer, not a data-storage mechanism — dashboards don't cache source tables or inherit credentials from tiles. As a study tip, remember the phrase "thin report, shared model": whenever a report has no imported tables and credentials are managed centrally, you're dealing with a live connection to a shared semantic model, and all data governance stays with that model.