Microsoft Power BI Quiz: Deployment Pipelines
10 questions · exam conditions
0:00
Deployment PipelinesQuestion 1 of 10

A company has separate Development, Test, and Production workspaces assigned to a deployment pipeline. A developer completes changes to a Power BI Desktop file, and the changes must be validated by testers before becoming visible in Production.

Which sequence should the company use?

Publish to Development, deploy to Test, complete validation, and then deploy from Test to Production.
Publish to Test, deploy to Development for validation, and then publish the file directly to Production.
Publish to Development, deploy directly to Production, and then copy the production report into Test.
Publish to all three workspaces, validate the Test copy, and delete the unapproved Production copy if needed.
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Deployment Pipelines

Practice Deployment Pipelines 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 Deployment Pipelines, giving you a quick way to practice the rules, question types, and explanations that matter most for Microsoft Power BI.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A company has separate Development, Test, and Production workspaces assigned to a deployment pipeline. A developer completes changes to a Power BI Desktop file, and the changes must be validated by testers before becoming visible in Production.

Which sequence should the company use?

  1. Publish to Development, deploy to Test, complete validation, and then deploy from Test to Production. (correct answer)
  2. Publish to Test, deploy to Development for validation, and then publish the file directly to Production.
  3. Publish to Development, deploy directly to Production, and then copy the production report into Test.
  4. Publish to all three workspaces, validate the Test copy, and delete the unapproved Production copy if needed.
Explanation: When you see a question about Power BI deployment pipelines, think about the fundamental purpose of the pipeline: moving content through a controlled, sequential flow — Development → Test → Production — so that changes are validated before reaching end users. The correct approach is A. A developer publishes the updated .pbix file to the Development workspace, which is the designated entry point for new changes. From there, the deployment pipeline's built-in "Deploy" action promotes the content to Test, where testers can validate it against real-world scenarios without affecting Production. Only after validation passes does the content get deployed from Test to Production. This sequence preserves data integrity and ensures no unreviewed changes reach business users. B is wrong because it bypasses Development entirely and publishes directly to Test, breaking the intended pipeline order. It also suggests publishing directly to Production, which completely circumvents the pipeline's governance controls. C is wrong because deploying directly to Production skips the Test validation stage altogether — the entire point of having a three-stage pipeline. Copying the report backward into Test afterward doesn't retroactively validate anything; it reverses the flow. D is wrong because publishing simultaneously to all three workspaces ignores the sequential promotion model. Deployment pipelines exist precisely so you don't push to Production prematurely. Planning to delete the production copy "if needed" introduces unnecessary risk and is not how pipeline governance works. A useful study tip: on Power BI exam questions involving pipelines, always look for the answer that respects the left-to-right, sequential promotion model — Development first, Production last, never skipping stages.

Question 2

A developer adds a Margin field to a semantic model and updates a report to use that field. Both changes exist in Development. During selective deployment to Test, the developer selects only the report.

What is the most appropriate action before testing the updated report?

  1. Deploy only the report because its visual definition includes a private copy of every referenced model field.
  2. Deploy the changed semantic model and the dependent report so the target contains a compatible set of items. (correct answer)
  3. Refresh the existing Test semantic model because a refresh automatically creates fields added in Development.
  4. Rename the Test semantic model to Margin so the deployed report resolves the missing field by name.
Explanation: When working with Power BI deployment pipelines, the critical concept is item dependency: a report is not self-contained — it references fields, measures, and tables that live in the semantic model. If those two items fall out of sync across pipeline stages, the report breaks. Here, the developer added a Margin field to the semantic model in Development but only deployed the report to Test. The Test semantic model has no Margin field, so the deployed report immediately has an unresolved reference. The correct action — answer B — is to deploy both the updated semantic model and the report together, ensuring the target environment contains a compatible, consistent set of items. Answer A is a fundamental misconception. Reports in Power BI do not carry private copies of model fields. They hold visual definitions (chart types, filters, formatting) but depend entirely on the live semantic model for data and schema. Deploying the report alone leaves the Margin reference dangling. Answer C is wrong because a dataset refresh pulls in new data rows from the source — it does not alter the schema or create new calculated fields. A refresh cannot add a column or measure that was never defined in the model. Answer D is a trap based on a misunderstanding of how report-to-model binding works. Reports connect to semantic models by item ID or workspace binding, not by matching names. Renaming the Test model "Margin" solves nothing. Study tip: On deployment pipeline questions, always ask yourself whether dependent items share the same schema across stages. If a model change drives a report change, they must travel together.

Question 3

A tester edits a report directly in the Test workspace to correct a calculation display. The Development version is still unchanged. Another developer is ready to deploy unrelated Development changes to Test.

