Fabric DP-700 common mistakes
Fabric DP-700 · Understand the traps and how to avoid them.
Building dev, test, and prod artifacts in a single workspace and granting every team member the Admin role 'so nothing blocks them'.
Candidates optimize for getting the lab-style tasks done quickly and never practise the workspace-role model, so they forget that Admin/Member can manage access and that a single workspace makes promotion and rollback impossible to demonstrate.
What to do instead
Create one workspace per environment, promote content with a deployment pipeline, and assign the least-privileged role that works (Admin/Member for owners, Contributor for developers, Viewer for consumers). Reserve item-level permissions and sensitivity labels for data that needs stricter control.
Promoting items through a deployment pipeline without creating deployment rules, so the promoted semantic model or dataflow still points at the dev Lakehouse, SQL endpoint, or connection.
The deployment succeeds and the item looks healthy, so candidates assume the work is finished; they do not realize connections and parameters are not rewritten automatically unless a rule is defined for that stage.
What to do instead
Define deployment rules per stage for data source rules on semantic models and for parameters on pipelines, dataflows, and notebooks. Then validate by running the promoted item against the target environment, not just by checking that deployment reported success.
Defaulting every workload to a Lakehouse (or every workload to a Warehouse) instead of choosing the store from the workload's shape.
Candidates learn one item type well during preparation and reuse it everywhere, missing that T-SQL-heavy relational modelling, streaming/time-series, and file-based Spark processing are served by different Fabric stores.
What to do instead
Decide from requirements: Warehouse for relational T-SQL, multi-table transactions, and BI over structured data; Lakehouse for Spark, Delta engineering, and files/semi-structured data; Eventhouse/KQL database for high-volume streaming and time-series querying; mirrored/shortcut sources when data must stay in place.
Assuming a Direct Lake semantic model always reads Delta tables directly and never falls back, and never checking the model's mode after a refresh.
Direct Lake looks like 'Import but faster', so candidates skip the guardrails; when a table exceeds row/cardinality limits or uses an unsupported schema construct, the model silently falls back to DirectQuery and performance changes without any visible error.
What to do instead
Design Delta tables to stay within Direct Lake guardrails (reasonable column cardinality, supported types, well-defined Delta schema), check the mode reported after refresh, and capture Direct Lake fallback events through monitoring/logging so a fallback is detected rather than discovered as a performance complaint.
Copying data with a pipeline into the Lakehouse when the source is already ADLS Gen2/OneLake, instead of creating a shortcut.
Candidates equate 'ingest' with 'copy', so they pay for duplicate storage and repeated movement, and they miss questions about zero-copy access and where the data actually lives.
What to do instead
Use shortcuts when the requirement is read access to data that should stay in its source system with no duplication. Use Copy activity or notebooks when you must land a transformed, typed, or governed copy (schema mapping, type conversion, deduplication).
Reloading full source tables on every pipeline run instead of implementing an incremental pattern.
Full loads always produce correct results in a small test dataset, so the mistake is invisible until volume and cost matter; candidates then answer the design question with a full-refresh copy or a notebook that overwrites the Delta table.
What to do instead
Carry a watermark (last-modified or a high-water-mark column) and load only new/changed rows, then apply MERGE INTO on the Delta target to upsert. Use Dataflow Gen2 incremental refresh or a Copy activity with a watermark query when no notebook is involved.
Using Dataflow Gen2 with the default (non-staged) settings for large-volume transformations that would be better handled by a notebook or stored procedure.
Dataflows Gen2 are the easiest low-code path, so candidates use them for everything and overlook that transformation runs in the Mashup engine and that staging to a Lakehouse changes how and where the compute happens.
What to do instead
Reserve Dataflows Gen2 for low-code, moderate-volume transformations and connector-heavy ingestion. For large or complex transformations, use notebooks on Spark or T-SQL in the Warehouse; when a dataflow must handle bigger volumes, enable staging so the heavy work is pushed down to the Lakehouse.
Writing streaming or frequently-appended data into Delta tables and never compacting them, leaving thousands of tiny Parquet files.
The write succeeds and queries work on a small demo, so the small-file problem stays hidden; candidates do not connect slow downstream reads and inflated metadata to the append pattern.
What to do instead
Schedule OPTIMIZE (with V-Order as appropriate) on frequently written tables, run VACUUM to remove unreferenced files while respecting the retention period, and for high-rate streaming consider Eventhouse instead of landing raw events in Delta first.
Diagnosing slow or throttled workloads by intuition instead of reading the capacity metrics, then 'fixing' performance by re-running jobs at a different time.
Fabric compute is shared and smoothed over time, so a single slow run does not reveal whether the cause is a background job being throttled, an interactive query being delayed, or genuine query inefficiency.
What to do instead
Use the Capacity Metrics app to identify the item and operation consuming the most capacity units, check for throttling and which stage it affects, and correlate with the Monitoring hub. Then act on the specific consumer (optimize the query/model, move heavy background work, or right-size the capacity) rather than rescheduling blindly.
Tuning a slow notebook by rewriting the transformation code without first opening the Spark UI or the run's details to see where the time went.
Spark failure symptoms look like code problems, but skew, shuffle, small files, and executor sizing appear only in stage and task metrics; candidates who skip that step rewrite the wrong part of the job.
What to do instead
Open the Spark UI from the notebook run or Monitoring hub, identify the slow stage, and check task skew, shuffle read/write, spill, and input file sizes. Then apply the matching fix - repartition or broadcast for skew and joins, compaction for small files, caching for reused DataFrames - and for Warehouse T-SQL use Query Insights instead.