DP-600 - Implement and Manage Semantic Models (27% of the exam) - Section 3.6

Configure Direct Lake behaviour, including fallback and refresh, choose between Direct Lake on OneLake and on SQL endpoints, and implement incremental refresh.

Configure Direct Lake mode to read Delta tables from OneLake without importing data, and understand when framing causes fallback to DirectQuery. Choose between Direct Lake on OneLake and Direct Lake on the SQL analytics endpoint, and implement an incremental refresh policy to limit data refreshed to recent partitions.

Direct Lakefallback to DirectQueryDirect Lake on OneLake vs SQL endpointincremental refreshrefresh policy

Practice question for this objective

Free sampleImplement and Manage Semantic Modelshard

A team builds a "Direct Lake" "semantic model" over Delta tables in a "Lakehouse". Reports must read brand-new rows the instant data engineers write them, and the model must keep working even if the read-only "SQL analytics endpoint" lags behind the latest Delta commit. Which "Direct Lake" variant should the engineer choose?

A"Direct Lake" on OneLake, which reads the Delta tables straight from "OneLake" and does not depend on the "SQL analytics endpoint" staying in sync with the latest commit Correct
B"Direct Lake" on SQL endpoint, which routes every read through the "SQL analytics endpoint" so the model always matches what that endpoint currently exposes to queries
CImport mode refreshed on a schedule, which loads the Delta rows into the model cache so reports query an in-memory copy that is fast and fully detached from "OneLake"
DDirectQuery over the "SQL analytics endpoint", which pushes each report query to the endpoint at run time so visuals always resolve against the live SQL surface

Choose "Direct Lake" on OneLake when the model must read the latest Delta commit without depending on the "SQL analytics endpoint" sync. "Direct Lake" on OneLake reads Parquet columns from the Delta tables in "OneLake" directly, so it surfaces the newest committed rows immediately, whereas the SQL endpoint variant inherits any lag in the endpoint's metadata refresh.

Why A is correct: "Direct Lake" on OneLake binds to the Delta tables in "OneLake" directly, so it reflects the newest committed rows without waiting for the read-only SQL surface to refresh its metadata.

Why B is wrong: This variant resolves tables through the "SQL analytics endpoint", whose metadata sync can lag the latest Delta commit, so it can miss the freshest rows the stem demands.

Why C is wrong: Import duplicates the data and only updates on a refresh schedule, so brand-new rows are invisible until the next refresh, which contradicts the instant-freshness requirement.

Why D is wrong: DirectQuery still depends on the "SQL analytics endpoint" and gives up the in-memory speed of "Direct Lake", so it both lags and performs worse than the required approach.

See more DP-600 practice questions, answers explained.

Exam traps in Implement and Manage Semantic Models

Answers that look right on this material and are not. Each one is a distractor from a different question in the DP-600 bank for this domain.

Build the model in import mode over the "Lakehouse" tables and schedule frequent refreshes, so reports read in-memory copies rather than depending on any SQL surface staying in sync.
Why it is wrong: Import mode duplicates the data into the model and relies on scheduled refresh, which adds latency and overhead, so it does not meet the lowest-latency, no-copy requirement that Direct Lake satisfies.
DirectQuery mode, because it sends each report query to the "Warehouse" so freshly committed rows appear immediately and no copy of the data is held inside the model.
Why it is wrong: DirectQuery reflects new rows and avoids duplication, but it answers from the Warehouse rather than memory, so it cannot deliver the in-memory query speed the reports require.
"Direct Lake" cannot be used because the database has too many rows for memory, so the team should pick import mode and schedule frequent refreshes to approximate the freshness they want.
Why it is wrong: The blocker is the source type, not row count, and import with frequent refresh still serves cached data, so this both misdiagnoses the limit and fails the near real-time need.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.