In this post we are going to cover Direct Lake and Power BI in Microsoft Fabric: how Direct Lake differs from Import and DirectQuery, fallback, guardrails, framing, the retired default semantic models and where business logic belongs. These are 7 real Microsoft Fabric interview questions, asked the way they come up on a real project, and the last one is a scenario where leadership wants one sales model on the lakehouse that serves fifty reports.
Direct Lake is the storage mode that lets a Power BI semantic model read the Delta tables in OneLake directly, without copying the data into the model. Interviewers ask about it because it is where the data engineer's work meets the BI developer's work. The file layout of your gold tables decides how fast the reports are, and when the numbers refresh.
Part 8 of the Real Time Microsoft Fabric Interview Questions and Answers series on TechBrothersIT.
- The short answer
- Question 1: Your Power BI lead asks what Direct Lake is and how it differs from Import and DirectQuery. What do you say?
- Question 2: A report on Direct Lake suddenly runs slowly and the model shows DirectQuery queries. What is fallback, and how do you prevent it?
- Question 3: A table grew past a size limit and the model stopped working in Direct Lake. What are the guardrails per capacity size?
- Question 4: After the nightly load, users still see yesterday's numbers in a Direct Lake report. What is framing, and how do you control refresh?
- Question 5: Default semantic models used to appear automatically on every lakehouse. What changed, and how do you build models now?
- Question 6: The data engineer and the BI developer argue about where measures and business logic belong. What do you recommend?
- Scenario 7: Leadership wants a single sales model on the lakehouse that serves fifty reports. How do you design it end to end?
The short answer
Direct Lake lets a semantic model read Delta tables in OneLake directly, at close to Import speed, with framing instead of a data refresh. Direct Lake on OneLake never falls back to DirectQuery; on the SQL endpoint, views, SQL security and guardrail breaches cause fallback. Default semantic models are retired: build one owned model on V-Order gold tables.
Keep that in mind. Every question below is one piece of it.
Question 1: Your Power BI lead asks what Direct Lake is and how it differs from Import and DirectQuery. What do you say?
Direct Lake is a storage mode for semantic model tables. The VertiPaq engine reads the Delta tables straight from OneLake, so queries run close to Import speed, without copying the data into the model.
Let's put the three modes side by side.
| Import | DirectQuery | Direct Lake | |
|---|---|---|---|
| DATA | copied into the model | stays in the source | Delta in OneLake, no copy |
| SPEED | fast, in memory | as fast as the source | close to Import |
| REFRESH | scheduled data refresh | none: live queries | framing: metadata, seconds |
Import copies the data into the model. It is fast, but the data is duplicated, and it needs a scheduled refresh. DirectQuery sends every visual's query to the source, so it is only as fast as the source.
Direct Lake sits in between. Its refresh is called framing, and it only points the model at the latest Delta version, so it takes seconds. Columns load into memory on demand, the first time a query needs them.
There are two flavors, and interviewers like to hear both:
- Direct Lake on OneLake reads one or many Fabric sources and never falls back to DirectQuery. It is the recommended option for new models.
- Direct Lake on the SQL analytics endpoint uses a single source, and it can fall back.
It needs a Fabric capacity. And the gold Delta tables become the model's storage, so their file layout matters.
Question 2: A report on Direct Lake suddenly runs slowly and the model shows DirectQuery queries. What is fallback, and how do you prevent it?
Fallback only happens with Direct Lake on the SQL analytics endpoint. When a table can't be read in Direct Lake mode, the query runs as DirectQuery against the endpoint. It still works, just slower, and that is why the report slowed down without an error.
These are the usual triggers:
- SQL security on a table: row-level security, object-level security or dynamic data masking.
- A SQL view instead of a table.
- A guardrail breach: too many files, row groups or rows.
- A table that was not framed after a change.
To prevent it, first model Delta tables, not views, and materialize the view logic as a gold table. Then move security into the model, or use OneLake security with Direct Lake on OneLake, instead of SQL security on the endpoint. And keep the tables inside the guardrails with OPTIMIZE.
The Direct Lake behavior property controls fallback:
| DirectLakeBehavior | What happens |
|---|---|
| Automatic (default) | falls back to DirectQuery |
| DirectLakeOnly | no fallback: you get an error |
| DirectQueryOnly | always DirectQuery |
Setting it to DirectLakeOnly turns fallback off, so you get an error instead of a silent slowdown.
Use Direct Lake on OneLake: it never falls back. The trade-off is that it can't read SQL views.
Question 3: A table grew past a size limit and the model stopped working in Direct Lake. What are the guardrails per capacity size?
Direct Lake guardrails grow with the capacity SKU. Parquet files, row groups and rows are limited per table. Model size on disk is limited per model. Max memory is not a hard limit: it caps how much data can be paged in.
| SKU | Files, row groups per table | Rows per table | Size on disk, per model | Max memory (paging) |
|---|---|---|---|---|
| F2 TO F8 | 1,000 | 300 million | 10 GB | 3 GB |
| F64 | 5,000 | 1.5 billion | unlimited | 25 GB |
| F1024 AND UP | 10,000 | 24 billion | unlimited | 400 GB |
So on F2 to F8 a table can have 1,000 files or row groups and 300 million rows. On F64 it is 5,000 files or row groups and 1.5 billion rows per table, with 25 GB of max memory. From F1024 up, it is 10,000 files or row groups, 24 billion rows and 400 GB of max memory.
What happens on a breach depends on the flavor. Direct Lake on OneLake fails the refresh, and the model can't be queried until you fix it. Direct Lake on the SQL endpoint falls back to DirectQuery. Either way, one table over a guardrail stops Direct Lake for the whole model, not just that table.
In practice it is usually files, not rows. Small appends and over-partitioning create thousands of them. Use the read heavy for Power BI resource profile on gold tables, and run OPTIMIZE with V-Order.
spark.conf.set("spark.fabric.resourceProfile",
"readHeavyForPBI")
spark.sql("OPTIMIZE gold.fact_sales VORDER")Aggregate or trim history in gold, or move to a bigger SKU.
Question 4: After the nightly load, users still see yesterday's numbers in a Direct Lake report. What is framing, and how do you control refresh?
Framing is the Direct Lake refresh. It points the model at the latest version of each Delta table and evicts what changed. It is metadata only, so it takes seconds.
Automatic updates are on by default, so the model picks up new Delta versions by itself. Yesterday's numbers usually mean one of two things: automatic updates were turned off, or suspended after a failed refresh, and nothing reframes the model after the load.
Turning them off is often the right call, though. Say the model is framed on version 41, yesterday's data, and tonight's load writes version 42 table by table. During a multi-table load, automatic updates can show a half-loaded state, like new facts with old dimensions. So turn them off, and reframe once when the load is done.
Here is the pipeline in order:
- First, the gold notebooks load every table.
- Then a Semantic model refresh activity runs. For a Direct Lake model that refresh is framing, so it is fast.
- On failure, the pipeline alerts the team with a Teams or Outlook activity.
Automatic updates for simple, single-table loads. For real pipelines, turn them off and make the refresh the last step.
Question 5: Default semantic models used to appear automatically on every lakehouse. What changed, and how do you build models now?
Default semantic models are retired. Since September 5, 2025, Fabric doesn't create them, and by the end of November 2025 the existing ones were decoupled into normal, independent semantic models.
So in an older workspace you may still see them, but they are ordinary models now. Check which reports use them, keep those, and clean up the rest.
Now you build the model on purpose. Let's go through it step by step:
- Create a new semantic model on the lakehouse, on purpose.
- Pick only the gold tables you need.
- Use Direct Lake on OneLake for new models.
- Model it as a star schema: relationships, a date table, measures, and hidden technical columns.
- Promote it with deployment pipelines like any other item, and give report authors Build permission, so new reports reuse the model instead of copying it.
One model per business area, with a named owner.
Question 6: The data engineer and the BI developer argue about where measures and business logic belong. What do you recommend?
My rule: push logic as far upstream as you can, and only as far downstream as you must. Row-level logic goes into the gold Delta tables. Logic that depends on filters goes into DAX measures.
Upstream, in the gold tables, built once in Spark or SQL:
- Cleansing and conformed dimensions.
- Derived columns and flags.
- Business and surrogate keys.
Because it is built once, every engine sees the same values: Power BI, the SQL endpoint and notebooks. For example, a net amount column goes in the notebook.
gold = silver.withColumn(
"net_amount", F.col("amount") - F.col("discount"))Downstream, in the semantic model:
- Ratios and percent of total.
- Year to date and prior year.
- Anything that depends on the filters a user picks.
So the margin measure goes in DAX.
Margin % =
DIVIDE ( [Sales Amount] - [Cost Amount],
[Sales Amount] )Direct Lake adds one more reason to keep row-level logic upstream: calculated columns and tables on Direct Lake on OneLake are still in preview.
The data engineer owns the gold tables, the BI developer owns the model and measures, and they review the star schema together.
Scenario 7: Leadership wants a single sales model on the lakehouse that serves fifty reports. How do you design it end to end?
This one pulls every earlier answer together. The flow is silver, then a gold star schema, then one sales model, then fifty thin reports. Let's build it layer by layer.
- Gold star schema. A sales fact with conformed dimensions for date, customer, product and store. Real Delta tables, not views, with V-Order, kept compact with OPTIMIZE.
- One Direct Lake model. On top, one semantic model in Direct Lake on OneLake, so there is no DirectQuery fallback. It holds the relationships and measures, with OneLake security roles for the row-level rules.
- Guardrails. Size it against the capacity's guardrails, using the biggest fact table's rows and files, and aggregate history in gold if needed.
- Pipeline. The nightly pipeline loads gold, runs OPTIMIZE, then a Semantic model refresh activity frames the model once, with an alert on failure. Automatic updates stay off, so no one sees a half-loaded night.
- Thin reports. The fifty reports are thin reports on that one model. Report authors get Build permission, and the model moves from dev to test to prod with deployment pipelines.
One copy of the data, one version of the numbers, fifty fast reports.
Key points to remember
- Direct Lake: VertiPaq reads Delta in OneLake, no copy, framing in seconds
- Fallback only on the SQL endpoint: views, SQL security, guardrails
- Guardrails per SKU: files, row groups, rows; OPTIMIZE with V-Order
- Framing: auto updates or a refresh activity as the last pipeline step
- Default models retired: one owned model, logic upstream, measures in DAX
Part 9: Security, Governance and CI/CD
Part of the Real Time Microsoft Fabric Interview Questions and Answers series on TechBrothersIT. Features, limits and their status (GA or preview) are current as of October 2026; check the Microsoft Learn page for anything you quote in an interview.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.