Microsoft Power BI Quiz: Calculation Types
20 questions · exam conditions
0:00
Calculation TypesQuestion 1 of 20

Which DAX object reacts to slicers without expanding model storage?

Column, stored at refresh
Table, stored at refresh
Measure, evaluated at query
All DAX objects run at query
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Calculation Types

Practice Calculation Types 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 Calculation Types, 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

Which DAX object reacts to slicers without expanding model storage?

  1. Column, stored at refresh
  2. Table, stored at refresh
  3. Measure, evaluated at query (correct answer)
  4. All DAX objects run at query
Explanation: Measures are computed at query time, so they respond to slicer filters without saving any extra values to the model. A column stored at refresh is fixed when data loads, so it can't react to a slicer change without rebuilding the model. That's why the measure is the DAX object that reacts dynamically.

Question 2

Which object is evaluated per row at refresh and increases model size?

  1. Measure, evaluated per query
  2. Calculated column, row-by-row (correct answer)
  3. Calculated table, at refresh
  4. Measure, row context per query
Explanation: Calculated columns are computed row by row during data refresh and are stored in the model, so they increase model size. Measures, by contrast, are evaluated at query time in filter context and are not stored, so they add no size. Row context comes from calculated columns and from iterator functions such as SUMX and FILTER, not from measures. The tempting wrong answer is a measure evaluated per query, but a measure never persists values.

Question 3

A user changes a slicer. What happens to an existing calculated table?

  1. It updates immediately
  2. It recalculates per query
  3. It recalculates on demand
  4. It remains unchanged now (correct answer)
Explanation: A calculated table is built when the data model refreshes, not when a slicer changes. Slicers only filter visuals and measures, so the table's stored values stay the same until a refresh. The tempting error is thinking it recalculates per query, but calculated tables aren't dynamic query-time objects.

Question 4

A DAX expression must return a stored table that can be related. Which object should you use?

  1. A stored calculated table (correct answer)
  2. A stored calculated column
  3. A table-returning measure
  4. A one-to-many relationship
Explanation: A calculated table is evaluated at refresh, stored in the model, and can participate in relationships, so it is the object you need. A table-returning measure is tempting because it returns a table, but it returns a virtual table only in memory, and virtual tables cannot be related or stored. A calculated column returns a column, not a table, and a relationship is not a DAX expression.

Question 5

Which statement about DAX objects is false?

  1. Calculated columns: row-by-row
  2. Measures use filter context
  3. Calculated tables run at query (correct answer)
  4. Columns increase model size
Explanation: Calculated tables are built when the data model is refreshed, not when you run a query, so the claim that they run at query is false. Calculated columns are evaluated row by row at load time and stored, which increases model size. Measures are evaluated on demand using filter context. The tempting trap is A, but column behavior at load is true.

Question 6

A slicer needs a standalone list of values not tied to existing data. Which DAX object?

  1. A calculated column
  2. An explicit measure
  3. A calculated table (correct answer)
  4. An aggregation table
Explanation: A calculated table creates a standalone list in DAX, like VALUES or a generated sequence, without needing existing data. A calculated column is tempting, but it must belong to a specific table and isn't independent, so it can't serve as a standalone slicer list.

Question 7

Which pair describes the default evaluation context of calculated columns and measures?

  1. Column: row; Measure: filter (correct answer)
  2. Column: filter; Measure: row
  3. Column: query; Measure: load
  4. Column: load; Measure: filter
Explanation: Calculated columns evaluate once per table row, so they use row context. Measures evaluate based on current filters and slicers, so they use filter context. The tempting mistake is reversing them: row context for measures and filter for columns, but measures see filtered data, columns see each row.

Question 8

A value must be a stored field on an existing customer table, not recomputed by slicers. Which object?

  1. A calculated column (correct answer)
  2. An explicit measure
  3. A calculated table
  4. An aggregation table
Explanation: A calculated column is computed once and stored as a field in the table, so slicers change filtering but not the stored value. An explicit measure is the tempting wrong choice because measures are evaluated dynamically in the current filter context, so they are recomputed as slicers change.

Question 9

A report ratio must use the current filter context for both parts. Which object should you create?

  1. A persisted column
  2. An explicit DAX measure (correct answer)
  3. A calculated table
  4. An aggregation table
Explanation: A ratio that must respect the current filter context has to be calculated at query time, so you create an explicit DAX measure. Measures reevaluate whenever filters change, keeping both parts aligned with the selected context. A persisted column is the tempting wrong choice, but it is static and row-level, so it can't respond to filters.

Question 10