How should the team preserve the tester's correction while maintaining a reliable promotion path?

  1. Incorporate the correction into the Development source, then redeploy the resulting tested version through the pipeline. (correct answer)
  2. Deploy the unrelated Development version first because the pipeline automatically merges report changes made in Test.
  3. Continue editing only the Test report because target-stage changes are automatically copied back into Development.
  4. Deploy the corrected Test report directly to Production and allow Development to remain permanently different.
Explanation: When working with Power BI deployment pipelines, the critical concept to understand is that pipelines are one-directional promotion tools, not synchronization systems. Changes made directly in a target stage (like Test) are never automatically reflected back upstream — and if you deploy over them, they're simply overwritten. The correct approach is A: take the tester's correction, incorporate it back into the Development source, and then redeploy through the pipeline in the proper sequence. This keeps Development as the single source of truth and ensures every change is tested before it reaches Production. The promoted artifact reflects both the unrelated developer's changes and the tester's fix, giving you a clean, traceable promotion path. B is a dangerous misconception — Power BI pipelines do not merge changes. Deploying from Development to Test will overwrite whatever the tester manually edited in the Test workspace. The correction would be permanently lost. C is similarly false. Target-stage edits are never "copied back" to upstream stages. Power BI has no reverse-sync feature. Believing this would lead teams to lose track of what's actually in their source environments. D might seem pragmatic in a pinch, but it breaks the entire promotion model. Deploying Test directly to Production while Development diverges creates inconsistency and means future deployments from Development will undo Production changes — a recipe for regression bugs. As a study tip: on pipeline questions, always ask yourself "where is the source of truth?" In a healthy pipeline, it's always Development. Any fix made downstream must be ported upstream before the next deployment.

Question 4

A report and its semantic model are deployed together through Development, Test, and Production. Each stage has its own corresponding semantic model, and the Production report must never query the Development model.

Which approach best supports this requirement?

  1. Deploy only the report and delete every target semantic model so the pipeline creates model fields inside the report.
  2. Keep the report connected to the Development model and rely on Production workspace permissions to redirect its queries.
  3. Deploy the report and semantic model through the same pipeline so the report binds to the corresponding model in each stage. (correct answer)
  4. Publish three unrelated report copies and manually change every visual whenever a stage-specific model is refreshed.
Explanation: When you see a question about deployment pipelines in Power BI, think about how reports maintain their data connections as they move across stages. The core challenge is ensuring that each stage's report queries only its own corresponding semantic model — not one from a different environment. Deploying both the report and its semantic model together through the same pipeline (C) is exactly how Power BI deployment pipelines are designed to work. When you deploy them as a unit, the pipeline automatically binds the report in each stage to the semantic model in that same stage. Production stays connected to the Production model, Test to the Test model, and Development to the Development model — no manual rewiring required. Option A is fundamentally flawed because deleting target semantic models doesn't create "model fields inside the report" — that's not how Power BI works. Reports are thin visualization layers; they don't absorb or embed a full semantic model by removing the target. Option B relies on workspace permissions to redirect queries, but permissions control access, not data source routing. A report connected to the Development model will continue querying that model regardless of what permissions exist in the Production workspace — this directly violates the stated requirement. Option D abandons pipeline automation entirely. Maintaining three separate, manually updated report copies is error-prone, unsustainable, and defeats the entire purpose of a deployment pipeline. Study tip: On Power BI exam questions about deployment pipelines, remember that the pipeline only manages what you deploy through it. Deploy both artifacts together, and stage binding happens automatically — leave one out, and you break the chain.

Question 5

A semantic model uses a parameter named ServerName. Development must connect to dev-sql, Test must connect to test-sql, and Production must connect to prod-sql. The model definition should otherwise remain identical in every stage.

What should you configure to minimize manual work and prevent a later deployment from restoring the wrong server value?

  1. A separate PBIX file for each stage, with ServerName edited before every publication.
  2. A parameter deployment rule that supplies the appropriate ServerName value in each target stage. (correct answer)
  3. A workspace role that allows testers to change ServerName after each pipeline deployment.
  4. A report-level filter that selects the appropriate server according to the current workspace.
Explanation: When working with Power BI deployment pipelines, the key challenge is moving the same semantic model across stages (Development → Test → Production) while allowing environment-specific settings — like database connection strings — to change automatically without manual edits or risk of human error. This is exactly what deployment rules are designed to solve. A parameter deployment rule lets you define, once per stage, what value a named parameter should take whenever a deployment lands in that workspace. So when you deploy to Test, the pipeline automatically substitutes test-sql for ServerName; when you deploy to Production, it substitutes prod-sql. The model definition itself stays untouched, satisfying the requirement that it remain identical across stages. This makes B the correct answer — it directly solves both requirements: no manual work and no risk of a subsequent deployment overwriting the wrong value. A fails because maintaining three separate PBIX files defeats the "identical model definition" requirement and creates ongoing manual effort and version-drift risk every time a change needs to be replicated across files. C misunderstands the problem — granting workspace roles to testers allows humans to change the parameter after deployment, but that's exactly the manual, error-prone process you're trying to eliminate; it also doesn't help in Production. D is a conceptual mismatch: report-level filters operate on data, not on connection parameters, and cannot redirect a query to a different SQL server. As a study tip, remember that deployment rules are the pipeline feature specifically built for environment-specific configuration — whenever a question mentions parameters that must vary by stage, deployment rules should be your first instinct.

