Power BI Interview Questions - Practice Real Quiz

Line 11 creates a relationship on FactSales[SalesAmount], which is a measure/fact column — not a foreign key. In a star schema, relationships must join a foreign key in the fact table to a primary key in a dimension table. Additionally, DimProduct[ProductKey] already participates in the relationship on line 8, so line 11 would create an ambiguous filter path between the same two tables.

Filter context is one of the two fundamental evaluation contexts in DAX (the other being row context). At difficulty 1, the key recall point is that filter context determines which rows are visible during evaluation and comes from user interactions in the report (slicers, visual cross-filtering) as well as programmatic filter arguments.

Query folding is exactly this mechanism: Power Query translates transformation steps (such as filtering, sorting, grouping, and selecting columns) into a native source query — most commonly a SQL SELECT statement — and sends it to the data source so the source engine does the heavy lifting. This reduces the volume of data transferred to Power BI and improves refresh performance. When folding breaks (e.g., after adding a non-foldable step), subsequent steps are processed locally, which can be much slower.

A measure's DAX expression is re-evaluated every time it's placed in a visual, responding to whatever filter context that visual, its slicers, and its page filters currently apply — the result is never written back into the model, so it costs no extra storage. A calculated column's formula runs once per row during data refresh (or when the model is otherwise recalculated), and the resulting value for every row is materialized and stored in the compressed in-memory model exactly like a column loaded from the source, which means it consumes VertiPaq storage and refresh time regardless of whether a report ever uses it. That's why the standard guidance is to prefer a measure whenever the calculation can be expressed dynamically — a calculated column is reserved for cases where the value has to exist as a discrete row value, such as something you need to filter, slice, or group by, or a row-level security condition.

In a star schema every dimension sits exactly one relationship away from the fact table it describes, so a filter applied to a dimension (say, filtering Product by category) only has to propagate across a single relationship to reach the fact table — fewer hops means fewer relationships the engine has to traverse to resolve a visual's query, and it also gives report authors a flatter, more predictable Fields list. A snowflake schema normalizes a dimension further (Product → Subcategory → Category, each its own table), which mirrors relational database design but adds extra relationship hops that filters must cross, and typically adds little practical benefit inside a semantic model, since the dimension tables involved are almost always small relative to fact tables — the storage saved by normalizing them further is rarely worth the added query complexity. Dimension-to-dimension relationships are technically possible in Power BI (b is wrong), refresh time is not the deciding factor here since dimension tables are the smaller side of the model (c is wrong), and the two designs do measurably differ in query-time relationship traversal (d is wrong).

A workspace has to exist before anything can be published into it, so it's the starting point, and it's also where the actual authoring happens — reports and semantic models are built and iterated on there by people with edit permissions. An app is a separate, curated distribution layer built from a workspace's content: configuring it means picking which reports and dashboards it exposes and to whom, which only makes sense once that content already exists in the workspace. Publishing the app is what actually generates the distributable version consumers open, and consumption comes last: business users interact with the read-optimized app, not the workspace itself, which is exactly the separation that lets a team keep iterating on drafts inside the workspace without exposing half-finished work to the wider audience using the app.

Microsoft guidance is to keep relationships single-directional by default and enable bidirectional only when justified (b). For row-level security, the specific 'Apply security filter in both directions' toggle is the targeted way to propagate RLS without making the whole relationship bidirectional (c). Setting every relationship bidirectional (a) and never using it at all (d) are both incorrect extremes.

Creating a manual relationship in the Model view follows a fixed sequence: you first switch to Model view, then drag a field from one table onto the corresponding field in another table to initiate the relationship, then configure cardinality and cross-filter direction in the dialog that appears, and finally confirm to persist the relationship in the model.

Import mode's defining behavior is that it copies and column-compresses the source data into VertiPaq, Power BI's in-memory analytical engine, so every report query is answered from that fast in-memory copy — which is also exactly why the data is only ever as fresh as the last refresh (a and d). DirectQuery instead never copies the data: each visual's query gets translated into a native query against the live source at the moment someone views the report, so the numbers are always current, but every interaction now depends on that source's own query latency (b). DirectQuery is not a universal performance win — it trades query latency and DAX limitations for freshness, and it's frequently slower than Import for typical reporting workloads because every click round-trips to the source instead of hitting an in-memory columnstore (c is wrong). DirectQuery also has real constraints on which DAX functions and constructs it supports, since not every DAX expression can be translated into every source's native query language — some functions (RANKX in a calculated column or RLS rule, for instance) are explicitly unsupported in DirectQuery (e is wrong).

False. RELATED follows a many-to-one relationship in exactly one direction: it's used from the 'many' side (typically a fact table row) to fetch a single related value from the 'one' side (a dimension table), because on the many side there's guaranteed to be exactly one matching row on the one side. Going the other way doesn't make sense for RELATED — from a single dimension row there can be many matching fact rows, not one, so there's no single value to return. To pull data from the 'many' side while sitting in row context on the 'one' side, the correct function is RELATEDTABLE, which returns a table of all the matching related rows instead of a single value — that table is typically fed into an aggregator like SUMX or COUNTROWS.

