Microsoft Power BI Quiz: Creating And Saving Reports
10 questions · exam conditions
0:00
Creating And Saving ReportsQuestion 1 of 10

A report uses Import mode for a CSV file stored at C:\Finance\Actuals.csv. The report is saved as Finance.pbix and sent to another analyst. The recipient has no access to that path but can open the PBIX and initially view the saved report pages.

Which statement best explains the expected behavior?

The report can display imported data, but refresh will fail until the source path and access are corrected.
The report cannot open because a PBIX stores only the CSV path and never stores imported data.
The report refreshes automatically because saving a PBIX embeds the source file and its credentials.
The report opens as read-only because PBIX files cannot be edited on a different computer.
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Creating And Saving Reports

Practice Creating And Saving Reports 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 Creating And Saving Reports, 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 report uses Import mode for a CSV file stored at C:\Finance\Actuals.csv. The report is saved as Finance.pbix and sent to another analyst. The recipient has no access to that path but can open the PBIX and initially view the saved report pages.

Which statement best explains the expected behavior?

  1. The report can display imported data, but refresh will fail until the source path and access are corrected. (correct answer)
  2. The report cannot open because a PBIX stores only the CSV path and never stores imported data.
  3. The report refreshes automatically because saving a PBIX embeds the source file and its credentials.
  4. The report opens as read-only because PBIX files cannot be edited on a different computer.
Explanation: When working with Power BI's Import mode, the key distinction to understand is the difference between data storage and data source connectivity. Import mode physically copies data into the PBIX file at the time of import, but it still remembers where that data originally came from for future refreshes. This is exactly what makes A correct: because the data was imported, it travels inside the PBIX file itself. The recipient can open the file and view all report pages normally — the visuals render from the embedded dataset, not from a live connection. However, the moment they click "Refresh," Power BI attempts to reconnect to C:\Finance\Actuals.csv. Since that path doesn't exist on their machine, the refresh fails. The data becomes stale but remains visible until refreshed. B describes DirectQuery or live connection behavior, not Import mode. In Import mode, Power BI absolutely stores a copy of the data — the PBIX would be useless for offline viewing otherwise. C contains a dangerous half-truth: saving does embed the data, but it does not embed credentials or make refresh automatic or path-independent. Refresh still requires valid access to the original source location. D is simply false. PBIX files are fully editable on any machine running Power BI Desktop, regardless of where they were originally created. Read-only status is not a cross-computer restriction. A useful pattern to remember: Import mode = data travels with the file, refresh path does not. Any question pairing "sent to another user" with Import mode should immediately make you think about the refresh-versus-view distinction.

Question 2

A developer must provide a reusable report starter containing Power Query steps, model relationships, measures, report pages, and parameters. The file must not contain the confidential rows currently imported into the model. Each recipient should supply parameter values and load data when creating a report.

Which file type should the developer create?

  1. A PBIX file, because it retains the model and all currently imported rows.
  2. A PDF file, because it retains the pages while removing model metadata.
  3. A PBIT file, because it retains report definitions without imported model data. (correct answer)
  4. A CSV file, because it retains measures, relationships, and parameter definitions.
Explanation: When you see a question about distributing reusable Power BI content without exposing imported data, think about Power BI's different file formats and what each one preserves or discards. The .pbit format — the Power BI Template file — is specifically designed for this scenario. It stores everything a report developer builds: Power Query steps, data model relationships, DAX measures, report pages, and parameters. Critically, it strips out all imported row data before saving. When a recipient opens a .pbit file, Power BI prompts them to enter parameter values and then refreshes the data from the source. This makes C the correct answer, matching every requirement in the passage exactly. Choice A is wrong because a .pbix file retains the full dataset, including all currently imported rows. Sharing it would expose the confidential data the developer is specifically trying to exclude. Choice B is wrong because a PDF is a static visual export — it captures the visual appearance of report pages but loses all model metadata, relationships, measures, and Power Query logic entirely. It cannot be used as a report starter. Choice D is wrong because a CSV is a plain text data format. It holds tabular values only and has no concept of DAX measures, model relationships, or parameters whatsoever. A useful memory trick: think of PBIT as "PBI Template" — the "T" signals it's a skeleton without data flesh. Whenever an exam question combines the words reusable, no imported data, and parameters, that's your signal to reach for the .pbit format.

Question 3

A company stores Development, Test, and Production report files in one shared folder. All three files are named Sales.pbix, so users frequently open or publish the wrong version. The model and report design are otherwise valid.

