Microsoft Power BI Quiz: Version Management
14 questions · exam conditions
0:00
Version ManagementQuestion 1 of 14

Can report version history show visuals before last month's refresh?

Yes, refresh is versioned
Only if published as an app
No, refresh is not versioned
Only if you save a copy
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Version Management

Practice Version Management 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 Version Management, 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

Can report version history show visuals before last month's refresh?

  1. Yes, refresh is versioned
  2. Only if published as an app
  3. No, refresh is not versioned (correct answer)
  4. Only if you save a copy
Explanation: Report version history tracks saved changes to the report definition, not data refreshes. A refresh updates the dataset, so visuals from before last month's refresh are not captured as a new version. The tempting wrong answer is thinking refresh is versioned, but refresh does not alter the report file itself.

Question 2

Two authors edit the same report in a Git-integrated workspace. Which change is safest?

  1. Merge via a pull request (correct answer)
  2. Push directly to main branch
  3. Publish both .pbix files
  4. Overwrite from latest .pbix
Explanation: In a Git-integrated workspace, a pull request lets you review and merge changes from two authors safely, resolving conflicts before they reach the main branch. Pushing directly to main is the tempting choice but skips review and can overwrite a teammate's work. Publishing or overwriting .pbix files bypasses Git version control entirely, so those are riskier.

Question 3

You restore version 8 of a report that has 40 versions. What happens to version 40?

  1. It is deleted permanently
  2. It becomes the latest version
  3. It is moved to Recycle Bin
  4. It remains in version history (correct answer)
Explanation: Restoring version 8 adds that older snapshot as a new latest version; it doesn't delete anything already in history. So version 40 remains in the version history, just no longer the most recent. The tempting mistake is thinking version 40 is deleted or becomes the latest, but restore only promotes version 8 and leaves prior versions intact.

Question 4

A report is tested in a pipeline. How should it be moved to production safely?

  1. Publish from Power BI Desktop
  2. Deploy through the pipeline (correct answer)
  3. Copy the .pbix to OneDrive
  4. Export and import the report
Explanation: Once a report has passed testing in a pipeline, deploying through that same pipeline is the safe path because it moves the tested version to production without rebuilding it. Publishing from Power BI Desktop is the tempting shortcut, but it sends your current local file straight to the workspace, bypassing the tested pipeline and risking untested changes.

Question 5

A faulty release has been deployed to Production through a deployment pipeline. The Development workspace already contains additional unfinished changes, but the Git repository has an immutable tag for the last known-good release.

What is the safest rollback strategy?

  1. Restore the tagged release to a controlled source workspace, validate it, and deploy that known-good version forward to Production. (correct answer)
  2. Perform a reverse deployment from Production to Test because pipeline stages retain the complete prior state of every deployed item.
  3. Deploy the current Development workspace to Production because unfinished changes will be excluded automatically by the release tag.
  4. Refresh the Production semantic model from the last successful refresh because data refresh also restores prior report definitions.
Explanation: When a faulty release reaches Production in a deployment pipeline, your instinct should be to isolate the problem and use a verified, stable source rather than trying to "undo" in place. The key concept here is controlled promotion: always validate before you deploy forward, and never trust an intermediate workspace as a clean baseline unless you've confirmed its state. The safest path is A. By restoring the immutable Git tag — which represents a snapshot of the last known-good release — into a controlled source workspace, you get a clean, verified artifact. You then validate it in that workspace before promoting it forward through the pipeline stages to Production. This mirrors the same deployment discipline that introduced the change, reducing the risk of introducing additional issues. B is a trap because pipeline stages do not retain a complete historical snapshot of every prior deployed item. Deployment pipelines show differences and allow forward deployment; they aren't version-history vaults you can reverse through to recover old states. C is dangerous because the Development workspace contains unfinished changes. Power BI deployment pipelines do not automatically filter or exclude items based on Git tags at deploy time — you would push incomplete work straight into Production. D confuses two entirely separate concerns. A semantic model refresh updates data from a source; it has no effect on report definitions, visuals, measures, or metadata. Refreshing data cannot restore a prior report state. Your study tip: on Power BI pipeline questions, remember that Git tags are immutable checkpoints, while pipeline stages reflect current workspace state — not history. Rollback always flows through source control, not through pipeline reversal.

Question 6

Consumers access a report only through a published Power BI app. A developer needs to validate revised report navigation with a small review group before exposing it to all app users. The shared semantic model will remain unchanged during this test.

