Microsoft Power BI Quiz: Power Bi Desktop Interface
10 questions · exam conditions
0:00
Power Bi Desktop InterfaceQuestion 1 of 10

A table contains MonthName and MonthNumber columns. A chart sorts MonthName alphabetically, but it must display months chronologically. The model must retain MonthName as the field shown to users.

Which workflow should you use?

In Report view, sort the chart by MonthName descending and then reverse the visual's category axis.
In Data view, select MonthName, set Sort by column to MonthNumber, and then use MonthName in the chart.
In Model view, create a relationship from MonthName to MonthNumber and set the relationship as bidirectional.
In Data view, sort the displayed rows by MonthNumber and save that row order with the report.
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Power Bi Desktop Interface

Practice Power Bi Desktop Interface 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 Power Bi Desktop Interface, 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 table contains MonthName and MonthNumber columns. A chart sorts MonthName alphabetically, but it must display months chronologically. The model must retain MonthName as the field shown to users.

Which workflow should you use?

  1. In Report view, sort the chart by MonthName descending and then reverse the visual's category axis.
  2. In Data view, select MonthName, set Sort by column to MonthNumber, and then use MonthName in the chart. (correct answer)
  3. In Model view, create a relationship from MonthName to MonthNumber and set the relationship as bidirectional.
  4. In Data view, sort the displayed rows by MonthNumber and save that row order with the report.
Explanation: When a chart sorts months alphabetically instead of chronologically, the fix lives in how Power BI understands the data — not in how the visual is configured. This is the Sort by Column feature, and recognizing when to use it is essential for the Power BI exam. The right approach, choice B, is to open Data view, select the MonthName column, and set its "Sort by Column" property to MonthNumber. This instructs Power BI to use MonthNumber as the underlying sort key whenever MonthName is displayed anywhere in the report. Because the sort is baked into the data model, every visual that uses MonthName will automatically respect chronological order — no per-visual workarounds needed. Choice A is tempting but flawed: sorting a chart descending by MonthName just reverses alphabetical order (December → January), which is still alphabetical, not chronological. Reversing the axis doesn't fix the root problem either. Choice C misunderstands relationships entirely — relationships connect tables for filtering and lookup purposes, not for controlling sort order within a column. Creating a relationship between two columns in the same table isn't even valid in Power BI. Choice D is a dead end: row order in Data view is a display convenience for analysts. Power BI does not persist or use that row order when rendering visuals. Study tip: Whenever a question describes a column that displays one thing but needs to sort by another, immediately think "Sort by Column" in Data view. This is a classic Power BI exam pattern — the display column and the sort column are always kept separate.

Question 2

You import a customer table and discover that the text value N/A must be replaced with null before the data is loaded into the semantic model. After applying the change, you must inspect the loaded rows without creating a visual.

Which sequence should you use?

  1. Open Power Query Editor from Transform data, replace the values, apply the query changes, and inspect the table in Data view. (correct answer)
  2. Open Data view, replace the values directly in the loaded table, save the model, and inspect the table in Report view.
  3. Open Model view, replace the values by editing the table properties, refresh the relationships, and inspect the relationship diagram.
  4. Open Report view, replace the values by using a visual-level filter, refresh the visual, and inspect the filtered data points.
Explanation: When a question asks about transforming data before it loads into the semantic model, your mind should immediately jump to Power Query Editor — this is the dedicated environment for shaping, cleaning, and transforming raw data prior to loading. The correct workflow is option A. You access Power Query Editor through Transform data, where you can use the "Replace Values" feature to swap "N/A" with null. Once done, selecting Close & Apply pushes those clean transformations into the model. To then inspect the loaded rows without building a visual, you switch to Data view — this gives you a raw tabular look at every row in your table, exactly what the question requires. Option B is flawed because Data view does not allow you to edit cell values directly — it's read-only. You can't replace values there, and "saving" a change that way isn't a valid workflow in Power BI Desktop. Option C misleads you into Model view, which is designed for managing relationships and table schemas, not for replacing data values. You cannot edit the actual data content from table properties. Option D confuses a visual-level filter with a data transformation. Filters in Report view only hide data from a visual — they don't alter the underlying table or replace values in the semantic model, which is what the question explicitly requires. Study tip: Memorize the purpose of each Power BI view: Report view = visuals, Data view = inspect loaded rows, Model view = relationships, Power Query = transform before load. Exam questions frequently test whether you can match the right tool to the right task.

Question 3

A report contains Sales, Customer, and Region tables. Selecting a region produces unexpected sales totals. You suspect that two active relationship paths or an incorrect cross-filter direction is propagating filters through the model.

