Microsoft Power BI Quiz: Measures Vs Columns
10 questions · exam conditions
0:00
Measures Vs ColumnsQuestion 1 of 10

Two imported tables must be related by a business key formed by concatenating CountryCode and AccountNumber. Neither source can be modified, and the combined key does not already exist. The key will be used on the one side and the many side of a relationship.

What should you create in each table?

A measure that concatenates CountryCode and AccountNumber whenever a visual evaluates the relationship.
A calculated column that concatenates CountryCode and AccountNumber and is then used by the relationship.
A measure that returns the matching row count after filtering both tables by the two source columns.
A calculated column that returns the account balance after filtering by CountryCode and AccountNumber.
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Measures Vs Columns

Practice Measures Vs Columns 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 Measures Vs Columns, 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

Two imported tables must be related by a business key formed by concatenating CountryCode and AccountNumber. Neither source can be modified, and the combined key does not already exist. The key will be used on the one side and the many side of a relationship.

What should you create in each table?

  1. A measure that concatenates CountryCode and AccountNumber whenever a visual evaluates the relationship.
  2. A calculated column that concatenates CountryCode and AccountNumber and is then used by the relationship. (correct answer)
  3. A measure that returns the matching row count after filtering both tables by the two source columns.
  4. A calculated column that returns the account balance after filtering by CountryCode and AccountNumber.
Explanation: When you need to create a relationship in Power BI between two imported tables using a composite business key, the core question is: what object can physically exist as a column that a relationship can be built on? Relationships in Power BI require actual columns on both sides — they cannot be built on measures. This is why B is correct. A calculated column evaluates row by row during data refresh and stores the concatenated result (e.g., "US" & "12345") as a persistent column in the table. You can then define a one-to-many relationship using that column on both tables, exactly as you would with any native column. Since neither source can be modified, adding a calculated column inside Power BI is the appropriate workaround. A is wrong because measures are evaluated in filter context at query time and don't produce a stored column value. Power BI relationships must reference columns — you literally cannot select a measure in the "Manage Relationships" dialog. C describes a measure that counts matching rows, which is not a relationship at all — it's a custom aggregation that doesn't establish the data model connection the scenario requires. D describes a calculated column, but one that returns an account balance — that's a value aggregation, not a key. A relationship key column must uniquely identify rows (on the one side) and match values (on the many side), not return financial figures. As a study tip: on Power BI exam questions involving relationships, always ask yourself "does this object produce a stored, addressable column?" If the answer is no, it cannot support a relationship.

Question 2

An imported Sales table contains 200 million rows with Quantity, UnitPrice, and DiscountRate. Reports need total net revenue under arbitrary filters. No other requirement needs the net revenue of an individual row, and reducing model size is a priority.

Which implementation is most appropriate?

  1. Create a calculated column for row net revenue and sum it with an explicit measure in every visual.
  2. Create a measure using SUMX over Sales to calculate and aggregate net revenue in the current context. (correct answer)
  3. Create a calculated column for row net revenue and rely on its default implicit average aggregation.
  4. Create three calculated columns for quantity, price, and discount, then multiply their separate totals in a measure.
Explanation: When choosing between calculated columns and measures in Power BI, always ask two questions: Where does the calculation happen? and What does it cost the model? Calculated columns are computed at refresh time and stored in memory for every row — a serious concern with 200 million rows. Measures are computed on-the-fly using only the data relevant to the current filter context. The right approach here is B: a measure using SUMX. It iterates over the Sales table row-by-row within the current filter context, computing Quantity * UnitPrice * (1 - DiscountRate) per row, then aggregates the result — no storage overhead, no permanent column, and it responds correctly to any slicer or filter combination. This is exactly what SUMX is designed for: row-level calculations that are only needed as aggregates. A is tempting but wasteful. Storing a calculated net revenue column across 200 million rows consumes significant memory at the VertiPaq compression layer, directly contradicting the requirement to minimize model size. A measure accomplishes the same aggregation without that cost. C compounds A's memory problem with a logic error. Default implicit aggregation on a calculated column would average net revenue rather than sum it — producing completely wrong totals under most filter contexts. D misunderstands how aggregation works. Summing Quantity, UnitPrice, and DiscountRate separately and then multiplying their totals is mathematically incorrect: ∑(Q×P)≠∑Q×∑P\sum(Q \times P) \neq \sum Q \times \sum P. This produces wildly inaccurate results. Study tip: On the Power BI exam, if a question involves row-level math that only matters as an aggregate, SUMX in a measure is almost always the answer over a calculated column.