Which workflow provides the safest change boundary?

  1. Update the app immediately, validate the navigation with consumers, and restore the old links manually if reviewers find an issue.
  2. Replace the production semantic model first so the existing app automatically creates a recoverable copy of the report layout.
  3. Modify and validate the report in the workspace, obtain approval, and update the app only after the revised version is accepted. (correct answer)
  4. Refresh the app's semantic model after every layout edit because refresh controls which report definition app users receive.
Explanation: When you see a question about managing report changes in Power BI while protecting end users, think about the workspace-to-app publishing pipeline. In Power BI, the workspace is your development environment, and the app is a controlled, curated layer on top of it. These two layers are intentionally separate — changes in the workspace don't automatically reach app consumers until you explicitly update the app. This separation is exactly what makes C the correct workflow. By modifying and validating the report inside the workspace first, the developer creates a safe sandbox. App users continue seeing the unchanged, published version throughout the review process. Only after the review group approves the navigation changes does the developer push the update by republishing the app. No users are exposed to unfinished work, and no manual rollback is needed. A fails because it exposes all app users to the untested navigation immediately. If reviewers find problems, you're already in damage-control mode — manually restoring links is error-prone and disruptive. B is built on a false premise: replacing the semantic model doesn't create a recoverable snapshot of the report layout, and it would disrupt the shared model the question specifically says should remain unchanged. D confuses semantic model refresh with report definition delivery. Refreshing a dataset updates data values, not the report layout or navigation structure that app users see — those are controlled by app publication, not dataset refresh. The key study takeaway: always remember that publishing the app is the gate. Workspace edits are invisible to app consumers until you choose to update the app — use that gate deliberately.

Question 7

A Power BI Desktop file is stored in a SharePoint document library with version history enabled. A developer publishes a new version that unintentionally removes several measures. The previous SharePoint version is known to be valid, and no required data source changes were introduced by the new version.

Which recovery approach most safely restores the previous report and semantic model definitions?

  1. Run an on-demand refresh in the Power BI service because refresh returns the semantic model metadata to the previous successful state.
  2. Restore the earlier SharePoint file version, validate it in Power BI Desktop, and republish it through the controlled release process. (correct answer)
  3. Restore only the report pages from SharePoint because measures are versioned separately by the Power BI service after publication.
  4. Delete the existing workspace semantic model and wait for SharePoint synchronization to reconstruct all service configurations automatically.
Explanation: When dealing with version control and recovery in Power BI, the key principle is that the .pbix file is the source of truth — it contains both the report layout and the semantic model (measures, relationships, data model). Recovery questions hinge on understanding where definitions actually live and what each service can and cannot reconstruct. Restoring the previous SharePoint version of the .pbix file and republishing it is the correct approach (B) because it treats the file as a complete, atomic artifact. The older version contains the missing measures intact within the data model, you can validate everything looks correct in Power BI Desktop before touching production, and republishing through a controlled release process ensures governance and minimizes risk of introducing further errors. Option A is a common trap — on-demand refresh updates the data in the semantic model, not its metadata or structure. Refresh cannot resurrect deleted measures; it simply re-queries the data source against whatever model definition currently exists in the service. Option C reflects a fundamental misunderstanding of how Power BI stores things. Measures are embedded in the semantic model within the .pbix file, not versioned separately by the Power BI service. You cannot restore report pages independently while leaving measures intact from a different version. Option D is entirely fictional behavior. The Power BI service has no automatic SharePoint synchronization mechanism that reconstructs workspace configurations. Deleting the semantic model would cause additional disruption with no guaranteed recovery path. Your study tip: on Power BI exam questions about recovery or versioning, always ask yourself "where does this artifact actually live?" — data lives in sources, structure lives in the .pbix, and the service reflects whatever was last published.

Question 8

The same Power BI semantic model is promoted through Development, Test, and Production. Each stage must use a different server name, but the model schema, measures, and report definitions must remain identical across stages.

How should the team manage the stage-specific server values without creating separate content versions?

  1. Maintain a different PBIX branch for each stage and merge measure changes independently into all three branches before every deployment.
  2. Use a parameter for the server and configure deployment rules or stage-specific settings to assign the appropriate value during promotion. (correct answer)
  3. Edit the server connection directly in each target workspace after every deployment and treat the resulting differences as uncommitted hotfixes.
  4. Store the Production server in the model definition and rely on gateway mappings to rewrite every development and test query automatically.