Which evaluation timing applies to calculated columns and calculated tables?

  1. Columns query; tables refresh
  2. Columns and tables query
  3. Columns refresh; tables query
  4. Columns and tables refresh (correct answer)
Explanation: Both calculated columns and calculated tables are evaluated during data refresh and then stored in the model, so they do not recompute each time a visual queries. The tempting mistake is to think calculated columns behave like measures and evaluate at query time, but measures are the ones that query; columns and tables refresh.

Question 11

A Power BI model contains a Product table with UnitPrice and UnitCost columns. Users must place a field named Margin Band on slicers and chart axes. Each product must be assigned to Low, Medium, or High based only on that product's price and cost. The assignment can be updated during dataset refresh.

Which calculation type should you use for Margin Band?

  1. A measure that returns the band from the current product filter context
  2. A calculated column that stores the band for each product row (correct answer)
  3. A calculated table that contains one row for each possible band
  4. A measure that concatenates the selected products' calculated bands
Explanation: When a question asks about placing a field on slicers and chart axes, that's your signal to think about row context versus filter context — a core DAX concept. Fields that appear on axes and slicers must exist as discrete, enumerable values in the data model, not as dynamic calculations that return a single value in response to a filter. A calculated column is the right tool here (answer B). It evaluates row by row during dataset refresh, using each product's UnitPrice and UnitCost to assign "Low," "Medium," or "High" and stores that result permanently in the table. Because it lives as a real column, Power BI can display it on slicers, group by it on axes, and filter against it — exactly what the requirement demands. Crucially, the requirement says the assignment updates during refresh, which calculated columns support naturally. Answer A fails because a measure has no row context of its own — it responds to whatever filter context is applied, making it impossible to use directly on a slicer or axis. It would return a single band label, not a list of bands to select from. Answer D has the same fundamental problem: concatenating selected products' bands is a measure behavior, still incompatible with slicers and axes, and it describes aggregation rather than classification. Answer C — a calculated table with one row per band — might seem clever, but it's disconnected from the Product table and individual products. It could support a slicer, but it wouldn't automatically assign each product to a band without additional relationship modeling. Study tip: When a question mentions slicers or axes, ask yourself: "Does this need to live in the table as a column?" If yes, think calculated column, not measure.

Question 12

A report displays Revenue, Profit, and Profit Margin by year, region, and product category. Profit Margin must be recalculated after every slicer selection and must represent total profit divided by total revenue in the resulting filter context.

Which implementation best meets the requirement?

  1. Create a calculated column that divides each row's profit by its revenue
  2. Create a calculated table that summarizes profit and revenue by category
  3. Create a measure that divides the Profit measure by the Revenue measure (correct answer)
  4. Create a calculated column that divides category profit by category revenue
Explanation: Whenever you see a Power BI question involving values that must respond dynamically to filters or slicers, your instinct should immediately jump to measures, not calculated columns or calculated tables. The core distinction is this: calculated columns are evaluated row-by-row at data refresh time and are blind to slicer context, while measures are evaluated at query time within whatever filter context the user has applied. Profit Margin here must represent Total ProfitTotal Revenue\frac{\text{Total Profit}}{\text{Total Revenue}} after every slicer selection — that phrase is your signal. Option C, creating a measure that divides the Profit measure by the Revenue measure, does exactly this. Each time a slicer changes, DAX re-evaluates both measures within the new filter context and returns the correctly aggregated ratio. Option A fails because a calculated column divides profit by revenue at the individual row level during data load. When visuals aggregate those column values, you get an average of ratios — not the ratio of totals — which is mathematically incorrect for margin analysis. Option D makes the same mistake but at a category grain; the aggregation problem persists regardless of the granularity at which the column is computed. Option B introduces an unnecessary calculated table. Summarizing into a static table locks data into a snapshot and doesn't respond to slicer-driven filter context the way a measure does. A reliable study tip: on Power BI exam questions, any requirement containing phrases like "recalculated after selection," "responds to filters," or "represents totals in context" is almost always pointing you toward a measure. Calculated columns answer "what is true per row?"; measures answer "what is true right now, given what the user selected?"

Question 13

A model has a Product table containing a calculated column that ranks every product by lifetime sales. The rank is shown in a report filtered to a single region. Users report that the rank still reflects company-wide lifetime sales rather than sales within the selected region.

What should you do to produce a rank that changes with the region filter?

  1. Replace the rank column with a measure that ranks products in the current filter context (correct answer)
  2. Replace the rank column with a calculated table that stores one row per product and region
  3. Keep the rank column and configure its default summarization as Do not summarize
  4. Keep the rank column and sort it by a region identifier calculated column
