DAX vs Power Query vs data modelling: what PL-300 actually tests

Published 8 November 2026 · 11 min read · By a Microsoft Certified Power BI Data Analyst

Ask a group of PL-300 learners what confuses them most and you'll hear the same thing: "I understand Power Query, I understand DAX, but in the exam I can't tell which one the question wants." That confusion is not a gap in knowledge. It's a gap in judgement, and the exam deliberately tests it.

Many PL-300 questions describe a business problem and ask where or how to solve it: in Power Query, in the data model, or with DAX. Pick the wrong layer and the answer is wrong, even if your formula would technically work. This guide gives you a simple rule for choosing, then shows how it plays out in typical scenarios.

The three layers in one picture

Think of a Power BI report as a kitchen:

Notice that DAX sits inside "Model the data". Together, Power Query and the model-plus-DAX layer make up roughly half to 60 percent of the exam's weight. Getting the layer choice right is worth a lot of marks.

The rule: clean early, calculate late

When a question describes a requirement, ask yourself one question: "Does the answer change depending on what the user filters?"

• No, it's a fixed fact about each row (a cleaned name, a split column, a corrected type, a category). Do it in Power Query, as early as possible.
• Yes, it depends on the selection (a total for the selected region, a year-to-date figure, a percentage of the selected total). That's a DAX measure.
• It's about how tables connect or how filters travel. That's the model: relationships, direction, cardinality, a date table.

Microsoft's own guidance follows the same idea, often summarised as doing transformations as far "upstream" as possible and as far "downstream" as necessary. Cleaning in Power Query keeps the model smaller and faster. Calculating in measures keeps results correct in every context.

What Power Query questions look like

These questions describe messy data and ask which transformation fixes it. Recognising the problem is half the answer:

A common trap: merge vs append. Merge adds columns from another table by matching a key (like a join). Append adds rows by stacking tables with the same structure. If the scenario says "combine this year's and last year's sales into one table", that's append.

Also expect questions on data profiling, on query settings like "enable load", on reference versus duplicate queries, and on choosing the right connectivity mode: import, DirectQuery or composite models.

What data modelling questions look like

Modelling questions are about structure rather than formulas. The ideas that come up again and again:

• Star schema. One fact table (transactions such as sales) connected to dimension tables (customer, product, date). If a scenario has a flat, wide table that makes calculations slow or confusing, the answer often involves splitting it into a fact and dimensions.
• Cardinality. One-to-many is the normal relationship between a dimension and a fact. Many-to-many relationships need care and often signal a modelling problem.
• Cross-filter direction. Single direction (dimension filters fact) is the default and usually correct. "Both" can solve specific problems but can cause ambiguity and performance issues.
• Active and inactive relationships. A fact table with Order Date and Ship Date can only have one active relationship to the date table. You use USERELATIONSHIP in a measure to use the other one.
• Date table. Time intelligence needs a proper date table with one row per date, marked as the date table.
• Role-playing dimensions, hierarchies, and hiding fields users shouldn't see.
• Performance: reducing columns and rows, choosing appropriate data types, and using tools like Performance Analyzer.

What DAX questions look like

DAX questions usually give you a requirement and either ask you to choose the right formula, complete a formula, or say what a formula returns. You don't need to memorise hundreds of functions. You need to understand a few ideas really well.

Calculated column vs measure

This single idea answers a surprising number of questions.

If a value needs to be used on an axis or in a slicer, it must be a column, and the exam will usually prefer creating it in Power Query rather than as a DAX calculated column. If it needs to react to filters, it must be a measure.

CALCULATE and filter context

CALCULATE evaluates an expression with modified filters. It's behind most "percentage of total", "sales for a specific category" and "ignore this slicer" questions. Learn three patterns cold:

Sales Red = CALCULATE ( [Total Sales], Product[Color] = "Red" )

% of All Products =
DIVIDE ( [Total Sales], CALCULATE ( [Total Sales], ALL ( Product ) ) )