Explanation: When you see a question about managing environment-specific configurations across deployment pipeline stages in Power BI, focus on how to change values without touching the model definition itself. The goal is a single source of truth that adapts per environment automatically. Power BI deployment pipelines solve exactly this problem through parameters combined with deployment rules. You define a parameter (e.g., ServerName) inside your semantic model, then configure stage-specific rules in the pipeline to inject the correct server value during promotion. The schema, measures, and reports remain identical — only the injected parameter value differs per stage. This makes B the correct approach. A is a maintenance trap. Maintaining three separate PBIX branches means you'll inevitably have schema drift between branches, and merging measure changes across all three before every deployment is error-prone and time-consuming — exactly the problem deployment pipelines are designed to eliminate. C describes a manual, unsustainable workflow. Directly editing connections after each deployment means the workspace state diverges from your source definition, creating undocumented "hotfix" differences that break the promise of identical content across stages. D reverses the proper logic. Hardcoding the Production server into the model definition means Development and Test inherit a Production value, which is a security and governance risk. Gateway mappings handle credential authentication and on-premises routing, not query-level server-name rewriting. As a study tip, remember that in Power BI deployment pipelines, parameters + deployment rules is the canonical pattern for any value that must vary by stage (servers, connection strings, API endpoints). If an exam question describes stage-specific configuration, this combination is almost always the answer.

Question 9

A semantic model measure is being replaced, and a report visual must be updated to reference the replacement measure. The old measure will be removed as part of the same release. The solution is stored as a Power BI project in Git.

How should the dependent changes be committed to make rollback and review safest?

  1. Commit the model and report changes together as one coherent change set, then validate and tag the tested release. (correct answer)
  2. Commit the measure removal first, deploy it, and commit the report update only after users confirm that visuals are broken.
  3. Commit the report update first and leave the model change uncommitted so Git can infer the required replacement measure.
  4. Commit each generated file to unrelated branches and combine the branches directly in the Production workspace after deployment.
Explanation: When working with Power BI projects in Git, the critical concept being tested here is atomic commits for dependent changes. Whenever a report visual depends on a model element (like a measure), removing that element and updating the reference must travel together — otherwise you create a broken intermediate state in your version history. Answer A is correct because bundling the measure removal and the report's updated visual reference into a single coherent commit ensures that at no point in the Git history does the repository contain a broken state. Reviewers examining the diff see both sides of the dependency change at once, and if a rollback is ever needed, reverting one commit restores both files simultaneously — keeping the model and report consistent. Answer B inverts the safe order catastrophically. Deploying the measure removal before the report is updated intentionally breaks production visuals and uses user-reported errors as a testing mechanism — this is never an acceptable release strategy and makes rollback painful because changes are already split across deployments. Answer C misunderstands how Git works. Git tracks file changes; it has no semantic awareness of Power BI measure dependencies and cannot "infer" a replacement. Leaving model changes uncommitted means the repository is incomplete and the change is invisible to reviewers entirely. Answer D treats Production as a merge environment, which bypasses proper branch review, CI validation, and the entire purpose of using Git. Combining unrelated branches directly in Production is a governance and auditability failure. Your study tip: on Power BI project/Git questions, always ask "does this strategy leave the repo in a broken state at any commit?" — atomic, co-dependent commits are always the safe answer.

Question 10

A Fabric workspace connected to Git contains a report changed by an analyst in the workspace. Another developer changed the same report in the connected repository branch. Synchronization now reports a conflict, and neither set of changes has been validated against the other.

What should the team do before synchronizing the final version?

  1. Select the workspace version immediately because workspace edits always have precedence over repository changes during conflict resolution.
  2. Select the Git version immediately because a connected repository automatically contains every workspace edit as a hidden commit.
  3. Preserve both states in commits or branches, reconcile the conflicting source changes, validate the result, and then synchronize the resolved version. (correct answer)
  4. Disconnect Git and reconnect the same branch because reconnection combines both report versions without requiring conflict resolution.
