Top Power BI Interview Questions & Answers (2026)

Row context exists when DAX iterates a table row by row, in a calculated column or inside an iterator like SUMX; it lets you reference the current row's values but does not filter anything by itself. Filter context is the set of filters active when a measure is evaluated: slicers, visual axes, page filters, and anything CALCULATE adds. Context transition is what happens when CALCULATE runs inside a row context: it turns the current row into an equivalent filter context. That is why a measure referenced inside SUMX over Customers gives a per-customer value, because every measure reference is implicitly wrapped in CALCULATE. It is powerful but it can be slow over large tables and surprising when the table has duplicate rows.

CALCULATE evaluates an expression in a modified filter context. It takes the existing filters, performs context transition if there is a row context, then applies each filter argument. A simple predicate like Product[Color] = "Red" replaces any existing filter on that column, it does not intersect with it, so if the user sliced to Blue you still get Red. If I want intersection, I wrap it in KEEPFILTERS. Modifiers like REMOVEFILTERS or ALL clear filters, which is how I build percent-of-total: sales divided by CALCULATE of sales with REMOVEFILTERS on the product table. USERELATIONSHIP activates an inactive relationship, which I use for ship date versus order date. I always test edge cases in a matrix with totals turned on.

My default is single direction, from the one side to the many side, dimension to fact. Bidirectional filtering lets a fact table filter a dimension, which sounds handy but creates ambiguous paths once you have two facts sharing dimensions, can hurt performance, and interacts badly with RLS. The legitimate cases are narrow: a bridge table in a many-to-many pattern, or a slicer that should only show products with sales. Even then I prefer scoping it inside one measure with CROSSFILTER, or filtering the slicer visual with a measure that is not blank, so the behaviour is explicit and does not leak into every other visual in the report.

I would use dynamic RLS rather than one role per region. I add a security table mapping user email to region, relate it to the Region dimension, and create one role with a DAX filter on the security table like [Email] = USERPRINCIPALNAME(). The filter flows from security table to Region to the fact. I test with View as role in Desktop and with test users in the service, then assign the role to an Entra ID security group rather than individuals. Two things people miss: RLS only restricts users with Viewer permissions, so workspace Admins, Members and Contributors see everything; and the role needs at least one member, or a Viewer who is in no role sees no data.

I create two datetime parameters named exactly RangeStart and RangeEnd, filter the fact table's date column with one inclusive and one exclusive boundary so rows are not duplicated, then define the policy: for example store five years, refresh the last ten days. After publishing, the service creates partitions and the first refresh loads the full history, which can be long. Gotchas: the filter must fold to the source or every partition reads the whole table; the policy only applies in the service, Desktop just loads the filtered sample; and once published you cannot download the PBIX back, and republishing from Desktop wipes the partitions, so later schema changes go through XMLA tools. I also use detect data changes when a reliable last-updated column exists.