Which change most directly improves project organization while preserving separate lifecycle versions?

  1. Combine all environments into one PBIX and select the environment from a report slicer.
  2. Store each PBIX in an environment-specific folder and apply a consistent filename convention. (correct answer)
  3. Export each environment to PDF and delete the corresponding PBIX working files.
  4. Keep identical paths and names but use different report-page background colors.
Explanation: When you encounter Power BI project organization questions, think about the core principles of ALM (Application Lifecycle Management): keeping environments isolated, reducing human error, and maintaining clear traceability across Development, Test, and Production stages. The root problem here is ambiguity — three files share the same name and location, making it trivially easy to open or publish the wrong one. Answer B solves this directly by separating each PBIX into its own environment-specific folder (e.g., /Dev/Sales.pbix, /Test/Sales.pbix, /Prod/Sales.pbix) and applying a consistent naming convention. This preserves all three working files, keeps lifecycles distinct, and costs nothing in terms of rework — the model and report design are already valid. Answer A collapses three environments into one file, which actually eliminates lifecycle separation. A slicer controlling "environment" is a report UX pattern, not a deployment strategy — you'd be publishing dev data alongside prod data. Answer C converts PBIX files to static PDFs and deletes the source files. PDFs cannot be edited, published to the Power BI service, or refreshed — this destroys the working files entirely and defeats the purpose of maintaining separate versions. Answer D keeps identical names and paths, so the original problem — users opening the wrong file — persists completely. Background colors are cosmetic; they don't prevent someone from publishing the Dev file to Production. As a study tip, Power BI exam questions about lifecycle management almost always reward answers that maintain file integrity and reduce ambiguity through structure, not workarounds. If an option eliminates the source file or collapses environments, it's almost certainly wrong.

Question 4

A report is created as a thin report that uses a live connection to an existing Power BI semantic model. The author saves the report as RegionalAnalysis.pbix and sends it to another authorized user.

What does the saved PBIX primarily contain in this scenario?

  1. The remote workspace itself, including its permissions, apps, and deployment history.
  2. A complete imported copy of the remote semantic model and all of its source credentials.
  3. Only cached visual images, with no report definition or connection information retained.
  4. The report definition and connection information, while the remote semantic model remains external. (correct answer)
Explanation: When you see a question about thin reports and live connections in Power BI, focus on the fundamental architecture: a thin report is intentionally lightweight, acting as a presentation layer that sits on top of a separately hosted semantic model. When an author creates a report using a live connection to an existing Power BI semantic model and saves it as a .pbix file, that file stores the report definition — visuals, pages, formatting, filters — along with the connection metadata pointing to the remote semantic model. The actual data, tables, and measures remain in the external semantic model hosted in the Power BI service. This is precisely what D describes, making it correct. The recipient can open the file and, provided they have authorization, connect to the same remote model. A is wrong because a .pbix file has no ability to capture workspace-level configurations like permissions, apps, or deployment pipelines — those are service-side constructs entirely outside the file's scope. B is wrong because a live connection explicitly means data is not imported into the file; importing data would defeat the purpose of a live connection and would also make credentials embedded in the file a serious security concern. C is wrong because the file does retain the full report definition (layout, visuals, measures references) — it is not simply a screenshot or image cache. A useful memory anchor: think of a thin report .pbix as a map, not a territory. It tells Power BI where to find the data and how to display it, but the data itself lives elsewhere.

Question 5

A team wants to place a Power BI solution in a Git repository. Reviewers must be able to inspect changes to report and semantic-model definitions as text-based files instead of treating every revision as a single opaque binary file. The team does not require the working artifact to be one PBIX file.

Which saving approach best meets the requirement?

  1. Save the solution as a PBIP project and commit the supported project files and folders. (correct answer)
  2. Save the solution as a PBIX file and rely on Git to merge internal binary changes.
  3. Export the solution as a PDF file and commit one PDF for each report revision.
  4. Save the solution as a PBIT file and compare the imported data between revisions.
Explanation: When a question asks about source-control-friendly Power BI development, you should immediately focus on which format exposes report and semantic-model internals as readable, diffable text rather than a compressed binary blob. Power BI's PBIP (Power BI Project) format does exactly this. When you save as a PBIP project, Power BI Desktop writes report definitions, data model metadata, and other components as separate, human-readable files (JSON, TMDL, etc.) inside a structured folder hierarchy. Reviewers can open a pull request and see line-by-line changes to measure definitions, visuals, or relationships — just like reviewing any code change. This makes A the correct answer and directly satisfies the requirement for text-based inspection without needing a single PBIX file. Choice B fails because a PBIX file is a ZIP-compressed binary package. Git can store it, but it cannot meaningfully diff internal changes — every revision appears as an opaque binary swap, which is exactly what the question says must be avoided. Choice C is a non-starter: a PDF is a read-only presentation export with no editable definition; committing PDFs provides no way to inspect or merge semantic-model or report logic. Choice D is similarly wrong — a PBIT is a template file that still packages model and report structure in a binary-like format and does not expose individual component changes as text; "comparing imported data between revisions" is not a meaningful source-control workflow. Study tip: On Power BI exam questions about Git integration and collaborative development, PBIP is the keyword to remember. If the scenario mentions readable diffs, text-based files, or avoiding binary blobs, PBIP is almost always the answer.