Explanation: When you see a conflict in Fabric's Git integration, think of it the same way you'd think about a merge conflict in any version control workflow: neither side can be blindly trusted, and the safest path is always to preserve, reconcile, and validate before pushing anything final. In this scenario, two sets of changes exist simultaneously — one in the workspace, one in the repository branch — and neither has been validated against the other. Option C is correct because it follows sound version control discipline: commit or branch both states so nothing is lost, manually reconcile the conflicting changes (deciding which edits to keep, combine, or discard), validate the merged result for correctness, and only then synchronize the resolved version back. This protects both contributors' work and ensures the final artifact is intentional and tested. Option A is wrong because workspace edits carry no automatic precedence in Fabric's Git sync. Choosing the workspace version without review would silently discard the developer's repository changes, which is exactly the kind of data loss conflict resolution is meant to prevent. Option B is wrong on two counts: the repository does not automatically capture workspace edits as hidden commits, and blindly selecting the Git version would discard the analyst's workspace changes just as recklessly. Option D describes a fictional behavior — disconnecting and reconnecting a Git branch does not merge or combine divergent versions. It simply re-establishes the connection and leaves the conflict unresolved. A good rule of thumb for the exam: whenever a question involves Git conflicts in Fabric, the correct answer will always emphasize preserving both states and reconciling deliberately, never choosing one side automatically.

Question 11

A team uses a Microsoft Fabric deployment pipeline with Development, Test, and Production workspaces. An administrator makes an emergency report-definition change directly in Production. The Development branch does not contain the change, and another deployment from Test is scheduled for the next day.

What should the team do to prevent the emergency change from being lost while maintaining a controlled version history?

  1. Export the Production report to PDF, deploy from Test as scheduled, and use the PDF to recreate any missing report formatting afterward.
  2. Cancel all future deployments and continue editing the Production report directly until the next complete release is ready.
  3. Reproduce the emergency change in the source-controlled development branch, validate it, and advance that version through the deployment process. (correct answer)
  4. Deploy from Test immediately because deployment pipelines automatically merge report-definition changes made independently in Production.
Explanation: Whenever you see a question about deployment pipelines and source control in Microsoft Fabric, anchor your thinking to one core principle: the source-controlled development branch is the single source of truth. Any change that bypasses that branch is at risk of being overwritten or lost. In this scenario, the emergency fix was made directly in Production, which means it exists outside version history. The safest path forward is C: reproduce the change in the Development branch, validate it through the normal pipeline stages (Dev → Test → Production), and let that controlled version become the authoritative record. This preserves both the fix and your audit trail, and it ensures the scheduled Test deployment doesn't silently overwrite the emergency change. A is a trap because exporting to PDF captures a static visual snapshot, not the actual report definition. You cannot reliably reverse-engineer metadata, measures, or formatting from a PDF — it's a lossy format for this purpose. B sounds pragmatic under pressure but is exactly the anti-pattern deployment pipelines exist to prevent. Editing Production directly long-term creates drift, removes peer review, and breaks the integrity of your version history indefinitely. D reflects a dangerous misconception: deployment pipelines do not automatically merge or reconcile independent changes made in Production. Deploying from Test would simply overwrite the Production report, erasing the emergency fix entirely. Study tip: On Power BI and Fabric exam questions, any answer that bypasses the source-controlled branch in favor of a shortcut (PDFs, direct edits, "automatic merging") is almost always wrong. The pipeline exists to enforce discipline — trust the process.

Question 12

A widely used semantic model contains a measure named Revenue YTD. Twelve thin reports connect to the model. A developer plans to replace the measure with a renamed measure whose calculation also changes. The reports cannot all be updated and released simultaneously.

Which strategy best minimizes version-related disruption?

  1. Delete the existing measure, publish the renamed measure, and allow each report owner to repair broken visuals during the next maintenance cycle.
  2. Rename the measure directly in Production because thin reports retain private copies of every referenced measure definition.
  3. Change the calculation under the existing measure name and postpone documentation until all reports have been checked by consumers.
  4. Create a versioned replacement while retaining compatibility, test dependent reports, and retire the old measure after a coordinated migration. (correct answer)
Explanation: When managing shared semantic models in Power BI, the central challenge is maintaining backward compatibility — ensuring that reports built on your model continue functioning while you introduce changes. Any widely used model with multiple dependent reports requires a migration strategy, not a one-step replacement. The safest approach, confirmed by option D, is to create the new renamed measure alongside the existing one, validate that dependent reports still render correctly, and only retire the original measure after all twelve report owners have migrated. This phased deprecation pattern is a standard practice in enterprise Power BI governance — it eliminates the "big bang" risk of simultaneous breakage and gives teams time to update on their own schedules. Option A is dangerous precisely because deleting the original measure immediately breaks every visual that references it across all twelve reports. Pushing the repair burden to "the next maintenance cycle" means users encounter broken dashboards in the interim — exactly the disruption you're trying to avoid. Option B contains a critical misconception: thin reports do not retain private copies of measure definitions. Thin reports read measures directly from the shared semantic model at runtime. Renaming a measure in Production immediately orphans every visual that referenced the old name, causing widespread failures. Option C avoids renaming (so references stay intact), but silently changing the calculation logic without documentation or communication is a governance violation. Consumers relying on "Revenue YTD" will receive different numbers with no warning, eroding trust in the model. Your study tip: on Power BI exam questions involving shared models, always favor the answer that preserves existing references while introducing changes incrementally — deprecation beats deletion every time.