Question 6

A developer deploys an updated semantic model from Development to Test. The Development model contains recently refreshed sales data, but the Test model must retrieve data from a smaller test database.

What should the team expect immediately after the deployment?

  1. The Development data is copied to Test, after which the Test connection is applied during the next refresh.
  2. The model metadata is deployed, but Test must use its configured connection and be refreshed to load current test data. (correct answer)
  3. The Test data is copied back to Development so that both stages have matching model contents.
  4. The deployment is blocked because semantic models can be promoted only when both stages contain identical data.
Explanation: When working with Power BI deployment pipelines, it's important to separate two distinct concepts: model metadata and data. Deployment pipelines move the structure and configuration of a semantic model — its queries, schema, measures, and relationships — but they do not transfer the actual data loaded into memory. When a semantic model is deployed from Development to Test, what travels across is the metadata: the model definition itself. Each pipeline stage maintains its own data source connections, configured independently through deployment rules or workspace settings. This means the Test stage will use its own configured connection — pointing to the test database — not the Development connection. However, the model won't contain any data until a refresh is triggered against that test database. This is exactly what B describes, making it the correct answer. A is wrong because it inverts the actual behavior. Data from Development is never "copied" to Test first; the Test connection is applied immediately, not deferred to a later refresh. C describes a backwards data flow that simply doesn't exist — deployment pipelines are one-directional and never pull data from a downstream stage back into an upstream one. D is a fabricated restriction; deployments are not blocked by data mismatches between stages. The whole point of deployment pipelines is to promote models across environments that intentionally have different data. A useful mental model: think of deployment pipelines as deploying the blueprint, not the building materials. Each stage supplies its own materials (data) through its own connections. On exam questions about pipelines, always ask yourself: "Is this about structure or data?" — they behave very differently.

Question 7

A report is deployed successfully from Test to Production. Testers can access the Test workspace, but only executives should access the Production workspace. After deployment, an administrator notices that the executives still cannot open the production report.

What should the administrator do?

  1. Redeploy the report while signed in as an executive so that the executive permissions are inherited.
  2. Change the Production stage name to match the security group assigned to the executives.
  3. Add the executives to the Test workspace because its permissions automatically flow to later stages.
  4. Grant the executives access in Production by using the Production workspace, app, or item permissions. (correct answer)
Explanation: When working with Power BI deployment pipelines, it's critical to understand that workspace permissions are independent at each stage. Deployment pipelines move content (reports, datasets, dashboards) between stages, but they never transfer access rights. Each workspace — Development, Test, and Production — manages its own permissions separately. Since only executives should access Production, the administrator must explicitly grant them access there. This can be done through the Production workspace directly, by publishing a Power BI app from that workspace and granting the executives access to the app, or by configuring item-level permissions. Option D captures this correctly — permissions must be established where the users need access. Option A is a misconception about how deployment works. The identity of the person performing the deployment has no bearing on who inherits access afterward. Redeploying as an executive wouldn't grant that executive — or anyone else — workspace permissions. Option B confuses workspace naming with security configuration. Stage names in a deployment pipeline are labels for organizational clarity; they have no relationship to security groups or access control. Option C describes a feature that simply doesn't exist in Power BI. Permissions granted in one pipeline stage do not "flow" or cascade to later stages. Each stage is a separate workspace with its own membership. Study tip: On the Power BI exam, watch for questions that imply deployment pipelines automatically manage permissions or propagate access — they never do. Remember: pipelines move content, not access. Any time users can't open content after deployment, the answer almost always involves explicitly granting permissions in the target workspace or app.

Question 8

Consumers view production reports through a published Power BI app. An administrator deploys an updated report from Test to the Production workspace. The deployment succeeds, but app users continue to see the previous report design.

What should the administrator do next?

  1. Reassign the Production workspace to Test because apps can display content only from a pipeline's middle stage.
  2. Redeploy the report from Development because apps ignore content that arrives from the Test stage.
  3. Refresh the semantic model because an app's report layout changes only during a scheduled data refresh.
  4. Update the app from the Production workspace so that the deployed workspace changes are published to its audience. (correct answer)
