Query folding means Power Query can push supported transformations to the data source. It depends on the connector, source capabilities and transformations. You cannot prove folding simply because a query contains a filter.

These Power BI interview questions use a fictional invoice source. The small local example demonstrates transformation logic. A separate source-backed check is needed to investigate folding.

What should the transformation return?

let
    Source = #table(
        type table [InvoiceId = number, Status = text, Amount = number],
        {{1, "Open", 40}, {2, "Closed", 60}, {3, "Open", 20}}
    ),
    OpenInvoices = Table.SelectRows(Source, each [Status] = "Open"),
    Selected = Table.SelectColumns(OpenInvoices, {"InvoiceId", "Amount"})
in
    Selected

The result should contain invoice IDs 1 and 3 with amounts 40 and 20. This in-memory table has no remote SQL source to offload work to. Use it to check the result shape, not as evidence of source query folding.

How would the source-backed exercise differ?

Connect to a dedicated test source containing the same columns and rows. Apply the filter and column selection. Inspect the available query plan, native query or diagnostic evidence supported by that connector and Power Query environment.

Do not include a real server name or credential in a public example. Record the connector and versions alongside the observation. Another connector can behave differently with the same-looking steps.

Can a query fold partly?

Yes. Some work may be sent to the source while later transformations run in the Power Query engine. A folding boundary is useful evidence when diagnosing why a large intermediate result moves across the network.

Do not conclude that every preceding step folds merely because the final output is small. The engine may have read much more data before applying the last transformation locally.

Should filters always go first?

Filtering early can reduce work, but the filter must preserve the intended result. A filter before a grouping or type conversion can have different semantics from one after it. Source optimization can also rearrange supported work.

Compare outputs as well as timings when reordering steps. An apparently faster query that drops required rows is not an improvement. Keep the row grain and null-handling rules explicit.

What if the native-query option is unavailable?

That alone is not a universal proof that no folding occurs. Tooling and connector support differ. Use the appropriate diagnostics and source-side evidence where available. Explain the limitation of the observation instead of turning one menu state into a blanket rule.

Refresh behavior also depends on import versus DirectQuery design, credentials, gateway access and privacy settings. A successful preview does not automatically prove a scheduled service refresh will succeed.

What would you record?

  • The exact source and connector type.
  • The applied steps and expected output.
  • Evidence of pushed-down operations.
  • The first observed non-folding boundary, if established.
  • Comparable refresh conditions and result counts.
  • Any service-only gateway or credential checks still required.

A good answer separates transformation correctness from execution location. Prove the returned rows first, then investigate where the work happens. Do not invent speed improvements or folding evidence that you have not measured.

References and next practice

learn.microsoft.com — bi query

Browse interview topics · Practise a question in Interview Challenge · How to Answer Technical Interview Questions Out Loud