DP-600 common mistakes
DP-600 · Understand the traps and how to avoid them.
Designs a solution around Direct Lake, deployment pipelines, or a multi-GB semantic model while leaving the workspace on Pro/Shared capacity, and never checks the capacity requirement.
Candidates study the feature list for each item in isolation (model mode, ALM tooling) and treat the hosting capacity as an afterthought, because in smaller environments 'it just worked' when everything was in one Pro workspace.
What to do instead
Make capacity selection the first decision, not the last. Enumerate the features the scenario requires (Direct Lake, large semantic models, XMLA write, Fabric notebooks/pipelines) and map each to what it demands of the workspace; note that Pro workspaces impose size limits on semantic models and that Direct Lake requires a Fabric capacity. If the scenario says 'we only have Pro', rule out the Fabric-only options before scoring them.
Treats Git integration and deployment pipelines as competing alternatives and picks one, so the candidate cannot describe how a change travels from a developer workspace to test and production with environment-specific values.
Both are presented as ALM features in Fabric, so candidates memorise two definitions instead of learning how the features compose; they also confuse a Git branch with a pipeline stage.
What to do instead
Learn the division of labour: Git integration connects a workspace to a branch for per-item versioning and collaboration, while deployment pipelines promote entire workspaces across stages and apply rules (data source rules, parameter rules) to swap environment-specific values. In a combined answer, source control happens via Git and environment promotion happens via pipelines.
Answers a 'consolidate data from ADLS Gen2/S3/another workspace without duplicating storage or waiting for a refresh' scenario with a Copy activity or Dataflow Gen2.
Shortcuts are a OneLake-specific concept with no equivalent in the classic Azure data stack, so candidates fall back to the ingestion pattern they already know and default every source-integration question to copy.
What to do instead
Memorise the shortcut decision rule: a shortcut is a zero-copy pointer to data that already exists (ADLS Gen2, S3, other lakehouses/warehouses, Dataverse) and only makes data available, it does not transform it. Choose copy activities, pipelines, or dataflows when you need transformation, format conversion to Delta, schema enforcement, or scheduling. Also recall that shortcuts can point across workspaces, which is the standard answer for 'share without copying'.
Plans to run INSERT/UPDATE/DELETE or MERGE statements against the SQL analytics endpoint of a lakehouse to clean up or correct data.
The SQL analytics endpoint accepts T-SQL and exposes tables and views exactly like a database, so candidates assume it is a full T-SQL surface and treat it as a warehouse.
What to do instead
Anchor the rule: the lakehouse SQL analytics endpoint is read-only over Delta tables; it exposes data and lets you create views and manage permissions, but data changes go through Spark notebooks, dataflows, or pipelines writing Delta. When the scenario demands full T-SQL DML, stored procedures, and multi-table transactions, that is the trigger to choose a warehouse rather than a lakehouse.
Writes Delta tables repeatedly from notebooks and then blames capacity size when queries get slow, never proposing compaction, V-Order, or a partitioning strategy.
Small-file accumulation and layout problems are invisible in the notebook authoring experience, so nothing in the workflow prompts the candidate to think about table maintenance; optimisation questions get answered with 'scale up the SKU'.
What to do instead
Attach a maintenance answer to every notebook-write scenario: OPTIMIZE to compact small files, V-Order to improve read performance for the engine, partitioning aligned to how the data is filtered, and a scheduled maintenance step in the pipeline. If a question mentions degraded query performance after incremental loads, suspect file proliferation before capacity.
Selects Direct Lake by default on the grounds that it 'combines import performance with DirectQuery freshness', without verifying that the sources are Delta tables in OneLake and that the model will actually stay in Direct Lake mode.
Direct Lake is heavily marketed and candidates memorise the headline benefit but not the preconditions or fallback behaviour, so they answer freshness questions with Direct Lake even when the scenario hints at a source that will force a fallback.
What to do instead
Learn the preconditions and the fallback triggers: Direct Lake reads Delta tables in OneLake in a Fabric workspace; user queries fall back to DirectQuery when the model cannot be held in memory or when the model uses features incompatible with Direct Lake. For small data with a batch refresh window, Import is usually the safer, more defensible answer; reserve Direct Lake for large OneLake Delta sources that need near-real-time freshness.
Builds a snowflake or one very wide table and sets relationships to bi-directional cross-filter 'so the filters flow', rather than modelling a proper star schema.
Bi-directional filtering silences the symptom (filters 'not working', ambiguity errors avoided by luck) faster than restructuring the model, and candidates are wary of a question that seems to demand more modelling work than necessary.
What to do instead
Default to dimensions plus a fact table with single-direction one-to-many relationships from dimension to fact; restrict bi-directional to deliberate many-to-many bridge designs and be able to say why. Resolve genuine ambiguity with correct granularity and keys, and use inactive relationships plus USERELATIONSHIP for role-playing dimensions such as order date versus ship date.
Writes a calculated column containing SUM(...) to show a total, or wraps the fact table in FILTER(ALL(Fact), ...) inside a measure, instead of using CALCULATE with filter modifiers.
Spreadsheet and table habits carry over, and row context versus filter context is the most common conceptual gap; a calculated column visibly produces the right-looking numbers on small samples.
What to do instead
Separate the two: static row-level values are calculated columns, aggregations that must respond to slicers are measures. Use CALCULATE with boolean filters or REMOVEFILTERS/KEEPFILTERS rather than iterating the fact table, use DIVIDE for safe division, and confirm the result set in DAX Query View before committing to a design.
Ships a model where time intelligence measures return blanks and proposes adding missing dates into the fact table or writing offset logic by hand to compensate.
The requirement for a contiguous, marked date table is a modelling prerequisite rather than a DAX rule, so no error points at the date table; the failure appears only as silent blanks in the report.
What to do instead
Always create a dedicated date dimension with exactly one row per calendar date, no gaps, of Date data type, mark it as the date table, and relate it to each fact. Then use the built-in time intelligence functions (TOTALYTD, SAMEPERIODLASTYEAR, DATEADD); if measures still return blanks, check for gaps, duplicate dates, or a relationship that is missing or inactive.
When asked to verify a measure or hand back a result set for review, creates a throwaway report page or exports to Excel instead of querying the semantic model with DAX.
Candidates prepare for this exam as report builders, so their instinct is to prove a number visually; DAX Query View and EVALUATE-based querying are newer surfaces that get skipped during study.
What to do instead
Use DAX Query View to run EVALUATE queries directly against the model, preview and edit measures in place, and inspect results without building visuals. Practise the typical tasks: return a table of values for a measure across a dimension, define and test a new measure with the DEFINE syntax, and use INFO functions to inspect model metadata.
Assumes natural-language Q&A and Copilot will answer business questions over any model, including a raw bronze-layer model with technical column names such as CUST_ID or AMT1.
Copilot and Q&A are presented as turnkey features, so candidates treat them as purely a licensing switch and overlook that answer quality is a function of model quality.
What to do instead
Link NL querying to model hygiene: readable table and column names, hidden key and technical columns, synonyms, a clean star schema with relationships already defined, and a filled-in linguistic schema. In a scenario where Q&A gives poor results, propose model cleanup and synonyms before proposing a different tool, and remember Copilot also depends on the feature being enabled in the right capacity and tenant.