Which Power BI Desktop view should you use first, and what should you examine?

  1. Use Report view and examine the visual interaction settings and the order in which report filters appear.
  2. Use Data view and examine whether the Sales rows are physically sorted by customer and region.
  3. Use Model view and examine relationship activity, cardinality, and cross-filter direction among the tables. (correct answer)
  4. Use Power Query Editor and examine the Applied Steps order for every table in the model.
Explanation: When troubleshooting unexpected filter behavior in Power BI, your first instinct should be to visualize how tables are connected, not how data is displayed or transformed. Filter propagation problems — like ambiguous paths or incorrect cross-filter directions — live entirely in the data model layer, making Model view your diagnostic starting point. In Model view, you can inspect exactly what you need: whether relationships between Sales, Customer, and Region are active or inactive, the cardinality of each relationship (one-to-many, many-to-many), and critically, the cross-filter direction (single vs. both). If two active paths exist between tables, Power BI may produce ambiguous or incorrect filter results. If cross-filter direction is set to "Both" unintentionally, filters can propagate in unexpected ways, inflating or distorting sales totals. Model view gives you a visual map of all these properties at once, confirming C as the correct first step. A is a trap because visual interaction settings in Report view only control how visuals filter each other on the canvas — they don't reveal underlying relationship issues causing the calculation errors. B is wrong because physical row sorting in Data view has no bearing on how filters propagate through relationships; sorting is a display property, not a model property. D is a distractor because Power Query Editor governs data shaping and loading, not relationship behavior — Applied Steps won't reveal cross-filter or cardinality issues. As a study tip: whenever a Power BI question mentions unexpected totals or filter behavior across multiple tables, immediately think "relationship model" — cardinality, direction, and active vs. inactive relationships are the usual culprits.

Question 4

A model field is named Total Sales. On one chart only, the business wants the displayed field label to be Net Revenue. Other visuals, DAX expressions, and the model field name must remain unchanged.

Where should you make the change?

  1. In Report view, use Rename for this visual on the field assigned to the chart. (correct answer)
  2. In Model view, rename the measure and allow all dependent visuals to update automatically.
  3. In Data view, rename the field and prevent the change from propagating to other pages.
  4. In Power Query Editor, rename the source column only in the final Applied Step.
Explanation: When Power BI asks you to change a field label for one visual only without touching the underlying model, you're being tested on the distinction between model-level changes and visual-level display overrides. In Report view, every field assigned to a visual has a context menu that includes a Rename for this visual option. This lets you type a custom display name — like "Net Revenue" — that appears only on that specific chart. The model field (Total Sales), any DAX measures referencing it, and all other visuals remain completely untouched. This scoped rename is exactly what the scenario requires, making A the correct answer. The wrong answers each represent a broader, model-wide change that violates the requirement. B is tempting because renaming in Model view feels "official," but renaming a measure there propagates the change everywhere — every visual, every DAX expression that uses the display name, and the field list itself. That's the opposite of what's needed. C describes renaming in Data view, which also updates the field at the model level; there is no native mechanism in Data view to "prevent propagation to other pages" — Power BI doesn't work that way. D suggests renaming in Power Query, which operates at the data-source/ETL layer. Any rename there flows upstream into the model and affects everything downstream, making it the most disruptive option of all. The study tip here: whenever a question specifies a single visual change with no model impact, think Report view → field context menu → Rename for this visual. Scope is the keyword — match the scope of the tool to the scope of the requirement.

Question 5

You must create a calculated column that classifies each transaction. Before relating the classification to a lookup table, you must inspect the calculated result for individual rows and then configure the new relationship.

Which sequence most directly supports both tasks?

  1. Create the calculated column in Report view, and then configure the relationship by editing visual interactions.
  2. Create and inspect the calculated column in Data view, and then configure the relationship in Model view. (correct answer)
  3. Create and inspect the calculated column in Model view, and then configure the relationship in Data view.
  4. Create the calculated column in Power Query Editor, and then configure the relationship in the query dependency view.
Explanation: When working in Power BI Desktop, each view serves a distinct purpose, and exam questions about workflows often test whether you know which view is the right tool for each task. Think of it this way: Data view lets you see your actual table data row by row, Model view is where you manage relationships between tables, and Report view is for building visuals. For this scenario, you need to do two things: create and inspect a calculated column at the row level, then wire up a relationship. Data view is the ideal place to write a DAX calculated column because you can immediately see how the formula evaluates for every individual row in the table — exactly what "inspecting the calculated result" requires. Once you've confirmed the column looks correct, you switch to Model view, where you can drag fields between tables to create and configure the new relationship. That makes B the correct sequence. A is wrong because Report view is for building visuals, not for inspecting raw row-level column values. You'd also configure relationships in Model view, not through "visual interactions," which controls how visuals filter each other on a report page — a completely different feature. C reverses the tools: Model view doesn't display row-level data for inspection, and Data view doesn't have relationship configuration tools. The tasks are assigned to the wrong views. D is wrong because Power Query Editor transforms data before it loads into the model, making it unsuitable for DAX calculated columns. The "query dependency view" shows query dependencies, not relationship management. A reliable study tip: memorize the three main views by their primary job — Report = visuals, Data = row inspection, Model = relationships.

