Table of Contents

DP-700 — Complete Detailed Notes

Every officially listed skill area, explained in depth
Skills-measured version referenced: April 20, 2026 (next refresh July 21, 2026)

DOMAIN 1 — Implement and Manage an Analytics Solution (30–35%)

1. Configuring workspace settings
Every Fabric workspace has five categories of settings you’re expected to know, and the
exam likes to test which setting controls which behavior.
Fabric workspace settings (general): license type, workspace identity (a managed
identity the workspace itself can use to authenticate to other resources without you
managing a service principal), and OneLake-related storage settings.
Spark workspace settings: this is where you configure the default Spark pool size
(Starter Pool vs. a custom pool), the Spark runtime version, and the environment — a
reusable bundle of libraries and configuration that notebooks can attach to. The setting
most directly tested is high-concurrency mode: when enabled, multiple notebooks (or
notebook + pipeline sessions) can share a single Spark session instead of spinning up a new
one each time, which cuts startup latency and cost. If a scenario complains about repeated
slow Spark session startup across many small notebooks, high concurrency is almost
always the answer.
Domain workspace settings: “domains” in Fabric are an admin-level grouping of multiple
workspaces (e.g., all of “Finance” or all of “Marketing”) used to apply policy and organize
governance at scale. Don’t confuse this with a data domain or a business domain in a
general sense — it’s a specific Fabric admin construct.
OneLake workspace settings: control things like OneLake data access policies and
whether certain integrations are exposed at the workspace level.
Data workflow settings: govern Data Factory-style workflow items inside the workspace.

2. Lifecycle management
This is about treating your Fabric solution like software — versioned, tested, and promoted
through environments in a controlled way.
Version control (Git integration): A workspace can be connected to a branch in Azure
DevOps or GitHub. Once connected, changes to supported items sync as commits, meaning
you get commit history, branching, and pull-request-style review for Fabric items — not
just for code, but for the Fabric items themselves (pipelines, notebooks, semantic models,
etc.).
Database projects: this is schema-as-code specifically for Warehouse objects. Instead of
clicking through the UI to change a table’s schema, you define DDL in a database project,
check it into source control, review it like any other code change, and deploy it in a
controlled way. This is the answer whenever a scenario says schema changes need to be
“tracked” or “code-reviewed.”
Deployment pipelines: this is how you promote Fabric items across environments —
typically Dev → Test → Prod, each stage being its own workspace. The critical detail:
deployment rules let you parameterize what changes automatically during promotion.
The classic example is a notebook’s default Lakehouse connection — in Dev it points at the
Dev Lakehouse, and a deployment rule automatically repoints it at the Prod Lakehouse the
moment it’s promoted, without you manually editing anything.

3. Security and governance

This whole section rewards precision — the exam frequently gives you a scenario and
expects you to pick the exact right layer of control, not just “some kind of security.”
• Workspace-level access control: roles (Admin, Member, Contributor, Viewer) that
apply broadly to everything inside a workspace.
• Item-level access control: grants access to one specific item (say, a single
Lakehouse or report) without granting broader workspace membership — used
when you want to share one thing externally or with a team that shouldn’t see
everything else.
• Row-level security (RLS): restricts which rows of a table a given user can see.
Implemented via T-SQL security policies (CREATE SECURITY POLICY ... ADD
FILTER PREDICATE) typically at the Warehouse or SQL analytics endpoint.
• Column-level security (CLS): restricts which columns are visible — implemented
with GRANT/DENY on specific columns.
• Object-level security (OLS): restricts access to an entire table or view, rather than
filtering rows/columns within it.
• File-level security: newer, folder/file-level ACL-style restriction directly at the
OneLake storage layer, distinct from table-level controls.
• Dynamic data masking (DDM): doesn’t hide the row or restrict querying — it
obscures the value in a sensitive column for users without unmask permission (e.g.,
showing XXX-XX-1234 instead of a full SSN), while the underlying data stays intact
and the row remains fully visible/queryable otherwise.
• Sensitivity labels: Microsoft Purview classification labels (Public, Confidential,
Highly Confidential, etc.) applied to Fabric items for compliance/governance
 tracking. This is a classification tool, not an access-enforcement tool — don’t confuse