Question 6

A team maintains Baseline.pbix as an approved starting point. An analyst opens the file and must create a customer-specific report while ensuring that subsequent saves cannot overwrite the approved baseline.

What should the analyst do before making customer-specific changes?

  1. Publish Baseline.pbix to a personal workspace and edit the published report.
  2. Use Save As to create a new PBIX file in the customer's project folder. (correct answer)
  3. Use Save and rename the report after it has been published.
  4. Export Baseline.pbix as a PDF and save the PDF in the customer folder.
Explanation: When working with shared or approved template files in Power BI, your primary concern is protecting the original while creating an independent working copy. The key question to ask yourself is: "If I save right now, will I overwrite something I shouldn't?" Save As is the correct tool here precisely because it creates a brand-new PBIX file at a location you specify, completely severing the save path from the original. Once you choose B and save to the customer's project folder, all subsequent Ctrl+S saves write to that new file — Baseline.pbix is never touched. This is the standard, reliable way to branch from a shared starting point in any file-based workflow. A is tempting but flawed: publishing to a personal workspace puts the report in the Power BI Service, but the local Baseline.pbix file remains your active document. If you accidentally hit Save in Desktop, you still overwrite the baseline. Publishing doesn't protect the source file. C describes renaming after publishing — but the rename happens in the Service, not on the local file. The original PBIX is still at risk before and during editing, and renaming a published report doesn't create a separate local working file at all. D exports to PDF, which produces a static, non-editable snapshot. You cannot make customer-specific report changes inside a PDF — it defeats the entire purpose of working in Power BI Desktop. A useful rule of thumb: whenever a question mentions "protecting an original" or "preventing overwrites," Save As is almost always the right move. It's the foundational file-management step before any branching work begins.

Question 7

An analyst has completed an Import-mode report and must archive the exact editable state used for a monthly close. The archive must remain unchanged, while work for the next month should continue from the same model and report design.

Which workflow best satisfies both requirements?

  1. Convert the completed report to CSV, then reopen the CSV as the next month's report.
  2. Continue editing the archived PBIX, then export a PDF when the next month is complete.
  3. Publish the completed report twice and use the two workspace display names as file versions.
  4. Save the completed PBIX in the archive, then use Save As to create the next month's working copy. (correct answer)
Explanation: When working with Power BI files (.pbix), you need to understand the difference between archiving a state and continuing development — these are two distinct needs that require two distinct files. The key tool here is Save As, which creates an independent copy while leaving the original untouched. Option D is the correct workflow because it directly satisfies both requirements simultaneously. You save the completed PBIX in its final state as the archive — that file is never touched again. Then you use Save As to produce a new working copy for next month's work. Both the model structure and report design carry forward, and the archive remains a faithful, editable snapshot of the monthly close. Option A fails because converting to CSV destroys the Power BI model entirely — you lose all measures, relationships, formatting, and report layout. A CSV is raw data, not a report archive. Option B inverts the logic entirely. Continuing to edit the archived file means the "archive" is no longer preserved — it gets overwritten with next month's changes. Exporting a PDF at the end only captures a static, non-editable image, which doesn't meet the requirement of archiving an editable state. Option C misunderstands how versioning works in Power BI. Publishing the same report twice and relying on workspace display names provides no real file-level separation. If the source PBIX is edited, both published reports pull from the same file, and neither serves as a true frozen archive. A useful pattern to remember: whenever an exam question mentions preserving an editable state and continuing work, think Save As — it's Power BI's built-in file-branching mechanism.

Question 8

A report author opens an existing PBIX, makes several changes, and then Power BI Desktop closes unexpectedly. When Desktop restarts, it offers a recovered version. The team requires changes to be retained in the official project location under the approved filename.

What should the author do?

  1. Open the recovered version, verify it, and explicitly save it to the approved PBIX path. (correct answer)
  2. Assume recovery updated the official PBIX and delete the recovered version without opening it.
  3. Publish the recovered version because publishing always overwrites the approved local PBIX.
  4. Export the recovered pages to PDF because recovery files cannot be saved as PBIX files.