Question 3

A matrix displays sales by product. A value named Product Share must divide each product's sales by sales for all products while preserving the current date, customer, and region filters. Users can change all of these filters interactively.

Which approach should you use for Product Share?

  1. Create a calculated column that divides each sales row by the total sales stored during the most recent refresh.
  2. Create a measure that divides current sales by sales recalculated after removing only the product filter. (correct answer)
  3. Create a measure that divides current sales by sales recalculated after removing every report filter.
  4. Create a calculated column in Product that divides each product's refresh-time sales by all-product sales.
Explanation: When a calculation needs to respect some filters but ignore others, you're working in the territory of DAX filter context manipulation — specifically the CALCULATE function combined with REMOVEFILTERS (or ALL) on targeted tables or columns. The key question to ask is: which filters should the denominator ignore, and which should it keep? For Product Share, you want the denominator to represent "total sales across all products, but still filtered by the current date, customer, and region." That means you only strip the product filter from the denominator — nothing else. This is exactly what option B describes: a measure that calls CALCULATE([Sales], REMOVEFILTERS('Product')) in the denominator. Because it's a measure, it recalculates dynamically every time a user changes a slicer or filter, keeping the result accurate and interactive. Option A fails because a calculated column is computed at refresh time and stored as a static value. It cannot respond to interactive report filters — the denominator will never update when a user slices by date or region. Option D has the same fundamental flaw for the same reason: calculated columns live in the data model and are blind to report-level filter context. Option C is conceptually close but removes all filters from the denominator, which would ignore date, customer, and region filters too — giving you a grand total rather than the context-aware total you need. The study tip here is to remember the calculated column vs. measure distinction: columns are static at refresh; measures are dynamic at query time. Whenever a question requires interactive filter responsiveness, a measure is always the right vehicle.

Question 4

A Date table contains a Month Name column with values such as January, February, and March. Report visuals must display these names in calendar order rather than alphabetical order. The table does not contain a numeric month field.

What should you do?

  1. Create a measure that returns the month number, and select that measure in the Sort by column property.
  2. Create a measure that prefixes Month Name with a month number whenever the visual is evaluated.
  3. Create a calculated column that returns the month number, and sort Month Name by that column. (correct answer)
  4. Create a calculated column containing total monthly sales, and sort Month Name by the sales column.
Explanation: When you need to control the sort order of a text column in Power BI, think about the Sort by Column feature. This lets you tell Power BI: "When sorting this column, use the values in that column instead." The catch is that the sorting column must be a real column — not a measure — and it must have a one-to-one or many-to-one relationship with the column being sorted. That's exactly why C is correct. By creating a calculated column that returns a numeric month number (1 for January, 2 for February, etc.), you produce a persistent column stored in the data model. You can then open the Month Name column's properties and set Sort by Column to that numeric column. Power BI will display "January, February, March..." in proper calendar order across all visuals automatically. A is tempting but fundamentally wrong: the Sort by Column property does not accept measures — only columns. Measures are calculated on the fly per visual context and don't exist as stable column values in the model, so Power BI won't allow this. B is impractical and fragile. Prefixing month names (e.g., "01 January") changes the display text itself, which pollutes your labels and would require stripping prefixes elsewhere. It's a workaround, not a proper solution. D sorts Month Name by total sales figures, which would produce an order based on sales volume — completely unrelated to calendar sequence and useless for the stated requirement. The key study tip: whenever a question involves sorting a text column, your instinct should be calculated column + Sort by Column. Measures cannot be used in Sort by Column — this is a frequent exam trap.