Explanation: Whenever you see a question about calculated columns versus measures in Power BI, the central issue is when the calculation is evaluated. Calculated columns are computed once during data refresh and stored in the model — they have no awareness of report filters or slicers at query time. Measures, by contrast, are evaluated dynamically inside whatever filter context exists when the visual renders. That distinction is exactly what this scenario is testing. The rank column was built as a calculated column, so it locked in company-wide sales data at refresh time. No matter what region a user selects, the stored rank values never change. The fix is answer A: replace the column with a measure using something like RANKX(ALLSELECTED(Product), [Lifetime Sales]), which recalculates the rank using only the products and sales visible in the current filter context — including any active region filter. B is wrong because a calculated table is still static, computed at refresh time just like a calculated column. Storing one row per product and region doesn't make the rank dynamic; it just pre-computes every combination without responding to the active filter. C is a red herring — changing the default summarization to "Do not summarize" controls how Power BI aggregates the column in visuals, but it does nothing to make the underlying values filter-aware. D is also wrong; sorting by a region identifier only changes display order, not the rank values themselves, which remain frozen at company-wide figures. Your study tip: on the Power BI exam, any time you need a value that responds to filters, think measure. Calculated columns are for row-level attributes that don't depend on user selections.

Question 14

An imported Sales table contains 200 million rows. A developer proposes adding a calculated column for Line Amount by multiplying Quantity by Unit Price. The column is needed only to display total line amount under the current report filters; users will not group, sort, filter, or establish relationships by the individual values.

Which design is most appropriate?

  1. Create the calculated column because row-level arithmetic must always be stored before aggregation
  2. Create an iterator measure that calculates and sums line amounts in the current context (correct answer)
  3. Create a calculated table containing each sales row and its computed line amount
  4. Create a scalar measure that multiplies total quantity by average unit price
Explanation: When a question describes a large imported table where values are needed only for aggregated display — not for filtering, sorting, grouping, or relationships — your instinct should shift away from stored columns and toward dynamic calculation. The core tradeoff here is storage and refresh cost vs. on-the-fly computation. An iterator measure using SUMX is the right tool for this scenario. Rather than storing 200 million pre-computed values, SUMX walks through the rows in the current filter context, multiplies Quantity by Unit Price for each row, and returns the sum — all at query time. The result is the same total the user needs, with zero added model size or refresh overhead. This is answer B, and it's the most appropriate design. Answer A is a common misconception — row-level arithmetic does not need to be persisted as a calculated column before aggregation. That's exactly what iterator functions exist to avoid. Storing 200 million additional values bloats the model and slows refresh significantly. Answer C compounds the problem further. A calculated table replicating every sales row with a computed column doubles your storage footprint for no analytical benefit — an even worse choice than a calculated column alone. Answer D sounds efficient but is mathematically incorrect. Multiplying total quantity by average unit price does not equal the sum of individual line amounts unless all unit prices are identical, which is almost never true in real sales data. Study tip: On Power BI exam questions, if the scenario says "users won't filter or group by this value," that's a signal that a measure — especially an iterator like SUMX — will almost always outperform a calculated column.

Question 15

A developer creates a calculated table that summarizes sales by region and product category. The table is refreshed nightly. A report visual uses this table and must display only sales from dates selected in a slicer connected to the original Sales table. The summarized rows were not created at the Date grain.

Which statement best explains why the calculated table cannot satisfy the requirement by recalculating its rows after each slicer selection?

  1. Calculated tables ignore slicer filters unless the slicer column originates from the same table rather than from a related source table
  2. Calculated tables can respond to date slicers only when each date value is also stored as a separate calculated column within the same table
  3. Calculated tables are re-evaluated per visual query but cannot receive filters propagated through model relationships from other tables
  4. Calculated tables are materialized at refresh and do not re-execute their DAX expression in response to report filter context, so date-grain detail absent from the stored rows cannot be recovered at query time (correct answer)
Explanation: When working with calculated tables in Power BI, the critical distinction to understand is the difference between materialized objects and dynamic expressions. Calculated tables are computed once during model refresh and stored as static data in the model — their DAX is not re-run when a user interacts with a report. This is exactly why D is correct. Because the calculated table was summarized at a regional/category grain — not a date grain — individual date information simply does not exist in its stored rows. Even if Power BI wanted to filter it by date, there's nothing to filter on. More fundamentally, the DAX expression that built the table won't re-execute just because a slicer changed; the stored rows are all you get until the next refresh. Option A is wrong because it invents a rule about slicer column origin that doesn't exist — slicers from related tables absolutely can filter calculated tables through model relationships, provided the filtering column exists in the table. Option B is similarly fabricated; there is no requirement to store date values as separate calculated columns to enable date filtering. Option C gets closest to reality but is misleading: calculated tables can receive filters propagated through relationships at query time — they behave like any imported table in that sense. The real issue isn't filter propagation; it's the missing date-grain detail in the stored rows, which C fails to address. Your study tip: whenever you see a question involving calculated tables and dynamic filtering, ask yourself "was this data frozen at refresh?" If yes, any detail not captured in those stored rows is permanently unavailable at query time — no slicer can recover it.