Explanation: When Power BI Desktop crashes, it automatically creates a recovery file — a temporary saved state of your unsaved work. This question tests whether you understand that a recovery file is separate from your official PBIX and requires deliberate action to preserve it properly. The right move is A: open the recovered version, verify that your changes are intact, and then use File → Save As to explicitly save it to the approved project path and filename. Recovery files live in a temporary location and are not automatically merged into your original file. Only you can confirm the changes are correct and overwrite the official PBIX. B is dangerous — assuming the recovery process silently updated the official file is incorrect. The original PBIX remains in whatever state it was in before the crash; Power BI Desktop does not auto-save back to your source file. C confuses publishing with saving. Publishing sends the report to the Power BI Service (the cloud), but it does not write anything back to your local PBIX file. The official local file would remain unchanged, violating the team's requirement. D is simply false. Recovery files are valid PBIX files — you can open and save them normally. Exporting to PDF would discard all data model work, relationships, and measures, keeping only static page images. Study tip: On Power BI exam questions involving recovery, crashes, or unsaved changes, always focus on the distinction between the temporary recovery file and the official saved PBIX. Anything short of an explicit Save As to the approved path leaves the official file untouched.

Question 9

An analyst creates a report in Power BI Desktop by importing an Excel workbook, building relationships and measures, and adding three report pages. The analyst must create a locally editable deliverable that retains the imported data currently loaded into the model.

Which action should the analyst take?

  1. Save the report as a PBIX file by using File > Save As. (correct answer)
  2. Export the report as a PDF file by using File > Export.
  3. Save the report as a PBIT file by using File > Save As.
  4. Publish the report to a workspace without saving a local file.
Explanation: When a question asks about creating a locally editable deliverable that retains imported data, you need to think carefully about Power BI's file formats and what each one actually stores. A PBIX file is Power BI Desktop's native working format. It packages everything together: your report pages, the data model, imported data, relationships, measures, and visuals — all in one portable, locally editable file. Saving via File > Save As and choosing PBIX (option A) is exactly the right move here, because the analyst can reopen it in Power BI Desktop, make changes, and the imported Excel data travels with the file without requiring a reconnection. Option B (exporting as PDF) produces a static, read-only snapshot of the report pages. There's no way to edit visuals, modify measures, or interact with the data model — it's purely for sharing a visual output. Option C is a common trap. A PBIT file is a Power BI Template, which intentionally strips out the imported data. Templates are designed to share the structure (layout, measures, relationships) while requiring the recipient to supply fresh data. Since the question explicitly requires retaining the currently loaded data, PBIT is the wrong choice. Option D (publishing to a workspace) pushes the report to the Power BI Service online, but the question specifies a local deliverable. Publishing doesn't create or save a local file, and editing in the Service is a different workflow. Study tip: On the Power BI exam, always distinguish between PBIX (includes data, fully editable locally) and PBIT (template, data stripped out). That distinction appears frequently in scenario-based questions.

Question 10

An analyst creates an unsaved report named Report1 in Power BI Desktop. After building the model, the analyst publishes it to a workspace and then closes Desktop. The organization's process requires an authoritative PBIX file in a controlled network folder.

Which conclusion is most accurate?

  1. Publishing automatically creates the required PBIX in the last network folder used by Desktop.
  2. Publishing changes the service artifact into the authoritative local PBIX without another action.
  3. Publishing does not replace saving; the analyst must save the PBIX to the controlled folder. (correct answer)
  4. Publishing creates a PBIT locally, which can later be renamed with a PBIX extension.
Explanation: Whenever you see a Power BI question involving "publish," remember that publishing and saving are two completely separate, independent operations. Publishing sends your report and dataset up to the Power BI service; saving writes the .pbix file down to your local or network storage. Neither action triggers the other automatically. In this scenario, the analyst published without ever saving. That means the Power BI service now hosts the report artifact, but no .pbix file exists anywhere on disk — not on the network folder, not on the analyst's local machine. Because the organization requires an authoritative PBIX in a controlled network folder, the analyst must go back and explicitly do File → Save As in Power BI Desktop, targeting that folder. That's exactly what C captures: publishing does not replace saving, and the analyst must perform a separate save action. Choice A is wrong because Desktop has no concept of a "last network folder used" — it doesn't auto-save or auto-export a PBIX to any location upon publish. Choice B reverses the direction of the workflow entirely; publishing moves content to the service, it doesn't create or modify a local file. Choice D is a fabrication — publishing does not generate a PBIT (template file) locally, and even if it did, a PBIT is not interchangeable with a PBIX simply by renaming it. As a study tip: on the PL-300 exam, watch for questions that conflate the publish action with save/export actions. Always ask yourself: "Which direction is data moving, and which storage location is affected?" That mental check will protect you from several common traps.