Question 13

Several developers must maintain a complex Power BI solution. They need meaningful text-based comparisons of semantic model changes, the ability to review pull requests, and fewer conflicts than they experience when committing a single binary file.

Which version-management approach best meets these requirements?

  1. Store the PBIX file in Git and configure Git Large File Storage so reviewers can compare individual measure definitions in the binary file.
  2. Publish each draft to a separate workspace and use workspace names as version identifiers instead of maintaining repository branches.
  3. Export each release as a Power BI template file and compare template files directly during pull-request reviews.
  4. Save the solution as a Power BI project, maintain its supported text-based files in Git, and review changes through branches and pull requests. (correct answer)
Explanation: When a question asks about version control for collaborative Power BI development, focus on three requirements: text-based diffs, pull request reviews, and reduced merge conflicts. These requirements map directly to a specific Power BI feature set, so knowing that feature is the key. The Power BI Project format (.pbip) is designed precisely for this scenario. When you save a solution as a Power BI project, it decomposes the semantic model into individual text-based files — measure definitions, table schemas, relationships, and more — stored in a structured folder. Because everything is plain text, Git can show line-by-line differences, teammates can leave comments on specific measure changes in a pull request, and two developers editing different tables rarely touch the same file, dramatically reducing conflicts. Option D describes this workflow exactly and satisfies all three stated requirements. Option A fails because PBIX is a binary format. Git LFS helps store large binary files, but it cannot make Git produce meaningful text diffs of measure definitions inside a binary — reviewers still see an opaque blob, not readable code. Option B sidesteps version control entirely. Using workspace names as version identifiers provides no diff capability, no pull request process, and no conflict resolution — it simply duplicates environments rather than managing change history. Option C is a common trap. Power BI template files (.pbit) strip out data but remain binary-structured, so comparing two templates in a pull request still doesn't yield readable, line-level differences for measure logic. Study tip: On Power BI exam questions involving team collaboration and source control, the answer almost always involves Power BI Projects (.pbip) — learn how that format structures its files and why text-based storage enables Git workflows.

Question 14

An organization must be able to determine exactly which report and semantic model definitions were deployed during each monthly release. Administrators currently keep only the active workspace content and occasionally download PBIX files with names such as Final, Final2, and FinalApproved.

Which practice most directly improves release traceability and recoverability?

  1. Keep the naming convention but add the deployment date to every PBIX filename stored on an administrator's local computer.
  2. Maintain the supported project source in a repository and associate each validated deployment with an immutable release tag or commit identifier. (correct answer)
  3. Rely on semantic model refresh history because each successful refresh records the complete report and model definitions that were deployed.
  4. Retain only the Production workspace because deployment pipelines can reconstruct any historical release from the current target contents.
Explanation: When a question asks about release traceability and recoverability, think about version control fundamentals: you need a system that can precisely identify what was deployed, when, and allow you to restore it exactly. Ad hoc file management on someone's desktop simply cannot meet that bar. Storing project source files in a version control repository (such as Git) and tagging each validated deployment with an immutable release tag or commit ID is the gold standard. That tag permanently points to the exact state of every file at that moment — report definitions, semantic model definitions, everything — so you can audit or roll back any historical release with confidence. This is why B is correct. Option A might seem like an improvement because adding dates to filenames gives you a timeline, but filenames on a local computer are fragile: files can be overwritten, moved, or deleted, and there's no integrity guarantee. "FinalApproved_2024-01-15.pbix" stored locally is still an uncontrolled artifact. Option C is a common trap. Semantic model refresh history records data refresh events — timestamps and success/failure status — not the definitions of the report or model itself. You cannot reconstruct a deployment from refresh logs. Option D misunderstands how deployment pipelines work. Pipelines move content forward (Dev → Test → Prod), but they don't archive historical states. The Production workspace only holds the current version; previous releases are gone once overwritten. Study tip: On Power BI governance questions, watch for answers that confuse operational history (refresh logs, workspace content) with version history. True traceability requires source control with immutable identifiers — not timestamps bolted onto filenames or activity logs.