Sales YTD = TOTALYTD ( [Total Sales], 'Date'[Date] )

Time intelligence

Year-to-date, same period last year and running totals appear often. All of them depend on a correct, marked date table. If a question says time intelligence "returns blank" or "wrong values", look at the date table first.

Iterators

Know the difference between SUM (adds a column) and SUMX (evaluates an expression row by row, then adds the results). "Revenue = quantity × price per row" is a SUMX question.

Five scenarios: which layer?

The traps exam questions use

• Two answers that both "work". A DAX calculated column and a Power Query custom column can both create a category. The better answer is usually Power Query, because it's cleaner and keeps the model efficient. Read for words like "minimise model size" or "improve performance".
• "Least effort" or "minimise development". Prefer a built-in feature over a custom formula: a quick measure, a built-in visual option, or an existing transformation.
• Filter direction set to "Both" as a fix. It may work, but it's rarely the best answer unless the scenario specifically needs it.
• Measures that ignore slicers. If the requirement says "regardless of the slicer", you need ALL or REMOVEFILTERS inside CALCULATE.
• Calculated tables for things the model already does. Watch for answers that duplicate data unnecessarily.

How to practise the judgement, not just the syntax

1. Use one dataset all the way through. Clean it in Power Query, model it as a star schema, then write measures on top. You'll feel why each layer exists.
2. For every requirement, say the layer out loud before you build. "This is fixed per row, so Power Query." It sounds simple, and it trains exactly what the exam tests.
3. Break things deliberately. Delete a relationship, set a filter to both directions, unmark the date table, and watch what changes.
4. Explain every practice question you get wrong in one sentence: "I chose a DAX column; it should be Power Query because…". Our practice Q&A PDFs are built around explanations for this reason.

Import, DirectQuery or composite: the other "which layer" question

Before you even reach Power Query, the exam may ask how Power BI should connect to the data. This is another judgement question that confuses learners, because all three options "work".

The words in the scenario usually decide it. "Real-time" or "latest data without waiting for refresh" points to DirectQuery. "Fastest report performance" points to import. "Reuse the certified company model" points to a live connection. Remember that DirectQuery limits some Power Query transformations and can make complex DAX slower, which is often why it's the wrong answer when the scenario stresses performance.

Performance questions: where do you fix slowness?

When a scenario says a report is slow or a model is too large, the answer is again about layers. Fix the problem as early as possible:

1. Power Query first: remove columns you don't need, filter out rows you don't need (old years, test data), and set correct data types. Smaller data means a faster model.
2. Model next: replace a flat wide table with a star schema, avoid unnecessary bidirectional relationships, and avoid high-cardinality columns such as unique IDs or date-time values with seconds when you don't need them.
3. DAX after that: prefer measures over calculated columns, use variables to avoid repeating calculations, and use DIVIDE rather than manual error handling.
4. Report last: reduce the number of visuals on a page, and use Performance Analyzer to find which visual is slow.

Performance Analyzer is the tool to remember for "which visual is slow?" questions. It records how long each visual takes, split into the DAX query, visual display and other time.

Practice drill: choose the layer

Try these before opening the answers. Say the layer out loud and give one reason, the same way you will in the exam.

If you got six or more right with the correct reason, your layer judgement is in good shape. If not, go back to the rule: fixed per row → Power Query; depends on selection → DAX; how tables connect → model.

How much DAX do you really need?

Less than most people fear, but deeper than most people practise. You don't need advanced patterns. You do need to be completely comfortable with aggregation functions, DIVIDE, CALCULATE with filters, ALL and REMOVEFILTERS, the common time-intelligence functions, USERELATIONSHIP, the X iterators such as SUMX, and RELATED. Most importantly, you need to predict what a measure returns in a given filter context.

If DAX feels like the wall you keep hitting, give it a longer slot in your plan. In the 8-week study plan, DAX starts in week 3 and keeps returning through practice and revision. Beginners should read PL-300 for beginners for a gentler order.

Frequently asked questions