Explanation: When working with Power BI deployment pipelines, it's important to understand that deploying content to a workspace and publishing an app are two separate actions. A Power BI app is not a live mirror of its workspace — it's a packaged snapshot that must be explicitly updated and republished to reflect workspace changes. When an administrator deploys an updated report from Test to Production, the Production workspace receives the new content. However, the app that end users consume remains unchanged until someone manually updates and republishes it. That's exactly why D is correct: the administrator must open the Production workspace, go to the app settings, and select "Update app" to push the new report design to the app's audience. Choice A is a fabricated rule — there is no restriction preventing apps from displaying content from the Production (final) stage of a pipeline. Apps can and do serve content from any workspace stage. Choice B is similarly invented; apps do not ignore content based on which pipeline stage it arrived from. The deployment source is irrelevant to app visibility. Choice C conflates two unrelated processes — semantic model refreshes update data, not report layouts or visuals. Republishing the app is the only action that changes what consumers see in terms of design. A useful rule of thumb: in Power BI, deployment pipelines move content between workspaces, but app updates move content to users. Any time a question describes a mismatch between what's in the workspace and what app users see, the answer almost always involves updating and republishing the app from the Production workspace.

Question 9

The deployment pipeline comparison indicates that a semantic model is the same in Test and Production. However, a report displays different total sales values in the two stages. Test and Production use different databases.

Which explanation best accounts for these observations?

  1. The comparison evaluates deployed item definitions, while different source data or refresh states can produce different report values. (correct answer)
  2. The comparison guarantees equal data values, so the different totals prove that the pipeline comparison is corrupted.
  3. The comparison evaluates only workspace permissions, so it cannot determine whether semantic model definitions differ.
  4. The comparison automatically refreshes both models, but Production refresh results are hidden until another deployment occurs.
Explanation: When working with Power BI deployment pipelines, it's important to distinguish between what the pipeline compares and what the pipeline guarantees. The comparison feature evaluates item definitions — essentially the structure and configuration of artifacts like semantic models, reports, and dataflows as they were deployed. It does not inspect the actual data values sitting inside those models. This is exactly why A is correct. Two stages can have identical semantic model definitions (same tables, measures, relationships, calculated columns) while still showing different report totals, simply because each stage connects to a different database with different underlying data, or because the models were last refreshed at different times. The pipeline comparison gives you a green checkmark on structure, not on data parity. B is wrong because the comparison tool is not corrupted just because values differ — it's working exactly as designed. Identical definitions with different data is expected and normal behavior. C is incorrect because the comparison absolutely does evaluate item definitions (schema, measures, metadata), not just workspace permissions. D describes a behavior that doesn't exist — deployment pipelines do not automatically trigger data refreshes, and refresh results are never "hidden" pending a deployment event. A useful study tip: remember the phrase "definition vs. data." Pipeline comparison checks whether the blueprint of your model matches across stages. The content of that model depends on the data source and refresh schedule. On the exam, whenever you see a scenario where pipeline stages look identical but behave differently, ask yourself whether the question is about structure or about live data values.

Question 10

A team proposes assigning the same workspace to both the Development and Test stages of a deployment pipeline. The team argues that folders and naming conventions will keep untested content separate from validated content.

What should the team do instead?

  1. Use one workspace and separate the stages by granting developers access only during business hours.
  2. Use one workspace for both stages because pipeline stage labels create separate copies inside the assigned workspace.
  3. Use distinct workspaces for Development and Test so that each pipeline stage represents an independently managed content environment. (correct answer)
  4. Use one workspace and publish two apps because each app automatically becomes a separate pipeline stage.
Explanation: When you see a question about Power BI deployment pipelines, anchor your thinking to this core principle: each pipeline stage must map to its own dedicated workspace. A deployment pipeline exists precisely to give Development, Test, and Production environments clean boundaries — where content can be promoted, validated, and governed independently. That's why C is correct. Assigning distinct workspaces to Development and Test ensures that each stage is a fully isolated environment with its own content state, permissions, and refresh schedules. When you promote content from Development to Test, Power BI copies artifacts between workspaces, giving the Test team a clean snapshot to validate without any risk of interference from ongoing development work. Folders and naming conventions, as the team proposes, are fragile substitutes — they rely entirely on human discipline and offer no technical enforcement. Answer A is wrong because restricting developer access by time of day does nothing to separate content versions or prevent accidental overwrites. It conflates access scheduling with environment isolation. Answer B reflects a common misconception — pipeline stage labels are simply pointers to workspaces; they do not create internal partitions or separate copies within a single workspace. Assigning one workspace to two stages just points both stages at the same content. Answer D is wrong because publishing multiple apps does not create separate pipeline stages. Apps are presentation layers for consuming reports, not deployment environments — they have no native relationship to pipeline stage architecture. A good study tip: on Power BI exam questions, whenever you see pipeline stages mentioned, mentally verify that each stage = one workspace. If an answer breaks that one-to-one relationship, it's almost always a distractor.