Question 5

An InventorySnapshot table stores one row per product and date with the quantity on hand at the end of that date. A report must show ending inventory for any selected month, quarter, or year. The result must be the inventory on the last date in the current period, not the sum of all daily snapshots.

Which implementation should you use?

  1. Create a calculated column containing quantity on hand and configure its default summarization as Sum.
  2. Create a measure that sums quantity on hand across every snapshot date in the current period.
  3. Create a calculated column that flags the model's latest snapshot date and sum only rows with that flag.
  4. Create a measure that evaluates quantity on hand for the last applicable date in the current filter context. (correct answer)
Explanation: When a data model stores daily snapshots rather than transactions, the key distinction is between aggregating values and selecting the right point-in-time value. Inventory on hand is a semi-additive measure — summing it across dates is meaningless. Instead, you need the value at the last date within whatever time period the user has selected. This is exactly what D delivers. A measure can inspect the current filter context (say, Q1 2024), find the maximum date within that context, and return the quantity on hand for that specific date using functions like LASTDATE or CALCULATE with MAX on the date column. As the user changes slicers — from month to quarter to year — the measure dynamically recalculates to always return the correct ending snapshot. A is wrong because a calculated column is computed at refresh time and assigned to individual rows, not to a user-selected period. Setting its summarization to Sum compounds the error by adding up every day's inventory, producing a wildly inflated number. B makes the same fundamental mistake — summing all snapshot values across a period gives you a meaningless total, not an ending balance. C is closer in spirit but hardcodes the flag to the model's latest date globally, so it can't adapt when a user filters to a past month or quarter; it will either return no data or always show the same single date regardless of period selection. As a study tip, whenever you see "semi-additive" patterns on the Power BI exam — inventory, balances, headcount — your instinct should immediately be measure + LASTDATE/LASTNONBLANK, never a simple sum.

Question 6

A report lists products and displays a sales rank. The rank must change when users select a year or region, and products excluded by those selections must not participate in the ranking. Product sales are stored in a related fact table.

Which solution should you implement?

  1. Create a calculated column in Product that ranks products by total sales when the model refreshes.
  2. Create a measure that ranks products by an unfiltered lifetime-sales total for every product in the model.
  3. Create a calculated column in Sales that ranks each transaction by its sales amount within the source row order.
  4. Create a measure that ranks products by current sales over the products retained by user selections. (correct answer)
Explanation: When a ranking must respond to user selections — changing as filters change and excluding filtered-out products — you're being tested on the difference between static, pre-calculated values and dynamic, context-aware measures in Power BI. The right tool here is a DAX measure using RANKX. A measure recalculates on every report interaction, so when a user picks a year or region, the filter context changes and the measure ranks only the products that survive those filters. Option D describes exactly this: a measure that evaluates rank over the products currently visible in the filter context, using the actual sales those products generated under the selected conditions. This is precisely what RANKX over a filtered table achieves. Option A fails because calculated columns are computed at model refresh time, before any user interaction exists. The rank is baked in at load and never responds to slicer selections — it's a snapshot, not a dynamic value. Option B is the opposite trap: it deliberately ignores filters by ranking against an unfiltered lifetime total. That means excluded products still participate in the ranking pool, and the rank won't shift when the user changes their selection — exactly what the requirement forbids. Option C is the most confused choice: ranking individual sales transactions by amount within source row order has nothing to do with ranking products by aggregated sales, and a calculated column in the fact table still can't respond to user filters. Study tip: On Power BI exam questions, whenever you see words like "changes when users select" or "excluded items must not participate," that's your signal that only a measure — never a calculated column — can solve the problem.