Question 16

A model imports separate Customer and Product tables. You must create a persistent table containing every allowed customer-product pairing from those tables. The new object must have named columns, participate in model relationships, and be available to report authors after each refresh.

Which calculation type should you use?

  1. A measure that returns the number of allowed pairings in the current context
  2. A calculated column added to Customer that stores one selected product identifier
  3. A calculated table that materializes the allowed customer-product pairings (correct answer)
  4. A measure that returns a delimited list of customer and product identifiers
Explanation: When a question asks you to create a persistent, reusable table object with named columns that survives a refresh and can participate in relationships, you're being tested on the distinction between calculated tables, calculated columns, and measures in Power BI's data model. A calculated table is exactly the right tool here. Written in DAX using functions like CROSSJOIN or GENERATE, it materializes at refresh time, stores its rows in the model, exposes named columns, and can be the source or target of relationships — satisfying every requirement in the passage. Answer C is correct. A and D both describe measures, which are fundamentally the wrong shape for this task. Measures compute a scalar value (or, in D's case, a string) on demand within a filter context — they don't produce rows, can't hold columns, and cannot participate in relationships. No matter how clever the DAX, a measure cannot become a persistent table. B is tempting because calculated columns are persistent and do live in the model, but adding a column to the Customer table only gives you one product identifier per customer row. You cannot represent the full Cartesian (or filtered) set of pairings this way — you'd need multiple rows per customer, which is exactly what a separate calculated table provides. Study tip: On Power BI exam questions, watch for the keyword cluster "persistent + rows + relationships." That combination always points to a calculated table, never a measure. Measures answer "how many/much?" while calculated tables answer "what are all the combinations?"

Question 17

You are building a what-if analysis. A slicer must present discount rates from 0 through 20 percent in 1-percent increments. A projected-revenue calculation must use the selected rate and respond to the report's existing customer and date filters.

Which combination of calculation types should you use?

  1. A calculated table for the discount values and a measure for projected revenue (correct answer)
  2. A measure for the discount values and a calculated column for projected revenue
  3. A calculated column for the discount values and a calculated table for projected revenue
  4. A measure for the discount values and a calculated table for projected revenue
Explanation: When designing what-if analyses in Power BI, the key is matching each component to the calculation type that fits its purpose: static list generation versus dynamic, filter-aware computation. For a slicer presenting discrete values (0% through 20% in 1% steps), you need a physical table that Power BI can bind a slicer visual to. A calculated table is perfect here — it materializes rows at refresh time using a DAX expression like GENERATESERIES(0, 0.20, 0.01). This gives the slicer something concrete to display. A measure, by contrast, returns a single scalar value and cannot populate a slicer's list of selectable options. For projected revenue, you need a calculation that reads the user's selected discount rate and responds to existing customer and date filters on the report canvas. A measure is evaluated dynamically within the current filter context, making it the right tool. A calculated column is computed row-by-row at refresh time with no awareness of slicer selections or report filters — it cannot "see" what the user has chosen. This confirms A as the correct combination: a calculated table for the discount values and a measure for projected revenue. B fails because a measure cannot drive a slicer's values. C fails on both counts — a calculated column can't respond to slicer selections, and a calculated table can't compute context-aware revenue. D fails for the same reason as B (a measure can't populate a slicer) and because a calculated table for revenue would be static. Study tip: On Power BI exam questions, slicers always need a table or column as their source — if an answer uses a measure to feed a slicer, eliminate it immediately.

Question 18

A Sales table contains Quantity and UnitPrice. Report authors require a Line Value field for creating numeric bins and placing the bins on chart axes. They also require Total Line Value to aggregate correctly under all report filters.

Which design should you implement?

  1. Create both Line Value and Total Line Value as filter-responsive measures
  2. Create Line Value as a measure and Total Line Value as a calculated column
  3. Create both Line Value and Total Line Value as separate calculated tables
  4. Create Line Value as a calculated column and Total Line Value as a measure (correct answer)