Question 6

A table used by several measures does not appear in the Data pane while you are building a report. A colleague says the table was hidden from report view. You need to verify that the table still exists and make it available to report authors again.

What should you do?

  1. Use Report view, clear all page and visual filters, and refresh the Data pane to restore the table.
  2. Use Data view, refresh the table preview, and change its data category to an unhidden category.
  3. Use Model view, locate the hidden table, and change its hidden property so it appears in report view. (correct answer)
  4. Use Power Query Editor, enable load for every query, and duplicate the table under a visible name.
Explanation: When working in Power BI Desktop, visibility of tables is a modeling property, not something controlled by filters, data categories, or query load settings. This question is testing whether you understand the difference between the three main views in Power BI Desktop and which one governs how objects appear to report authors. When a table is hidden from report view, it still exists in the model — it simply has its hidden property toggled on. This is done intentionally to keep the Data pane clean, often for tables that only support relationships or calculations. To reverse this, you go to Model view, find the table (it appears grayed out when hidden), and toggle its hidden property back off. That's exactly what option C describes, making it the correct answer. Option A is wrong because filters and the Data pane refresh have nothing to do with table visibility — clearing filters only affects what data is displayed in visuals, not what appears in the field list. Option B misleads you into thinking data categories control visibility, but data categories classify data types (like geography or URLs) and have no effect on whether a table shows up in the Data pane. Option D confuses the issue entirely — enabling query load in Power Query Editor controls whether a query's results are loaded into the model at all, which is a different problem from hiding. Duplicating a table just creates redundancy and doesn't fix the original table's visibility. A useful rule of thumb: if a question mentions something being hidden from report view, always think Model view properties first — that's where visibility is controlled in Power BI.

Question 7

While troubleshooting imported data, you filter and sort a table in Data view. You then switch to Report view, but an existing chart still shows all records in its original category order.

Which explanation and corrective action are most appropriate?

  1. Data view filtering changes only the inspection display; apply an appropriate report, page, or visual filter in Report view. (correct answer)
  2. Data view filtering changes the semantic model; refresh the report canvas so the persisted row filter is propagated.
  3. Data view sorting changes relationship direction; restore the original direction in Model view before filtering the chart.
  4. Data view sorting changes source row order; rerun every Power Query step before opening Report view.
Explanation: Whenever you see a question about Power BI's Data view, the key concept to remember is the separation of concerns between the authoring environment and the live semantic model. Data view is essentially a read-only inspection window — it lets you explore, filter, and sort your data locally for troubleshooting purposes, but none of those interactions write back to the underlying dataset or affect what visuals render in Report view. That's precisely why A is correct. Filtering or sorting in Data view is purely cosmetic for your diagnostic session. The chart in Report view continues drawing from the full, unfiltered dataset because your Data view actions never touched the semantic model. The proper fix is to apply a filter at the report, page, or visual level in Report view, which does instruct the query engine to restrict the data returned to that visual. B is wrong because Data view filtering does not persist to the semantic model — there is no "persisted row filter" to propagate, and refreshing the canvas changes nothing about what you did in Data view. C invents a false connection between sorting behavior and relationship direction; sorting a table in Data view has zero effect on relationship cardinality or direction in Model view. D is similarly fabricated — row order in a Power Query source has no bearing on visual category order in charts, which is controlled by sort settings within the visual itself. A useful study tip: on Power BI exam questions, watch for distractors that imply Data view is a data-editing tool — it isn't. Any real change to filtering, shaping, or modeling happens in Power Query, Model view, or Report view filters, never in Data view.

Question 8

To make a complex semantic model easier to understand, you rearrange tables in Model view and create a separate model layout containing only finance-related tables. You do not edit any relationships or object properties.

What is the expected effect of these changes?

  1. The finance tables will be filtered first because model-layout position determines relationship evaluation order.
  2. Report pages will automatically adopt the table positions as a new visual layout for finance users.
  3. Tables excluded from the finance layout will be removed from the model and hidden from all reports.
  4. The model diagram becomes easier to navigate, but report layouts and model calculations remain unchanged. (correct answer)