Question 7

A report includes a What-if parameter named Minimum Sales. A card must show the number of customers whose sales exceed the selected parameter value. The count must also respond to date, region, and product slicers.

Which design best meets the requirement?

  1. Create a calculated column in Customer that compares a stored lifetime-sales value with the parameter's default value.
  2. Create a calculated column in Sales that flags transactions whose amount exceeds the currently selected parameter value.
  3. Create a measure that iterates customers and counts those whose sales in the current context exceed the selected value. (correct answer)
  4. Create a measure that counts sales rows whose individual transaction amount exceeds the selected parameter value.
Explanation: When a question asks about counts that must respond to slicers and reference a dynamic parameter, you're being tested on the difference between calculated columns (static, row-level, evaluated at refresh) and measures (dynamic, context-aware, evaluated at query time). The right design here is C: a measure that iterates over customers and counts those whose total sales — within the current filter context — exceed the selected parameter value. Using CALCULATE or SUMX inside an iterator like COUNTX or SUMX with IF, the measure respects whatever filters the date, region, and product slicers apply before it runs. That's exactly the responsive behavior the requirement demands. A fails because a calculated column in the Customer table stores a single lifetime-sales figure computed at refresh time. It can't recalculate based on slicer selections, so it will never reflect filtered date or product subsets. B is a more tempting trap. A calculated column in Sales that flags individual transactions also runs at refresh, not at query time. Even if you tried to reference the What-if parameter inside a calculated column, it won't respond to filter context — calculated columns don't update when slicers change. D counts individual transaction rows rather than distinct customers. A single customer with three qualifying transactions would be counted three times, producing a transaction count instead of a customer count. That's the wrong grain. Study tip: On Power BI exam questions, any time you see "must respond to slicers" or "dynamic context," that's your signal that only a measure can solve the problem — calculated columns are evaluated once and stored.

Question 8

An AccountsReceivable table contains DueDate and PaidDate. Users need an Invoice Status slicer with the categories Open, Overdue, and Paid. Status may remain unchanged between scheduled refreshes, and overdue status should be evaluated as of the refresh date.

Which design best satisfies the requirement?

  1. Create a calculated column that assigns each invoice a status during refresh and use the column in the slicer. (correct answer)
  2. Create a measure that assigns a status in the current context and use the measure directly in the slicer.
  3. Create a measure that counts open, overdue, and paid invoices and configure that measure as the slicer category.
  4. Create a calculated column that stores days overdue, then use its default sum as the status slicer field.
Explanation: When a question asks how to build a slicer with discrete category labels in Power BI, you need to think carefully about where those categories live — in the data model as a column, or computed on the fly as a measure. A calculated column runs during the model refresh and stores its result row-by-row in the table. Because invoice status (Open, Overdue, Paid) is relative to the refresh date — and the question explicitly states that overdue status should be evaluated at refresh time — a calculated column using TODAY() or NOW() captures that snapshot correctly. The resulting column contains literal text values like "Open" or "Overdue" that Power BI can display directly as slicer items. This is why A is the correct answer: it stores a stable, filterable category per invoice that slicers are designed to consume. B is tempting but wrong. Measures cannot be placed directly in a slicer field well because they return scalar values in a filter context, not a list of category labels. Power BI slicers require a column of discrete values, not a measure. C compounds that misunderstanding — counting invoices by status is a useful reporting measure, but a count is not a category label. You cannot configure a count measure as a slicer's source of filter values. D stores a numeric "days overdue" value, which is not the same as a status label. Summing days overdue in a slicer would produce meaningless aggregated numbers, not the Open/Overdue/Paid categories users need. Study tip: On Power BI exam questions, if the requirement is a slicer with text categories, think column — not measure. Measures filter; columns categorize.

Question 9

A sales model contains one row per invoice line in the Sales table, including SalesAmount and CostAmount. A report must display gross margin percentage by product, region, and any combination of slicers. Finance defines gross margin percentage as total gross profit divided by total sales, not as the average of line-level percentages.

