DAX vs Power Query: The PL-300 Distinction That Trips People Up

Almost everyone preparing for the Microsoft PL-300, the Power BI Data Analyst Associate exam, hits the same wall: they can write a bit of DAX and they can click through Power Query, but they cannot reliably say which tool they should reach for in a given situation. The exam loves this ambiguity. It will describe a business requirement and ask where the logic belongs, and the wrong answer is usually the one that technically works but solves the problem in the wrong layer. Getting this distinction straight is one of the highest-leverage things you can do for the Power BI Data Analyst certification, because it quietly underpins questions across the Prepare, Model, and Visualize domains.

Two tools, two moments in time

The cleanest way to keep DAX and Power Query separate in your head is to anchor each one to when it runs. Power Query, and the M language behind it, runs at load time. It is the extract-transform-load stage: it reaches out to your sources, reshapes the raw data, and produces the finished tables that get stored in the model when you press Refresh. Once the refresh finishes, Power Query's job is done and it goes quiet until the next refresh.

DAX runs at query time. Every time someone opens the report, clicks a slicer, or crosses-filters a chart, DAX evaluates against the data already sitting in the model and returns the numbers the visuals ask for. Power Query built the warehouse shelves and stocked them overnight; DAX is the clerk who, the moment a customer asks a question, counts what is on the relevant shelves right now given whatever filters the customer applied. That timing difference explains nearly every "which one should I use" decision on the exam.

A second useful frame is what each one produces. Power Query works in rows — it adds columns, filters rows, unpivots, merges, and appends, materializing values that are physically stored. DAX shines at aggregation — measures that sum, average, and rank on the fly, responding to context. If a requirement is about restructuring the shape of the data itself, that is upstream, Power Query work. If it is about a number that must recalculate as users slice and dice, that is a DAX measure.

Calculated column or measure? Row context vs filter context

The place this gets genuinely confusing is the overlap zone: calculated columns. You can create a new column with DAX or with Power Query, and both store a value on every row. So which is "right"? Here the PL-300 wants you to understand the two evaluation contexts.

A calculated column — whether written in DAX or M — is evaluated once per row, in row context. It knows about the current row and can reference other columns in that same row. Its result is computed during refresh and stored in the model, taking up memory. A measure is evaluated in filter context: it has no inherent "current row," and instead responds to the filters coming from the visual, slicers, and relationships at the moment it runs. It stores nothing; it is recomputed every time.

The practical rule the exam rewards: if a value depends only on other values in the same row and never needs to react to slicers — say, concatenating a first and last name, or flagging whether an order was placed on a weekend — it belongs in a column, and Power Query is usually the better home for it because that keeps calculation logic out of the model and closer to the source. If a value must change as the user filters — total revenue, a running average, a year-over-year percentage — it must be a DAX measure, because only a measure lives in filter context and recalculates on demand. Reaching for a calculated column when a measure is required is a classic exam trap: the column bakes in one static answer and cannot respond to the report at all.

A worked example

Imagine a sales table with a unit price, a quantity, and a discount percentage, and you need "net revenue" broken down by region, product, and month, with slicers on all three.

The line-level arithmetic — unit price times quantity times one minus the discount — is a per-row calculation that never changes regardless of how the report is sliced. That is a prime candidate to compute in Power Query as a new column while you are already cleaning the data. Doing it upstream means the value is stored once, the model stays simple, and if the same logic is needed elsewhere it is defined in exactly one place. The sum of that net-revenue column, however, is not something you hard-code. You write a DAX measure — Net Revenue = SUM(Sales[NetLine]) — and let filter context do the work: drop it into a matrix by region and it sums per region, add a month slicer and it responds, with no extra code. That division of labor — shape the row-level facts upstream, aggregate them with measures downstream — is the mental model the whole exam is built around. Many PL-300 practice questions are just this scenario wearing different costumes.

When to shape upstream vs model in DAX

Beyond correctness, the exam cares about good practice, and the guidance from Microsoft is consistent: push transformation as far upstream as you reasonably can. Cleaning, typing, filtering, and shaping data in Power Query — or better still in the source system — produces a smaller, faster, more maintainable model than doing the equivalent work in DAX after load. Calculated columns created in DAX are especially easy to overuse; each one inflates the model size and is often a sign that the work should have happened in Power Query instead. Save DAX for what only DAX can do: context-aware aggregation and the calculations that must respond to user interaction.

There are real exceptions. Some calculations genuinely need the model's relationships or the filter context to make sense and simply cannot be expressed at load time — anything involving RELATED across a relationship, time-intelligence over a marked date table, or ranking within the current selection. Recognizing which side of that line a requirement falls on is exactly the judgment the exam is testing, and it is a judgment you build by working through enough varied cases that the pattern becomes automatic.

How to lock this in before test day

Reading the distinction is easy; applying it under time pressure is where people stumble, because a well-written question deliberately makes the wrong layer look tempting. The fix is repetition against realistic scenarios until "load-time rows versus query-time aggregation" becomes the first thing you check. Our adaptive practice for the Microsoft Power BI Data Analyst exam targets the objectives where you are weakest, so if you keep mislabeling calculated columns and measures, it keeps surfacing that pattern until it clicks, and every missed question comes with an explanation you can review. When your scores stabilize, the full timed PL-300 exam simulations mirror the real format and pass mark so your readiness tracking tells you when to book with evidence rather than a hunch. Master where logic belongs, and a whole category of PL-300 questions stops being guesswork and starts being obvious.