Explanation: When working with Power BI's Model view, it's important to distinguish between cosmetic/organizational changes and structural changes that affect data, relationships, or calculations. This question tests exactly that boundary. Rearranging tables in Model view and creating a custom layout are purely visual, organizational actions. You're essentially reorganizing how the diagram looks to you as a developer — nothing underneath changes. Relationships, DAX measures, calculated columns, and report visuals all remain completely unaffected. That's why D is correct: the model becomes easier to navigate visually, but nothing functional is altered. A is wrong because Power BI does not determine relationship evaluation order based on where tables are positioned in the diagram. Relationship evaluation is governed by the model's defined relationships, cardinality, and cross-filter direction — not physical placement on the canvas. B is wrong because Model view layouts have no connection to report pages. Moving tables around in the model diagram does not rearrange or influence any report page visuals. Report layouts are managed entirely within Report view. C is wrong because custom layouts are additive and optional — they let you create focused views of a subset of tables without deleting or hiding anything from the broader model. Tables excluded from a layout still exist fully in the model and remain accessible to all reports. A useful study tip: whenever a Power BI question mentions changes made only in Model view's visual canvas (dragging, grouping, custom layouts), the answer almost always involves "no functional change." Save, hide, and delete actions are what actually modify model behavior — reorganizing the diagram is just housekeeping.

Question 9

A technical key is required by relationships and DAX calculations, but report authors should not select it when creating visuals. Existing calculations and relationships must continue to work.

Which action best meets the requirement?

  1. Delete the key in Data view so that it is removed from the field list but retained by existing relationships.
  2. Remove the key in Power Query Editor and rely on Power BI to preserve dependent DAX expressions automatically.
  3. Hide the key by applying a report-level filter that excludes all of its values from every report page.
  4. In Model view, mark the key as hidden in report view while leaving it in the semantic model. (correct answer)
Explanation: When working with Power BI semantic models, you'll frequently encounter fields that serve a technical purpose — like surrogate keys used in relationships or DAX calculations — but that would confuse report authors if they appeared in the field list. The key skill here is knowing how to control visibility without breaking the underlying model. The best solution is D: in Model view, right-click the column and mark it as hidden in report view. This removes it from the field list that report authors see, but the column remains fully present in the semantic model. Relationships built on it continue to function, and DAX measures that reference it still evaluate correctly. You get clean usability without breaking anything. A is dangerously wrong. Deleting a column in Data view actually removes it from the model entirely — Power BI does not quietly preserve it for relationships. This would break any relationship or DAX expression depending on that key, violating the requirement to keep existing logic intact. B is equally destructive. Removing a column in Power Query Editor strips it during data refresh, and Power BI absolutely does not automatically reconstruct dependent DAX expressions. You'd lose the column permanently after the next refresh. C misunderstands how report-level filters work. A report-level filter excludes values from visuals on that report, but the field still appears in the field list. Authors can still select it, and it only affects one report — not a model-wide solution. Study tip: On Power BI exam questions, whenever you see the phrase "should not be visible to report authors but must remain functional," think hide in Model view — it's the non-destructive visibility toggle designed exactly for this scenario.

Question 10

You create a measure that returns different results for each product category because it depends on filter context. You need to compare the category results and the grand total to validate the measure.

Which approach should you use?

  1. Use Data view and read the measure as a stored value beside every row of the product table.
  2. Use Model view and read the measure result from the relationship line connected to the product table.
  3. Use Report view and place category and the measure in a matrix or another suitable visual. (correct answer)
  4. Use Power Query Editor and add the measure to the preview after the final transformation step.
Explanation: When working with DAX measures in Power BI, remember that measures don't store values — they calculate dynamically based on filter context. That means you can only observe a measure's results when it's evaluated inside a visual that applies filters, like category slicers or row groupings. This is exactly why C is correct. Placing your measure alongside a category field in a matrix visual in Report view forces DAX to evaluate the measure once per category (each row becomes a filter context), and the matrix automatically includes a grand total row, which evaluates the measure with no category filter applied. This gives you the side-by-side comparison you need to validate that both the per-category and total calculations behave as expected. A is wrong because Data view shows the underlying data table with stored column values — measures don't appear there at all. You simply cannot read a measure's output row-by-row in Data view because measures have no fixed stored value. B is wrong because Model view displays tables, columns, and relationships visually. It shows the structure of your data model, not calculated results. No measure output is ever rendered on a relationship line. D is wrong because Power Query Editor operates before the data is loaded into the model — it handles transformations on raw data. DAX measures don't exist in Power Query, so there's no way to "add a measure" to a query step. Study tip: On Power BI exam questions about validating measures, always think Report view first. If the question involves filter context or totals, a matrix visual is almost always the right tool.