True. When query folding succeeds, Power Query doesn't retrieve raw source rows and then filter, group, or reshape them itself — it instead compiles the chain of applied steps down into one native query (for example, a single SQL SELECT statement with WHERE and GROUP BY clauses) and sends that to the source, so the source's own engine does the work and only the already-transformed result comes back over the wire. This matters enormously for refresh performance and source load: a query that folds fully might pull back a few thousand filtered, aggregated rows, while the same query with folding broken partway through could pull back the entire source table and do the filtering locally in the comparatively slower Power Query mashup engine. DirectQuery and Dual storage mode tables require folding to work at all, since every visual's query has to become a native query at the source in real time.

VertiPaq's columnar, compressed, in-memory design is the mechanical reason Import-mode Power BI models feel instant even over large datasets: a query only pays for the columns it actually touches, those columns are already compressed and resident in memory, and low-cardinality columns compress extremely well because there are few distinct values to encode. This is also why cardinality-reduction advice (fewer distinct values per column, splitting datetime into date + time, avoiding needless calculated columns with unique values) is treated as a first-class performance lever in Power BI modeling — it's a direct lever on how well VertiPaq can compress and scan the data.

RLS is Power BI's mechanism for row-level data isolation inside a shared semantic model — one report, one dataset, but each viewer only sees the rows their role allows. Static RLS is simple to set up but doesn't scale past a handful of fixed segments, since every new value needs its own role. Dynamic RLS trades a bit of setup complexity (a mapping table plus a USERPRINCIPALNAME()-based filter) for scaling to any number of users without touching the model again — which is why it's the standard approach for any RLS scenario beyond a small, static set of categories.

Everything downstream of a rendered number depends on the model already being loaded, so Power Query's extract-transform-load work and VertiPaq's compression happen first, at refresh time, entirely before any report is opened. From there, the report-time sequence is triggered by user interaction: a slicer click or a visual just rendering for the first time causes that visual to generate a DAX query, which resolves into a filter context before any aggregation can happen — filter context has to exist before a measure can be evaluated against it, not after. Only once the filter context is set does the measure's DAX expression actually run against the compressed in-memory columns, and only then does a single scalar value exist to hand back to the visual for rendering. Getting this order backward — for instance, imagining the DAX expression evaluates before filter context is resolved — is exactly the kind of confusion that makes 'why did my measure return the wrong number for this filter' hard to debug without a clear mental model of the pipeline.

The hub of a star schema is the fact table — it stores additive numeric measures at the grain of an event (e.g., a sales line) and foreign keys pointing to dimension tables that radiate outward like the points of a star.

Dimension tables contain unique rows for each entity (e.g., one row per ProductKey), so they occupy the 'one' side of the relationship. The fact table has many rows referencing the same dimension key, placing it on the 'many' side. This 1-to-many direction is what makes filter propagation from dimension to fact work correctly.

Outside of CALCULATE, a plain aggregation like SUM(Sales[Amount]) is evaluated in whatever filter context is currently active — and by itself, row context does not automatically become filter context, so with no ambient filter, SUM(Sales[Amount]) ignores the current row entirely and returns the grand total across the whole Sales table for every single row. CALCULATE is what performs context transition: when it wraps an expression while a row context is active, it converts that row context into an equivalent filter context that constrains every column to the current row's exact values, so the SUM inside it now only sees rows matching that filter — in a fact table with no duplicate keys, that reduces to just the current row's own Amount. This row-context-to-filter-context conversion is exactly what people rely on (often without wrapping it explicitly, since a plain measure reference gets an implicit CALCULATE wrapper) when they write DAX that behaves differently at the row level than the plain aggregate would.

Microsoft's own relationship guidance is explicit that bi-directional relationships require more processing and can hurt query performance as their count grows, so the general recommendation is to minimize them (a). One-to-one relationships are a special case that must be bi-directional — Power BI doesn't offer a single-direction option for them (b). Bi-directional filtering is also what produces the 'slicer options with data' effect, where selecting a value in one slicer dynamically narrows what's available in another, a behavior some report users find confusing because the options change without an obvious cause (d). For dimension-to-dimension analysis through a bridging fact table, Microsoft's guidance recommends the opposite of (c): rather than making the relationship permanently bi-directional in the model (which pays the performance cost on every query that touches it), activate bi-directional filtering just for the specific measure that needs it using the CROSSFILTER function inside CALCULATE. And (e) is simply false — the performance cost is the entire reason the guidance says to minimize bi-directional relationships in the first place.