it with RLS/CLS.
• Endorsement: “Promoted” and “Certified” badges applied to items to signal trust
and quality across the organization — a discoverability/trust signal, not a security
control at all.
⭐ A subtle but exam-relevant detail: the SQL analytics endpoint can run in User Identity
mode (each querying user’s own permissions are enforced — so RLS/CLS actually apply
per person) or Delegated Identity mode (a single shared identity handles all queries,
which can bypass that per-user enforcement). If a scenario is testing whether row-level
security is genuinely being respected for each individual user, the answer often comes
down to which identity mode is configured.

4. Orchestrating processes
Pipeline vs. notebook is a recurring decision point. A pipeline is the orchestrator — it
doesn’t do heavy transformation logic itself, but it chains together activities: Copy Activity,
Notebook activity, Stored Procedure activity, Lookup, ForEach, If Condition, Switch. A
notebook is where the actual transformation code lives (PySpark, Spark SQL). The very
common pattern tested is: pipeline orchestrates and calls a notebook activity, passing a
parameter into it (e.g., a file date or batch ID) via the pipeline’s expression language.
Triggers come in two flavors: schedule-based (cron-like, runs at fixed times) and event-
based (fires in reaction to something happening, most commonly a new file arriving in
connected storage). If a scenario says “must start the moment a file lands,” that’s an event-
based trigger, not a schedule.
Parameters and dynamic expressions: pipelines use an expression syntax like
@pipeline().[Link] to pass values between activities dynamically;
notebooks can declare a parameters cell that a calling pipeline populates at runtime. Being
able to recognize this pattern — pipeline parameter flowing into a notebook parameter —
comes up in scenario questions about reusable, parameterized pipelines.

DOMAIN 2 — Ingest and Transform Data (30–35%)

1. Designing loading patterns
Full load replaces the entire target dataset every run — simple to reason about, but
increasingly expensive as data volume grows. Incremental load only processes new or
changed records, typically tracked via a watermark column (a timestamp or an
incrementing ID) or true CDC (Change Data Capture) from the source. As data volumes
grow, incremental is almost always the “better” answer in a scenario unless the
requirement explicitly wants simplicity over efficiency.
Medallion architecture structures data into three layers: - Bronze: raw, as-ingested, no
transformation — the goal is fast, cheap, faithful landing of source data, usually via a
Pipeline Copy Activity. - Silver: cleansed, deduplicated, standardized, validated — usually
built with a Notebook because the logic tends to be too complex for pure low-code tools. -
Gold: aggregated, denormalized/dimensional, business-ready — shaped for direct BI
consumption, often a star schema.
Dimensional modeling for the Gold layer means fact tables (numeric measures, e.g., sales
amount) surrounded by dimension tables (descriptive context, e.g., customer, product,
date). Slowly Changing Dimensions (SCD): Type 1 overwrites the old value with no
history kept; Type 2 inserts a new row with effective-date columns, preserving full history.
If a scenario needs to preserve what a dimension attribute used to be, that’s Type 2; if only
the current value matters, Type 1.

2. Lakehouse, Warehouse, Shortcuts, Mirroring — architecture choices

Concept What it is When it’s the right answer
Lakehouse Files + managed Delta Spark/PySpark workloads,
tables, Spark-native, has a semi-structured/unstructur
read-only SQL analytics ed data, ML data prep
endpoint
Warehouse Full read/write T-SQL Traditional BI/DW
engine, Delta-native under workloads, stored
the hood procedures, MERGE-based
upserts
Shortcut Virtual pointer to data in Cross-cloud/cross-
OneLake, ADLS Gen2, S3, workspace access while
GCS, or another Fabric item avoiding duplication and
— zero data movement egress cost
Mirroring Continuous, near-real-time Keeping an operational DB
replicated copy of an (Azure SQL DB, Cosmos DB,
external database into Snowflake) queryable in
OneLake, no pipeline code Fabric with zero dev effort
Query acceleration (for Caches shortcut-referenced Repeated queries against
shortcuts) data for faster repeated KQL the same shortcut-based
queries in Real-Time data where latency matters
Intelligence

Table cloning (Warehouse-specific): a metadata-only, near-instant copy of a table — no

physical data duplication until the clone diverges from its source. Perfect for spinning up
dev/test copies of huge tables cheaply.

3. Choosing an ingestion/transformation tool

Tool Code level Best for
Pipeline (Copy Activity) No-code Bulk copy into Bronze,
 Tool Code level Best for
