Microsoft Fabric Direct Lake Interview Questions: Framing, Fallback, and Capacity

“Direct Lake reads Delta tables without a traditional full import” is a useful opening, but it is not enough to diagnose a stale visual or a suddenly slow report. A strong Microsoft Fabric interview answer separates three events: a Delta commit, the semantic model's framing of that data, and a query's decision to stay in Direct Lake or fall back to DirectQuery. It also names which Direct Lake architecture is in use.

This guide uses an original sales-dashboard incident to practice that diagnosis. For wider platform decisions, see Microsoft Fabric Data Engineer Interview Questions. The product changes quickly; the official Microsoft documentation linked here is the authority for current support and guardrails.

Evidence boundary: Official facts about Direct Lake modes, framing, fallback, and capacity are from Microsoft Learn. Candidate reports: no verified same-cycle candidate report establishes that a specific company asks this exact incident. Inference: the incident timeline, troubleshooting order, and evaluation rubric are original interview practice, not a claim about a real customer's deployment.

The incident: a late sales figure and a slower report

At 09:00, a pipeline commits a new Delta version for Sales in OneLake. At 09:02, a finance analyst opens a report and still sees yesterday's total. At 09:08, a refresh of the semantic model completes and the total changes. At 09:15, a different report page becomes much slower after a security change on the SQL analytics endpoint. The team says, “Direct Lake must be broken. Should we switch to Import?”

The first task is to ask for the model's architecture: Direct Lake on OneLake or Direct Lake on SQL analytics endpoints. Microsoft documents both in its Direct Lake overview. They have different source and security behaviors, and only the SQL endpoint variant has DirectQuery fallback. Without that distinction, the 09:15 diagnosis can be exactly backward.

Also ask whether the 09:02 visual is truly using the expected semantic model and measure, whether automatic updates are enabled and healthy, and whether report-page caching or a separate refresh layer is involved. The timeline suggests a framing delay, but does not prove it. A good answer names the observation that would falsify that hypothesis.

What is framing, and why does it affect freshness?

Official fact: Microsoft's How Direct Lake works describes framing as the operation that establishes which Delta table files form the semantic model's baseline. Direct Lake then loads or transcodes needed columns into memory for queries. Framing is a metadata operation; it is not the same thing as importing every table row into a conventional Import model.

The sales pipeline's Delta commit is therefore not by itself proof that the report's semantic model has framed that commit. The last successful frame determines the data baseline for Direct Lake reads. A refresh can trigger framing. Automatic updates can also keep a model current; Microsoft's docs say the setting Keep your Direct Lake data up to date is enabled by default, but automatic updates can stop after a non-recoverable refresh error. “You must manually refresh after every write” is too broad; “it is always instantly current” is also too broad.

At 09:02, inspect the Delta commit time and version, the semantic model's last successful framing/refresh status, and the report query path. If the model had already framed the new version, investigate measure logic, filters, relationship behavior, or report caching instead. If it had not, inspect automatic-update status, refresh errors, and schedule before blaming the Delta writer.

Frame boundaries can be useful: a report may intentionally present a consistent completed batch rather than transient intermediate ETL states. The business requirement should define “fresh”: latest committed row at query time, latest completed batch, or a published daily close. Only then choose an update schedule and data-quality gate.

Direct Lake on OneLake versus on SQL endpoints

The two architectures are related but not interchangeable. Official fact: Microsoft says Direct Lake on OneLake reads eligible Delta tables without DirectQuery fallback; new models are generally recommended to use this option where its source and feature requirements fit. Direct Lake on SQL analytics endpoints uses the SQL endpoint for discovery and permission checks and can fall back to DirectQuery when it cannot use the Direct Lake path. The overview lists supported sources and limitations for each.

For example, Direct Lake on SQL can use a SQL view as a source, but a query involving an unmaterialized view may fall back to DirectQuery. SQL-defined RLS, OLS, or dynamic data masking at the endpoint can also lead to fallback. Direct Lake on OneLake does not “honor SQL endpoint RLS by magic”; security must be modeled using the applicable OneLake and semantic-model access controls. Microsoft's Direct Lake security integration covers this nuance. The safest interview response is to name the security layer that actually controls the data path, not just say “RLS works.”

If the team recently added endpoint RLS and the SQL endpoint variant slowed at 09:15, fallback is a plausible hypothesis. If the model is on OneLake, DirectQuery fallback is not the explanation; check the security configuration, query diagnostics, and capacity behavior appropriate to that mode.

What does a fallback look like?

Official fact: For Direct Lake on SQL analytics endpoints, Microsoft's workings guide describes DirectLakeBehavior settings. The default Automatic can silently use DirectQuery when Direct Lake conditions are not met. A report may remain correct while becoming slower because its query now goes through the SQL endpoint. DirectLakeOnly prevents fallback and surfaces an error instead; DirectQueryOnly deliberately uses the endpoint. These settings apply to the SQL endpoint variant, not Direct Lake on OneLake.

The same guide gives a diagnostic DAX query:

EVALUATE TABLETRAITS()