RANKX evaluates its expression argument once per row of the table it's iterating, in that row's row context — but a plain aggregation function like SUM does not automatically respect row context the way a fully-fledged measure does. Row context only becomes filter context through context transition, and that transition only happens when CALCULATE (or CALCULATETABLE) wraps the expression, or implicitly, when the expression is a measure reference (every measure carries an implicit CALCULATE around its own definition). Here, SUM('Sales'[Amount]) is neither: it's a raw aggregation with no CALCULATE, so on every iteration of ALL('Product') it just evaluates in whatever filter context is already active outside RANKX — which, with no filter applied, is the grand total across the entire Sales table, identical for every product. The fix is RANKX(ALL('Product'), CALCULATE(SUM('Sales'[Amount]))) — wrapping the SUM in CALCULATE forces context transition, converting each product's row context into a filter context that constrains Sales to just that product's rows before summing, which is what actually makes the totals — and the ranks — differ per product. ALL('Product') is valid as RANKX's table argument (b is wrong), the default order argument ranks descending rather than ascending so no product is being pushed to a 'lowest rank' (c is wrong), and identical ranking for every row is never the intended behavior of RANKX (d is wrong) — it's the textbook symptom of a missing context transition, which is exactly why this pattern shows up repeatedly in real DAX debugging.

Query folding works by translating the chain of applied steps into one native query the source can run — but it can only fold a step if that step has an equivalent in the source's query language. A row-wise custom column built from a conditional M expression like each if [Amount] > 1000 then "Big" else "Small" has no direct SQL translation, so the moment the mashup engine hits AddFlag, it has to give up on further folding: it pulls the full result of everything folded so far — which, since nothing upstream filtered anything yet, means the entire Orders table — into memory, and evaluates AddFlag and every step after it, including the date filter on line 5, locally. Line 5's Table.SelectRows on [OrderDate] >= #date(2026,1,1) is a completely foldable predicate on its own (it would become a WHERE clause) — the problem isn't that step itself, it's that it was placed after the step that already broke folding (c is wrong, and b and d are wrong because selecting the Data column and using Sql.Database are both perfectly normal, foldable starting points). Microsoft's own query-folding guidance says exactly this: when a step prevents folding, move the steps that can fold earlier in the sequence so the mashup engine factors them into the native query before it gives up — here that means filtering Orders by date on line 5 first, then adding the non-foldable IsBigOrder column afterward, so the SQL WHERE clause does the heavy filtering at the source and the row-wise logic only has to run over the already-filtered, much smaller result set.

Row context is local to 'the current row' inside a calculated column or a table iterator; filter context is the global set of active filters that aggregation functions respond to. Relationships propagate filter context automatically, but they do not propagate row context — so simply being on a row of one table gives you no automatic visibility into a related table's rows unless you explicitly bridge the two, either by following the relationship directly with RELATED/RELATEDTABLE, or by using CALCULATE, which performs context transition: it converts the current row context into an equivalent filter context, which then flows across relationships exactly like a slicer selection would. This distinction is the root cause of a huge share of real DAX bugs — a plain aggregation with no CALCULATE, evaluated inside row context, just answers to whatever filter context already existed rather than reacting to the current row, which is why it silently returns the same total everywhere instead of erroring out.

Reprocessing an entire large fact table on every scheduled refresh doesn't scale — it's slow, it hammers the source with a full extract each time, and it can exceed the service's refresh time limits. Incremental refresh fixes this by splitting the table into date-based partitions and refreshing only the partitions that plausibly changed. The mechanism is the RangeStart and RangeEnd parameters: you filter the Power Query query for the fact table by a date column using those two parameters as bounds, and once the incremental refresh policy is configured in the Power BI service, it uses that same filter logic to automatically create and manage partitions — refreshing only the recent 'refresh period' window on each run while leaving older, already-loaded historical partitions alone. That's the difference between a refresh that reprocesses everything every time and one that scales to very large fact tables.

CALCULATE's FILTER argument iterates row-by-row over the Sales table. For each Sales row, RELATED(Products[Category]) traverses the many-to-one relationship from Sales[ProductID] to Products[ProductID] to retrieve the corresponding category. The two rows with ProductID=1 resolve to "Electronics" (Amounts 100 and 200), while the ProductID=2 row resolves to "Clothing" and is excluded. SUM of the remaining Amounts = 100 + 200 = 300. RELATED works here because the filter direction from Products to Sales means the lookup can traverse from the many side (Sales) to the one side (Products).

USERELATIONSHIP temporarily activates the inactive relationship on ShipDate and deactivates the active relationship on OrderDate for the duration of the CALCULATE. The report filter DateTable[Date] = 2024-01-01 therefore propagates through Sales[ShipDate] instead of Sales[OrderDate]. Only the third row (ShipDate = 2024-01-01, Amount = 50) satisfies this filter, so the result is 50. Option (b) 150 is what the active OrderDate relationship would yield (rows with OrderDate = 2024-01-01: 100 + 50). Option (c) 300 is the sum of rows where ShipDate = 2024-01-02 (a date-misreading error). Option (d) 350 is the unfiltered total of all rows.

When bidirectional cross-filtering is enabled on a relationship, the VertiPaq engine checks whether the resulting graph creates multiple equally-valid filter propagation paths between the same two tables. If it does, the engine cannot deterministically resolve which path to use, so it raises an ambiguity error and refuses to activate the relationship. The exact term used in the Power BI Desktop error dialog is 'ambiguity' — the message reads that the relationship cannot be active because it would create ambiguity. This is a model-design-time check, not a query-time one.