25 DAX Fundamentals questions with answers for power bi roles — 9 easy, 13 medium, 3 hard.
About DAX Fundamentals
DAX is the core skill tested in every Power BI interview. Learn measures versus calculated columns, row context, filter context and context transition, CALCULATE, iterators like SUMX, ALL and REMOVEFILTERS, FILTER, RELATED, DIVIDE, variables and counting functions, plus how to debug totals that do not add up and measures that repeat the same value.
Sheet progressStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
DAX, Data Analysis Expressions, is the formula language for Power BI, Analysis Services and Power Pivot. It is used to create measures, calculated columns, calculated tables and security rules. DAX looks like Excel formulas but works on tables and columns with filter context. Key functions include SUM, CALCULATE, FILTER, ALL, RELATED, time intelligence functions and iterators like SUMX.
02
What is the difference between a calculated column and a measure?
A calculated column is computed row by row at refresh and stored in the model, so it uses memory and can be used in slicers, filters and relationships, for example Profit = Sales[Amount] - Sales[Cost]. A measure is computed at query time in the current filter context and is not stored, for example Total Profit = SUM(Sales[Profit]). Prefer measures for aggregations and use columns only when you need to slice by the value.
SUM aggregates a single column, such as SUM(Sales[Amount]). SUMX is an iterator: it evaluates an expression for each row of a table and then sums the results, such as SUMX(Sales, Sales[Qty] * Sales[Price]). Use SUMX when you need row-level calculations before aggregating. Other iterators include AVERAGEX, MAXX, COUNTX and RANKX.
RELATED fetches a value from the one side of a relationship into a row context on the many side, such as RELATED('Product'[Category]) in a Sales calculated column. RELATEDTABLE goes the other way, returning the related rows from the many side for the current row, often wrapped in COUNTROWS to count a customer's orders. Both need an existing relationship and a row context.
05
Why should you use DIVIDE instead of the division operator?
DIVIDE(numerator, denominator, alternate) handles division by zero and blank denominators safely, returning blank or the alternate value instead of an error or infinity. It makes measures like margin percentage cleaner without IF checks. The division operator is slightly faster when you are certain the denominator is never zero, but DIVIDE is the safer default in reports.
06
What is the difference between COUNT, COUNTA, COUNTROWS and DISTINCTCOUNT?
COUNT counts non-blank values in a column, COUNTA counts non-blank values of any type, COUNTROWS counts rows in a table, and DISTINCTCOUNT counts unique values in a column. For example, COUNTROWS(Sales) gives order lines while DISTINCTCOUNT(Sales[CustomerID]) gives active customers. COUNTROWS is generally preferred for counting records because its intent is clearer.
07
Write basic measures for total sales, total cost and profit margin percentage.
Total Sales = SUM(Sales[Amount])
Total Cost = SUMX(Sales, Sales[Qty] * Sales[UnitCost])
Profit = [Total Sales] - [Total Cost]
Margin % = DIVIDE([Profit], [Total Sales])
Format Margin % as a percentage. Building measures on other measures keeps logic in one place and easy to change.
08
Write a measure for sales of a specific category and region.
Electronics North Sales =
CALCULATE(
[Total Sales],
'Product'[Category] = "Electronics",
'Store'[Region] = "North"
)
Multiple filter arguments are combined with AND. Wrap a filter with KEEPFILTERS if it should intersect with an existing slicer selection instead of replacing it.
09
How do you learn a difficult concept like filter context?
I learn by building tiny examples. For filter context I made a small model with five products and wrote measures with and without ALL, KEEPFILTERS and ALLSELECTED, checking each result in a table visual. I also read documentation and use DAX Studio to see queries. Explaining it to a teammate afterwards showed me which parts I had not fully understood.
Row context means DAX is evaluating one row at a time, which happens in calculated columns and iterators like SUMX, so you can refer to column values of the current row. Filter context is the set of filters applied to the model from slicers, visual rows, columns and CALCULATE. Measures are evaluated in filter context. Row context does not filter the model unless converted by context transition.
CALCULATE evaluates an expression in a modified filter context. Its filter arguments can add, replace or remove filters, for example CALCULATE([Total Sales], 'Product'[Category] = "Electronics") replaces any category filter with Electronics. It also performs context transition when used inside a row context, turning the current row into an equivalent filter. It is the most important function in DAX.
12
What is the difference between ALL, ALLEXCEPT and REMOVEFILTERS?
ALL returns all rows of a table or column ignoring filters, and as a CALCULATE argument it removes filters, useful for percent of total. REMOVEFILTERS does the same removal but only as a CALCULATE modifier and reads more clearly. ALLEXCEPT removes all filters from a table except the listed columns, such as keeping the Year filter while removing others. ALLSELECTED keeps filters from outside the visual, like slicers.
VAR defines a named value inside an expression and RETURN gives the final result. Variables make measures easier to read, avoid repeating the same calculation, which improves performance, and help debugging because you can return an intermediate variable. A variable is evaluated once in the context where it is defined, so its value does not change if later CALCULATE filters are applied.
14
A measure shows the same value on every row of a table visual. Why?
The measure is probably ignoring the filter context of the rows, for example using ALL on that column or table, or the row field comes from a table that is not related to the fact table, so its filter cannot reach the data. I would check relationships in model view, the direction of filtering, and any ALL or REMOVEFILTERS in the measure.
15
The total row of a table shows a different value than the sum of rows. Is this a bug?
Usually not. A measure's total is calculated in the total's own filter context, not by adding the visible rows. For non-additive measures like averages, distinct counts or ratios this differs from the row sum. If business wants the sum of rows, I write it explicitly with SUMX over the row values, for example SUMX(VALUES('Product'[Product]), [My Measure]).
16
Your calculated columns have made the model huge. What do you do?
I would move simple row-level logic into Power Query or the source SQL, where it compresses better and can fold, and replace aggregations stored as columns with measures. High-cardinality columns such as concatenated keys or precise timestamps should be removed or split. Then check model size with VertiPaq Analyzer in DAX Studio to confirm which columns used the most memory.
17
Write a measure for percentage of grand total sales.
Sales % of Total =
DIVIDE(
[Total Sales],
CALCULATE([Total Sales], REMOVEFILTERS('Product'))
)
This gives each product's share of total across all products. Use ALLSELECTED('Product') instead if the denominator should respect slicer selections on products.
18
Create a calculated column that categorises customers by their lifetime sales.
Customer Band =
VAR s = CALCULATE(SUM(Sales[Amount]))
RETURN
SWITCH(TRUE(),
s >= 500000, "Platinum",
s >= 100000, "Gold",
s > 0, "Silver",
"No Purchase")
This is a column on the Customer table; CALCULATE triggers context transition so each row gets its own customer's sales.
19
Write a measure that counts customers with sales above 10,000.
Big Customers =
COUNTROWS(
FILTER(
VALUES(Customer[CustomerID]),
[Total Sales] > 10000
)
)
Iterating VALUES of the customer key keeps the loop small and respects current filters such as year or region.
20
Tell me about a time you found a wrong number in a published report.
Situation: a regional head noticed our margin report did not match finance. Task: find and fix it quickly. Action: I compared numbers at product level, found returns were double-subtracted because a measure used both a net amount column and a returns table. I fixed the measure, added a reconciliation page against finance totals and informed users. Result: numbers matched to the rupee and the reconciliation check became standard.
21
What is the difference between SELECTEDVALUE and VALUES?
SELECTEDVALUE(column, alternate) returns the single value of a column when exactly one is visible in the filter context, otherwise the alternate or blank. VALUES(column) returns a table of distinct visible values, including blank for unmatched rows, and can be used in iterators or as a filter. Use SELECTEDVALUE for titles and parameters, and VALUES when you need to loop over the visible items.
22
Your measure returns an error that a table of multiple values was supplied where a single value was expected. How do you fix it?
This happens when an expression like VALUES or a column reference returns several rows where a scalar is needed, for example in IF or comparison. I would use SELECTEDVALUE with a fallback, wrap the column in an aggregation like MAX or SUM, or use HASONEVALUE to check first. If iteration is needed, use SUMX or another iterator over VALUES instead.
Context transition happens when CALCULATE, or a measure reference which implicitly wraps CALCULATE, is evaluated inside a row context. The values of the current row are converted into filters on the model. For example, in a calculated column on Customer, [Total Sales] returns that customer's sales because the row becomes a filter. It is powerful but can be slow over large tables and surprising with duplicate rows.
24
What is the difference between FILTER and a simple boolean filter in CALCULATE?
A boolean filter like 'Product'[Color] = "Red" is shorthand for a filter over that column's values and replaces existing filters on that column. FILTER(Table, condition) iterates a table and returns rows matching the condition; it can use measures and multiple columns but is slower on large tables. Prefer column filters where possible and use FILTER on small tables or with KEEPFILTERS when needed.
25
A colleague's measure uses FILTER(Sales, ...) on a 50-million-row table and is slow. How would you rewrite it?
I would replace FILTER over the whole fact table with column filters in CALCULATE, such as CALCULATE([Sales], Sales[Channel] = "Online"), which the engine can apply efficiently. If a condition uses a measure, iterate over a small dimension table instead, like FILTER(VALUES(Customer[CustomerID]), [Sales] > 10000). Then test in DAX Studio with server timings before and after.
Frequently asked questions
How important is DAX Fundamentals in Power BI interviews?
DAX is the core skill tested in every Power BI interview. Learn measures versus calculated columns, row context, filter context and context transition, CALCULATE, iterators like SUMX, ALL and REMOVEFILTERS, FILTER, RELATED, DIVIDE, variables and counting functions, plus how to debug totals that do not add up and measures that repeat the same value.
How should I use the DAX Fundamentals sheet?
Go top to bottom — easy to hard. Answer before opening each answer, tick what you solved and save misses to Last-Minute Revision.