Explanation: When designing fields in Power BI, the key question to ask is: does this field need to exist at the row level, or does it need to respond to report filters? That distinction drives the choice between calculated columns and measures. Line Value — calculated as Quantity × UnitPrice — must be a calculated column because report authors need to create numeric bins from it and place those bins on chart axes. Binning requires discrete, pre-computed row-level values that exist in the data model before any filter context is applied. A measure can't be binned or used directly on an axis because it only produces a single aggregated scalar value at query time. Total Line Value, on the other hand, must be a measure so it aggregates correctly under all report filters. Measures evaluate dynamically based on the current filter context, which is exactly what "aggregate correctly" means in a reporting scenario. That combination makes D the correct design. A fails because making Line Value a measure prevents it from being used for binning or placed on an axis — measures don't produce the row-level granularity binning requires. B reverses the roles: a measure for Line Value can't be binned, and a calculated column for Total Line Value won't respond to report filters — it would always show the same static row-level value regardless of slicers or filters. C is nonsensical here; calculated tables are for generating new table structures, not for creating row-level fields or dynamic aggregations. Study tip: On Power BI exam questions, "bins," "axis placement," or "row-level" = calculated column; "filter-responsive" or "aggregates correctly" = measure.

Question 19

An Import model has a CustomerBirthDate column. A developer creates a calculated column named CurrentAge using the current date. The semantic model refreshes weekly, but executives expect the displayed age to change on the correct birthday even if no refresh occurs. CurrentAge is displayed only as a value and is not used for grouping or relationships.

Which change best meets the requirement?

  1. Replace CurrentAge with a measure that computes age when the report is queried (correct answer)
  2. Keep CurrentAge as a calculated column and change its default summarization
  3. Move CurrentAge into a calculated table that contains customer birth dates
  4. Keep CurrentAge as a calculated column and hide it from report view
Explanation: When working with Power BI, the key distinction to understand here is the difference between calculated columns and measures — specifically when each one evaluates its formula. Calculated columns compute their values at model refresh time and store the result statically in the model. Measures, by contrast, compute their values at query time, meaning every time a report visual is rendered. This distinction is exactly what the question is testing. The requirement is that age updates on the customer's actual birthday, independent of the weekly refresh schedule. A calculated column named CurrentAge will simply hold whatever age was correct at the last refresh — it won't change until the model refreshes again. Replacing it with a measure (answer A) solves this because the measure recalculates using TODAY() every time the report is opened or the visual is queried, so the age reflects the current date dynamically. Answer B is wrong because changing the default summarization (sum, average, etc.) has no effect on when the value is evaluated — it's still a static column computed at refresh. Answer C is a red herring: moving the column into a calculated table doesn't change the refresh-time evaluation problem; calculated tables are also computed at refresh. Answer D is similarly flawed — hiding a calculated column from report view doesn't change how or when it calculates; it just controls visibility. Study tip: On Power BI exam questions, whenever you see a requirement involving "real-time" or "between-refresh" accuracy, that's your signal to reach for a measure, not a calculated column. Measures are dynamic; calculated columns are static snapshots.

Question 20

Which statement correctly compares the evaluation timing of calculated columns, calculated tables, and measures in an Import model?

  1. Calculated columns and tables are evaluated during refresh, while measures are evaluated when queried (correct answer)
  2. Calculated columns are evaluated when queried, while tables and measures are evaluated during refresh
  3. Calculated tables are evaluated when queried, while columns and measures are evaluated during refresh
  4. Calculated columns, calculated tables, and measures are all evaluated only when a visual is queried
Explanation: When working with Power BI Import models, a key concept to understand is when different object types are computed — this determines performance behavior, storage, and design decisions. Calculated columns and calculated tables are both materialized objects. This means their values are computed and stored in the model during data refresh. When you trigger a refresh, Power BI evaluates all DAX expressions for calculated columns (row by row in their respective tables) and builds entire calculated tables from scratch. The results are physically stored in the VertiPaq in-memory engine, so no recalculation happens at query time. Measures, by contrast, are dynamic. They contain no pre-stored results — instead, their DAX expressions are evaluated at query time, in the current filter context provided by a visual, slicer, or report interaction. This is what makes measures flexible and context-aware. This confirms that A is correct: calculated columns and tables are evaluated during refresh, while measures are evaluated when queried. B incorrectly claims calculated columns are query-time objects — they are not; they're stored during refresh. C inverts the behavior of calculated tables, suggesting they're query-time objects, which contradicts how materialization works in Import mode. D wrongly groups all three together as query-only objects, ignoring the fundamental distinction between stored (columns/tables) and dynamic (measures) calculations. A helpful memory trick: think of columns and tables as "baked in" during refresh, and measures as "cooked fresh" at query time. This distinction also explains why large calculated columns can slow down refreshes, while complex measures can slow down report visuals.