Inspect [DirectLakeFallbackInfo] for the relevant table and query context. A value indicating None is evidence that the table is using Direct Lake mode in that check. Pair it with query-level performance evidence and the model configuration; do not conclude from the report's visual appearance alone. Check whether a view, SQL security, an unframed new table, a missing table, a transient error, or a guardrail is involved.

Fallback can also have a freshness implication: Microsoft's docs note that DirectQuery fallback can read the latest data at the SQL endpoint rather than the last framed Direct Lake baseline. A “freshness fix” that is actually fallback may trade latency and capacity for recency. Before celebrating, test the correct path deliberately and document the intended consistency contract.

Where does capacity enter the answer?

Direct Lake requires Fabric capacity, and SKU-specific guardrails constrain table/file/row-group shape and resource use. Microsoft's Direct Lake overview publishes the current requirements. Avoid memorizing one number as a universal limit: SKU and product rules can change, and different guardrails are evaluated at different scopes.

Official fact: If relevant guardrails are exceeded, Direct Lake on OneLake can fail framing or querying rather than fall back. Direct Lake on SQL can fall back to DirectQuery when permitted, with a warning or slower queries. Microsoft also distinguishes memory pressure from a hard eligibility limit: excessive paging can harm performance even when a model stays nominally in Direct Lake.

For a slow sales report, inspect file counts, row groups, table size, capacity SKU, concurrent workloads, and fallback diagnostics. Many tiny Parquet files can be an optimization target; Microsoft's troubleshooting advice includes Delta-table maintenance such as OPTIMIZE and, where appropriate and safe, VACUUM. Do not run VACUUM as a generic speed button without considering retention, time travel, and other consumers. A higher SKU can help, but right-sizing without diagnosing table shape and concurrent load may simply move the bottleneck.

If the report is slow only immediately after framing, column transcoding and cold in-memory state may be relevant. If it remains slow, look at query design, model relationships, capacity pressure, and whether DirectQuery fallback has taken over. Test a representative warm and cold pattern, not one screenshot of total duration.

A diagnostic matrix for the invented incident

Use this as a conversation aid, not a product status dashboard.

Observation	Leading hypothesis	Evidence to collect	Next controlled test
Delta commit at 09:00; old total at 09:02	New Delta version not yet framed	Commit/version and last successful frame	Refresh or wait for healthy auto-update, then compare.
New total after 09:08 refresh	Framing likely changed baseline	Refresh history, model/query identity	Repeat with a known small test batch.
Slow after SQL endpoint RLS change	SQL variant may fall back	Model mode, TABLETRAITS(), query diagnostics	Compare before/after query path in safe environment.
Error after growing file count	Guardrail or frame failure	SKU limits, file/row-group counts, refresh error	Optimize source layout and retry framing.
Slow without fallback	Memory or model/query issue	Capacity metrics, column residency pattern, DAX plan	Compare warm/cold and concurrent load.

Each row is conditional. The report could have an incorrect measure or the pipeline could have committed bad data; Direct Lake is not the only possible cause. The value of the matrix is to separate where to look next and what a successful test would show.

Questions an interviewer may use to probe you

“Does Direct Lake eliminate semantic-model refresh?” Answer: it avoids a full Import data load, but framing/refresh still matters for the Delta baseline, and automatic updates need monitoring. “Will every Direct Lake query be fast?” No: capacity, table layout, model design, cold column loading, and fallback matter. “Can I put SQL endpoint RLS on everything and retain direct file access?” Not without checking the architecture and security path. “What happens if one table exceeds a guardrail?” Use current Microsoft docs and the actual model mode; do not assume a per-visual behavior from memory.

The strongest follow-up is often a decision: choose OneLake or SQL endpoint variant for a particular security and source requirement. State the requirement first. If direct access and no fallback are essential, test OneLake source support and implement security at the right layer. If SQL endpoint views or granular SQL security are required, acknowledge potential DirectQuery fallback and budget for its performance. Neither mode is a universal winner.

Practice the transferable engineering skills

Complete practice question	Apply it to Direct Lake
Design a Data Quality and Observability Pipeline	Prove that committed Delta data is valid before framing.
Defend a Data Pipeline Architecture and Its Trade-offs	Explain freshness versus consistency and fallback.
Design an Incremental Rolling-Metrics Data Pipeline	Define when a new metric window becomes visible.
Explore Dataset to Assess Quality and Choose Visualizations	Check that report-level filters match expected numbers.
Answer SQL And Data Warehouse Fundamentals For A Data Engineering Interview	Separate source layout from semantic-model behavior.

For a final mock answer, name the mode, line up the Delta commit with the last frame, inspect TABLETRAITS() only where fallback exists, and compare capacity against current SKU guardrails. Then say which observation would disprove your first hypothesis. Begin with Defend a Data Pipeline Architecture and Its Trade-offs and present the trade-off in a two-minute explanation.

Sources and further reading

• Microsoft: Direct Lake overview
• Microsoft: How Direct Lake works
• Microsoft: Direct Lake security integration
• Microsoft: Manage Direct Lake semantic models