broad connector support,
orchestration
Copy Job No-code, wizard-based Simple recurring copy
without building a full
pipeline
Dataflow Gen2 Low-code (Power Query/M) Business-user-friendly
transforms; loses efficiency
at high complexity/scale
Notebook Code-first Complex custom logic,
(PySpark/Spark SQL) large-scale transforms, ML
prep
T-SQL (in Warehouse) Code-first Set-based transforms,
MERGE upserts, stored
procedures
KQL Code-first Streaming/time-series/log
analytics in Eventhouse

Transformation techniques worth knowing by name: MERGE INTO for Delta upserts
(both T-SQL and PySpark support it), window functions like ROW_NUMBER() OVER
(PARTITION BY ... ORDER BY ...) for deduplication and ranking, denormalization
for Gold-layer prep, and handling of duplicates/missing values/late-arriving data (e.g., late-
arriving dimension rows getting an inferred/placeholder member until the real dimension
record catches up).

4. Real-Time Intelligence — streaming ingestion and transformation

This domain area is worth extra attention because it’s conceptually different from
everything else on the exam.
Eventstream: a no-code hub for ingesting streaming sources (Event Hubs, IoT Hub, Kafka,
CDC feeds) and routing them — simultaneously, if needed — to multiple destinations: a
Lakehouse table, an Eventhouse/KQL database, or Fabric Activator. It can also apply light
in-flight transformations (filtering, simple aggregation) before routing.
Eventhouse: a container that holds one or more KQL databases, purpose-built for high-
volume, time-series/log-style data where recent-time queries matter more than lifetime
aggregates.
KQL (Kusto Query Language) essentials to recognize: - where filters rows. - extend adds
a computed column. - project selects specific columns. - summarize aggregates — the
KQL equivalent of GROUP BY (e.g., T | summarize count() by Category). - bin()
buckets time into windows for windowed aggregation — e.g., T | summarize
avg(Value) by bin(Timestamp, 5m) groups data into five-minute buckets.
Choosing the right streaming engine: no-code routing/simple filtering → Eventstream.
Complex custom logic (intricate joins, custom windowing) that Eventstream’s UI can’t
express → Spark Structured Streaming inside a notebook. Automated alerting/action on
a condition crossing a threshold → Fabric Activator (also called Reflex).

DOMAIN 3 — Monitor and Optimize an Analytics Solution (30–35%)

1. Monitoring tools — know exactly which tool answers which question
Tool Answers the question…
Monitoring Hub “Did my pipeline/notebook/dataflow run,
and what was the status?” (central run-
history view across item types)
Capacity Metrics App “How much of my capacity’s CU budget am
I using, and am I being throttled?”
Query Insights “Which Warehouse queries have been slow
historically, over time?” (system-view-
based, historical)
DMVs (Dynamic Management Views) “What’s executing against the Warehouse
right now?” (live, real-time)
Spark UI “Why exactly is my Spark job slow?”
(stage/task/shuffle/executor-level detail)
Workspace Monitoring Custom, KQL-queryable operational logs
spanning multiple item types in a
workspace
Fabric Activator (Reflex) Automated alerting/action when a defined
condition or threshold is met

The Query Insights vs. DMVs distinction (historical vs. live) and the Capacity Metrics App
vs. Monitoring Hub distinction (capacity/throttling vs. run status) are both directly and
frequently tested.

2. Capacity management concepts

Fabric capacity has a few specific behaviors worth knowing by name: - Smoothing: Fabric
spreads short bursts of high CU usage over a longer window rather than immediately
throttling, so a brief spike doesn’t necessarily trigger a slowdown. - Throttling: once
sustained usage exceeds what smoothing can absorb, background/interactive operations
start getting delayed or rejected. - Autoscale (and Autoscale Billing for Spark): capacity
— or specifically Spark compute within it — can automatically scale up under load rather
than requiring manual resizing, with billing that reflects the actual scaled usage.
If a scenario describes a short usage spike that self-resolves without visible slowdown,
that’s smoothing at work; if it describes sustained overuse causing delays, that’s throttling.

3. Error resolution by item type

Item Where to look when something breaks
Pipeline Activity run details / error codes in
Monitoring Hub
Dataflow Step-level query diagnostics/error preview
Notebook Spark Application detail, driver/executor
logs (Spark UI)
Eventhouse/Eventstream Data connection status, ingestion failure
logs
T-SQL/Warehouse Standard SQL error messages, execution
plan analysis
Shortcut Usually a credential expiry, connectivity, or
permission issue at the source system