Which implementation should you use?

  1. Create a calculated column for each line's margin percentage, and configure visuals to average the column.
  2. Create a measure that divides the difference between summed sales and summed cost by summed sales. (correct answer)
  3. Create a calculated column for line-level gross profit, and configure visuals to average that column.
  4. Create a measure that uses AVERAGEX to average the margin percentage calculated for each invoice line.
Explanation: When a business metric is defined as a ratio of aggregated totals — not an average of individual-level ratios — your implementation must aggregate first, then divide. That distinction is the core of this question. Finance defines gross margin percentage as: Gross Margin %=∑SalesAmount−∑CostAmount∑SalesAmount\text{Gross Margin \%} = \frac{\sum \text{SalesAmount} - \sum \text{CostAmount}}{\sum \text{SalesAmount}} Option B implements exactly this as a DAX measure, ensuring that no matter how slicers filter the data — by product, region, or any combination — Power BI first sums both columns within the current filter context, then divides. The result is always mathematically correct and dynamically responsive to slicers. Option A fails on two levels: calculated columns compute row-by-row at refresh time and are blind to slicer context, and averaging those line-level percentages produces a simple average of ratios, which is mathematically different from a ratio of sums. A $1 line at 90% margin and a $1,000 line at 5% margin would yield a wildly misleading average. Option C makes the same fundamental mistake as A. Averaging line-level gross profit dollars (not percentages) is a different error — it would produce the average profit per line, not the margin percentage Finance requires. It also ignores the division step entirely. Option D uses AVERAGEX to average per-line margin percentages across rows, which is exactly the calculation Finance said not to use. AVERAGEX is powerful, but here it replicates the same weighted-average distortion as options A and C. Study tip: On Power BI exam questions, whenever a metric is defined as a "total divided by total," always reach for a measure with explicit SUM/SUM division — never an average of row-level values.

Question 10

A model has a Customer dimension related one-to-many to a Sales fact table. Users must place Customer Segment in a slicer. The segment is determined from each customer's lifetime sales: Platinum, Gold, or Standard. The segment only needs to change when the semantic model is refreshed.

What should you create in the Customer table?

  1. A calculated column that assigns a segment by evaluating lifetime sales for the current customer during refresh. (correct answer)
  2. A measure that assigns a segment by evaluating lifetime sales in the visual's current filter context.
  3. A measure that returns the selected segment and is configured as the field of the slicer.
  4. A calculated column in Sales that assigns every transaction the segment determined from that transaction's amount.
Explanation: When a question asks where to store a derived classification that's based on aggregated data but only needs to update at refresh time, you're being tested on the calculated column vs. measure distinction and where each type of computation belongs in a data model. A calculated column is evaluated row by row during model refresh and stored as a physical column in the table. This makes it ideal for the scenario here: each customer gets a segment label (Platinum, Gold, or Standard) computed once from their lifetime sales, and that label persists as a stable attribute you can drop directly into a slicer. Answer A is correct because a calculated column in the Customer table can use DAX like CALCULATE(SUM(Sales[Amount]), RELATEDTABLE(Sales)) to aggregate sales for each customer at refresh time, then assign a segment — exactly matching the requirement. Answer B describes a measure, which is recalculated dynamically in filter context rather than stored. Measures can't be used as slicer fields because they don't produce a fixed list of values per row — they return a single scalar in a given context. Answer C makes the same fundamental mistake: measures cannot serve as the field source for a slicer; slicers require a column with discrete values. Answer D places the segment on the Sales table at the transaction level, which would assign a segment per transaction amount rather than per customer's lifetime sales — this is the wrong granularity and the wrong table. A useful rule of thumb: if you need a stable, per-row attribute that can live in a slicer, filter, or row-level grouping, reach for a calculated column. Reserve measures for dynamic aggregations in visuals.