Home / data-analytics / Microsoft Certified: Fabric Data Engineer Associate (DP-700) / Cheat Sheet
Microsoft Certified: Fabric Data Engineer Associate (DP-700)

DP-700 Cheat Sheet

DP-700 Tests Microsoft Fabric Engineering — Not the Retired DP-203 Synapse Syllabus

DP-203 and the Azure Data Engineer Associate retired on 31 March 2025. Its successor, DP-700, certifies Fabric Data Engineer Associate: lakehouses, warehouses, eventhouses, OneLake security and capacity-aware optimisation.

Check Your Readiness →
Among the harder certs
Avg: Not published by Microsoft
Pass: 750 / 1000
Most candidates understand Microsoft Certified: Fabric Data Engineer Associate (DP-700) concepts — and still fail. This exam tests how you apply knowledge under pressure.

DP-700 Domain Map (replaces DP-203)

Three official domains of equal weight, each split here into its two main skill areas. Questions pair a Fabric item with a requirement such as least-privilege sharing, incremental loads, late-arriving data, small files or slow queries. Expect PySpark, T-SQL and KQL snippets. 100 minutes; question count not published.

  1. 01
    Manage an analytics solution: workspace and lifecycle (30–35% domain) — Spark pools, environments, domains, Git integration, deployment pipelines
  2. 02
    Manage an analytics solution: security and orchestration (same domain) — workspace and item permissions, RLS, CLS, masking, labels, pipelines, notebook DAGs
  3. 03
    Ingest and transform: loading patterns and batch (30–35% domain) — watermarks, MERGE, SCD types, shortcuts, mirroring, Dataflow Gen2, Spark
  4. 04
    Ingest and transform: streaming (same domain) — eventstreams, structured streaming checkpoints and watermarks, KQL update policies, window types
  5. 05
    Monitor and optimize: monitoring and errors (30–35% domain) — Monitoring hub, workspace monitoring, Activator, dependency paths, ingestion failures
  6. 06
    Monitor and optimize: performance (same domain) — OPTIMIZE, V-Order, Z-order, native execution engine, broadcast joins, caching policy

Wrong instinct vs correct approach

Azure SQL Database tables must appear in OneLake in near real time without building pipelines
✕ Wrong instinct

Create a OneLake shortcut to the database tables

✓ Correct approach

Shortcuts point at storage such as OneLake, ADLS Gen2 or S3, not operational databases. Mirroring replicates the database into Delta tables in OneLake in near real time and exposes a read-only SQL analytics endpoint.

An engineer must insert rows into a lakehouse table using T-SQL
✕ Wrong instinct

Run INSERT through the lakehouse SQL analytics endpoint

✓ Correct approach

The lakehouse SQL analytics endpoint is read-only. Write lakehouse tables with Spark notebooks, pipelines or Dataflow Gen2, or land the data in a Fabric Warehouse if T-SQL writes are a hard requirement.

Test-stage tables must reach production after a deployment pipeline promotes the items
✕ Wrong instinct

Expect the deployment pipeline to copy the table data

✓ Correct approach

Deployment pipelines promote item definitions and metadata across two to ten stages, with deployment rules swapping data sources per stage. Rows in the target stage must be loaded separately by pipelines, notebooks or dataflows.

Fact rows arrive before their customer dimension row exists, and no fact may be lost
✕ Wrong instinct

Filter out facts whose dimension key is not found

✓ Correct approach

Insert an inferred member: a placeholder dimension row carrying the business key, so the fact loads with a valid surrogate key. When the real customer row arrives, the placeholder's attributes are updated.

Queries on the last week of data in an eventhouse run slowly
✕ Wrong instinct

Increase the eventhouse retention policy

✓ Correct approach

Retention controls how long data is kept at all. The caching policy controls how much stays in hot cache, which is what speeds queries; extend the hot period to cover the range being queried.

Know these cold

  • ▸ Update the high watermark only after the load succeeds, never before the copy
  • ▸ MERGE upserts — atched rows update, unmatched rows insert; plain INSERT creates duplicates
  • ▸ SCD type 1 overwrites; type 2 adds rows with validity dates, surrogate keys and a current flag
  • ▸ Tumbling windows never overlap; hopping windows overlap; session windows close after an inactivity gap
  • ▸ OPTIMIZE compacts small files; VACUUM removes old files, default retention seven days
  • ▸ Deployment pipelines span 2–10 stages and promote metadata only, never stored rows
  • ▸ Endorsement signals trust and never grants access; certified needs an authorised certifier
  • ▸ Capacity Metrics app explains throttling; Monitoring hub and refresh history explain failed runs
  • ▸ Broadcast small dimension tables to avoid shuffles; try the native execution engine before adding nodes
  • ▸ Shortcuts copy nothing, so source permissions and availability apply to every read

Can you answer these without checking your notes?

In this scenario: "Azure SQL Database tables must appear in OneLake in near real time without building pipelines" — what should you do first?
Shortcuts point at storage such as OneLake, ADLS Gen2 or S3, not operational databases. Mirroring replicates the database into Delta tables in OneLake in near real time and exposes a read-only SQL analytics endpoint.
In this scenario: "An engineer must insert rows into a lakehouse table using T-SQL" — what should you do first?
The lakehouse SQL analytics endpoint is read-only. Write lakehouse tables with Spark notebooks, pipelines or Dataflow Gen2, or land the data in a Fabric Warehouse if T-SQL writes are a hard requirement.
In this scenario: "Test-stage tables must reach production after a deployment pipeline promotes the items" — what should you do first?
Deployment pipelines promote item definitions and metadata across two to ten stages, with deployment rules swapping data sources per stage. Rows in the target stage must be loaded separately by pipelines, notebooks or dataflows.

Common Exam Mistakes — What candidates get wrong

Studying Synapse dedicated pools from old DP-203 material

DP-700 is built on Microsoft Fabric: workspaces, lakehouses, warehouses, eventhouses, Dataflow Gen2, notebooks and OneLake shortcuts. Synapse-era topics such as dedicated SQL pool distribution choices are outside the outline, while workspace roles, deployment pipelines and capacity monitoring are in it.

Granting a workspace role when one item needs sharing

Viewer exposes every item in the workspace, and Contributor can edit items and sees unmasked data. Sharing a single warehouse or lakehouse with item permissions such as Read or ReadData is the least-privilege answer when the scenario names one item.

Treating dynamic data masking as a way to deny access

Masking obscures values in query results; users with UNMASK and administrators still see real data. When a column must be inaccessible, use column-level security, and remember warehouse row-level security does not protect files Spark reads from OneLake with ReadAll.

Running VACUUM to fix slow reads on a Delta table

VACUUM deletes unreferenced files older than the retention threshold, seven days by default, and only saves storage. Slow reads from many small files need OPTIMIZE compaction, with V-Order for read-optimised Parquet and Z-order on frequently filtered columns.

Writing structured streaming queries with no checkpointLocation

The checkpoint records stream progress, so a restarted query resumes instead of reprocessing data, and exactly-once sinks require it. Pair it with withWatermark to bound late events so state for windowed aggregates can be cleaned up.

Resources to help you pass Fabric Data Engineer DP-700 on your first attempt

Check whether your Fabric lakehouse, security and Delta tuning choices are DP-700 ready.