4. Performance optimization — the densest, most precisely tested part of the

exam
OPTIMIZE: compacts many small Delta files into fewer, larger ones, which speeds up
subsequent reads. The classic trigger scenario: a table has accumulated thousands of tiny
files after months of incremental writes, and reads have gotten slow.
VACUUM: removes old, dereferenced Delta file versions to reclaim storage. The important
nuance: vacuuming with too short a retention window can break Direct Lake
reports/semantic models that still needed to reference an older file version — so retention
settings matter, not just “run vacuum whenever.”
V-Order: Fabric’s write-time optimization (sorting and encoding Parquet files) that makes
reads faster, especially for Direct Lake and Power BI. Its default behavior differs by engine,
and this exact fact is a favorite trap: - In Spark, V-Order is disabled by default in new
workspaces — you must explicitly enable it if you want the read-speed benefit. - In the
Warehouse, V-Order is enabled by default, and critically, once disabled it cannot be re-
enabled for that Warehouse.
Data Clustering: a related optimization concept — physically co-locating related data to
improve query pruning efficiency, conceptually adjacent to V-Order but distinct from it.
Broadcast joins: when a Spark job joins a very large table with a small one, the default
behavior can force an expensive shuffle across the cluster; broadcasting the small table to
every node avoids that shuffle and speeds the join up dramatically.
Pipeline/query-level optimization: parallel copy, increasing Data Integration Units
(DIUs) for a Copy Activity, filter pushdown, and avoiding SELECT * to reduce unnecessary
data transfer.
5. Semantic models and Direct Lake — a quick note since it bridges Domains 2
and 3
Fabric’s semantic models can run in Import mode (data physically copied into the model,
fastest queries but needs refreshing), DirectQuery mode (always queries the live source,
no duplication, but slower), or Direct Lake mode (a Fabric-specific hybrid — reads Delta
Parquet files directly from OneLake without a traditional import step or full DirectQuery
overhead, combining speed with freshness). Direct Lake is the one the exam cares about
most, because its performance depends directly on the health of the underlying Delta files
— which is exactly why OPTIMIZE, VACUUM retention, and V-Order all matter so much: they
directly determine how well Direct Lake performs.

⭐ RAPID-FIRE FACTS MOST LIKELY TO APPEAR AS TRAPS

• OneLake is one per tenant, not one per workspace.
• Lakehouse SQL analytics endpoint is read-only — no INSERT/UPDATE/MERGE
through it.
• Shortcut = no data movement. Mirroring = continuous copy, but zero pipeline code.
• Table cloning is metadata-only — near-instant, no immediate storage cost.
• Dynamic data masking hides values; RLS hides entire rows. Sensitivity labels classify
but don’t enforce access.
• User Identity mode enforces per-user permissions on the SQL endpoint; Delegated
Identity mode uses one shared identity.
• Eventstream = no-code, routes to multiple destinations at once. Spark Structured
Streaming = code-first, for logic Eventstream’s UI can’t express.
• bin() in KQL = time bucketing for windowed aggregation.
• Query Insights = historical Warehouse query analysis. DMVs = live, right-now
monitoring.
• Capacity Metrics App = CU usage/throttling. Monitoring Hub = run status/history.
• OPTIMIZE = compact small files. VACUUM = remove old file versions (watch retention
vs. Direct Lake).
• V-Order: off by default in Spark, on by default in Warehouse, irreversible once
disabled in Warehouse.
• Broadcast join fixes a large-table/small-table shuffle bottleneck in Spark.
• Direct Lake mode’s performance depends directly on Delta file health
(OPTIMIZE/VACUUM/V-Order).

How to use this document in your remaining time

Read it once straight through without stopping to memorize anything. Then go do the
official practice assessment. Whatever you get wrong, come back to exactly that section
here — by now you’ll notice almost everything you miss traces back to one of the
comparison pairs above (Lakehouse vs. Warehouse, shortcut vs. mirroring, Query Insights
vs. DMVs, and so on). The exam is far more about recognizing which of two similar tools fits
a scenario than about recalling obscure syntax, so drilling those pairs until they’re
automatic is the highest-leverage use of your remaining hours.