DP-700 Microsoft Fabric Data Engineer Guide (2026)

Exam DP-700: Implementing Data Engineering Solutions Using Microsoft Fabric supports the Microsoft Certified: Fabric Data Engineer Associate credential. The official audience profile describes engineers with expertise in data loading patterns, data architectures, and orchestration. Their responsibilities include ingesting and transforming data, securing and managing an analytics solution, and monitoring and optimizing it. Candidates work with analytics engineers, architects, analysts, and administrators, and should manipulate data with SQL, PySpark, and Kusto Query Language (KQL).

That role description matters. DP-700 is not a tour of portal buttons and is not a Spark syntax contest. A production data product has a source boundary, an access model, a full and incremental path, a schema contract, duplicate and late-data rules, a deployment lifecycle, a service-level objective, operational telemetry, a capacity envelope, and a recovery procedure. If one part is missing, a transformation can be mathematically correct and still be an unsafe system.

The PrepKloud five-phase DP-700 roadmap sequences those concerns. This guide explains the architecture decisions behind it and connects them to original practice, active recall, and two substantial portfolio projects.

Current DP-700 domains and weights

The three ranges are equal, so preparation should be close to balanced. Do not interpret that as three isolated weeks of memorization. Consider an incremental customer pipeline. The engineering domain covers source changes, a watermark, transformation, and merge. The management domain covers workspace settings, permissions, orchestration, Git, deployment, labels, and audit. The operations domain covers failed runs, duplicate detection, Spark stages, query behavior, alerts, and capacity. The same pipeline can appear through any of those lenses.

Domain 1: configure a governed Fabric engineering foundation

Start with Microsoft Fabric's organizing layers. OneLake provides a unified logical data lake for the tenant. Workspaces organize items and collaboration, domains organize the estate by business ownership, and capacities supply shared compute. A data engineer must understand how a Lakehouse, Warehouse, Eventhouse, pipeline, Dataflow Gen2, notebook, environment, Eventstream, and monitoring item use those layers.

Workspace configuration includes Spark, domain, OneLake, and Apache Airflow settings in the current guide. For Spark, centralize the approved runtime, libraries, and compute behavior in a reviewed environment and workspace defaults when appropriate. Reproducibility is the goal: the same production notebook should not depend on a library installed manually in one author's session. Also model concurrency against capacity. Ten individually efficient notebooks can still create queueing when all start with pipelines and reports at the same time.

Storage selection should follow workload shape rather than product familiarity. A Lakehouse stores open Delta data in OneLake and supports Spark plus a SQL analytics experience. It fits code-first engineering, mixed files and tables, medallion patterns, and cross-engine access. Fabric Warehouse is a SQL-first relational analytics engine for tables, views, stored procedures, transactions, and governed T-SQL development. Eventhouse is optimized for high-volume, time-oriented, semi-structured, free-text, telemetry, and log analytics with KQL.

Lifecycle management: Git, database projects, and deployment pipelines

The current blueprint explicitly includes version control, database projects, and deployment pipelines. Fabric Git integration connects supported workspace items to a repository so teams can branch, review, synchronize, and recover definitions. Item support changes over time, so verify current documentation rather than assuming every object behaves like a text file. Never commit source credentials or production-specific secrets simply to make a definition portable.

Fabric database projects bring declarative source control to supported Warehouse schema. Tables, views, procedures, and other supported objects can be built and validated as code. That reduces manual production DDL, but a schema deployment still needs compatibility testing. Removing a column used by a notebook or dashboard is not safe merely because the project builds.

Deployment pipelines promote supported content through isolated development, test, and production stages. Configure environment-specific bindings or rules where supported, validate data sources and identities in test, and record the deployed commit. Item rollback does not automatically restore data state. A previous notebook definition may be incompatible with a newer Delta schema, watermark, Eventstream destination, or Structured Streaming checkpoint. Treat definition, schema, data, and state rollback as related but separate procedures.

Security, OneLake access, masking, governance, and audit

Fabric security is layered. Workspace roles can grant broad collaboration and item capabilities. Item permissions narrow access to a particular artifact. SQL, KQL, semantic, and OneLake data controls govern paths within or below items. The correct design starts from personas and actual access paths. A gold consumer normally does not need Contributor merely to read approved tables.

OneLake security roles can provide granular access to supported data, including folder, table, row, or column scopes according to current capability. Shortcut security also involves the source and shortcut path, so test both. Run positive and negative checks as each actual identity through Spark, SQL endpoint, KQL, OneLake, shortcut, and downstream tools. A policy that works in one path but leaves another direct route open is not complete.

Dynamic data masking changes displayed Warehouse query results for users without unmask permission; it does not encrypt or alter stored values. Row-, column-, and object-level controls enforce different boundaries. Sensitivity labels classify data and can protect supported downstream use, but a label does not revoke a workspace role. Endorsement communicates that a product is promoted or certified. Audit logs support investigation and review. These controls complement least privilege, lineage, ownership, retention, and access review.

Domain 2: design restartable batch and incremental data products

The loading-pattern objectives cover full and incremental data loads, preparing data for dimensional models, and streaming patterns. Begin with the source's change semantics. Does it expose a reliable modified timestamp, monotonically increasing ID, database change data capture, deletion marker, snapshot, or file boundary? The answer determines whether a watermark, merge, snapshot comparison, or mirroring pattern is defensible.

A safe watermark follows a commit sequence: read changes after the last committed boundary; preserve the run's source boundary; validate and transform; merge idempotently into the target; verify the durable commit; then store the new watermark. Advancing the watermark before the target succeeds can skip records after failure. Blindly appending every retry produces duplicates. Per-source control state is usually safer than one global timestamp for unrelated entities.

Medallion architecture clarifies responsibilities. Bronze preserves raw source evidence and ingestion metadata such as file name, source version, checksum, run ID, and arrival time. Silver validates schemas, standardizes types, deduplicates, applies late and deletion logic, conforms references, and quarantines bad records with reason codes. Gold publishes facts, dimensions, aggregates, and service-level metrics. The labels are not magic: each layer still needs a contract, retention rule, owner, security policy, and replay plan.

Dataflow Gen2 is suited to low-code Power Query transformations, profiling, joins, types, and supported destinations. Pipelines orchestrate movement, dependencies, parameters, expressions, schedules, events, retries, and multiple activities. Notebooks provide code-first PySpark for reusable, scalable logic. A common architecture uses a pipeline to invoke both a Dataflow Gen2 and parameterized notebooks. Tool selection should follow author skills, complexity, testing, performance, and operations—not an artificial rule that only one Fabric item may be used.

Data quality is part of engineering, not a dashboard cleanup task. Define duplicate keys and version precedence. Decide how missing dimensions map to unknown members or quarantine. Preserve invalid records with non-sensitive diagnostic metadata. Process valid late records according to event or business effective dates. Reconcile row counts and financial measures across boundaries. Publish quality and freshness as first-class operational tables so alerts reflect the data consumers receive.

Shortcuts, mirroring, and avoiding unnecessary copies

A OneLake shortcut is a logical link to selected data in another OneLake location or supported external storage. It gives a local namespace without another managed copy and lets producer teams retain ownership. That can reduce storage and synchronization, but it transfers dependencies: source availability, permissions, external network latency, format compatibility, and changes remain important.

Mirroring works at database or catalog level. For supported proprietary operational databases, it can continuously replicate changes into OneLake in Delta format. For open-format catalogs, the underlying mechanism can use shortcuts. A useful distinction is intent: use a shortcut when selected supported data should remain in place; use mirroring when an external database or catalog should appear in Fabric as a managed unit and stay synchronized according to source capability. Pipelines remain appropriate when custom movement, transformation, schedule, or control is required.

Streaming data engineering: Eventstream, Structured Streaming, and Eventhouse

Streaming begins with semantics, not a connector. Define event ID, schema version, event time, ingestion time, allowed lateness, duplicate behavior, malformed-record policy, and state recovery. A five-minute business window based on device event time can differ materially from a five-minute window based on when Fabric received the event.

Fabric Eventstream is a low-code path for streaming sources, field management, timestamp normalization, filtering, enrichment, grouping, window aggregation, derived streams, and routing to destinations such as Eventhouse or Lakehouse. Its Data insights and runtime logs expose incoming and outgoing events, bytes, backlog, errors, conversion or deserialization failures, and watermark delay depending on the node. Those metrics are essential when destination counts do not match source counts.

Spark Structured Streaming is the code-first alternative when transformations, libraries, or state require PySpark control. Use an explicit schema and a stable, unique checkpoint location for each query. Align event-time watermarking and deduplication with the contract. Design the Delta sink for replay safety. Deleting a checkpoint to make an error disappear loses recovery state and can cause unexpected replay or gaps.

Eventhouse stores and analyzes streaming, time-series, log, semi-structured, and free-text data. It organizes data for fast recent queries and uses KQL. Efficient KQL usually begins with a selective datetime predicate and other filters, projects only needed columns, and then summarizes with bin(). Avoid converting timestamps to strings before filtering, expanding large dynamic fields unnecessarily, or joining entire retention periods when only the last hour matters.

Native Eventhouse tables versus OneLake shortcut query acceleration

Historical Delta data can remain in OneLake and appear in a KQL database through a shortcut. Standard shortcut queries use external_table() and can be slower than native Eventhouse data because of network calls, lack of native indexing, and storage behavior. Query acceleration caches and indexes a selected hot period to approach native performance without a separate ingestion pipeline.

Acceleration is not free caching. The selected hot period consumes Eventhouse SSD storage, and synchronization/indexing use compute. Region and compliance constraints also matter. Accelerated external tables do not support every native-table feature. Benchmark the standard shortcut first, measure the time ranges users query, then accelerate only the history that needs interactive performance. A twelve-month hot period for a dashboard that reads seven days is wasteful.

Domain 3: monitor the data product, not only the scheduler

Monitoring should answer four questions: Is the product current? Is it correct? Is it secure? Is it operating inside performance and capacity objectives? A green scheduler start cannot answer any of them alone. Track the latest committed gold watermark, quality score, reconciliation, rejected rows, pipeline and Dataflow state, notebook result, Eventstream backlog and watermark, Eventhouse ingestion, query latency, and capacity.

Monitoring hub provides centralized run visibility. Workspace monitoring stores supported item logs in a monitoring Eventhouse and KQL database. Pipeline monitoring shows run and activity detail; Dataflow Gen2 provides refresh evidence; notebooks and Spark UI expose stages, tasks, shuffle, skew, spill, and executors. Eventstream offers Data insights and runtime logs. Eventhouse monitoring and query insights expose ingestion and query behavior. The Capacity Metrics app explains shared utilization, throttling, and interactive versus background pressure.

A disciplined incident workflow starts with impact and the last trusted data boundary. Find the failed item and run. Preserve parameters, error text, source boundary, deployed version, and identity. Determine whether the failure originates in source connectivity, authentication, schema, data quality, activity, Spark, Eventstream, Eventhouse, SQL, shortcut, or capacity. Recover with an idempotent rerun, then validate downstream completeness. A later green run is not proof that missing data was backfilled correctly.

Optimize from evidence: Delta, Spark, pipelines, SQL, KQL, and capacity

Lakehouse optimization often begins with files. Thousands of tiny Delta files increase listing, scheduling, and metadata overhead. Compact files based on measured access. Partitioning can prune scans but high-cardinality or tiny partitions can make the layout worse. Evaluate V-Order when read acceleration justifies write overhead. Keep statistics and maintenance aligned with the current engine guidance.

For Spark, inspect the execution plan and UI. A join where one key owns most rows creates skew: adding executors does not split the single oversized task automatically. Consider broadcast only when the small side safely fits, repartition from actual keys, reduce data before shuffle, and avoid collecting large frames to the driver. Cache only reused data that fits a clear memory plan.

For pipelines, separate queue time from source read, transfer, and sink write. Review parallelism, integration path, throttling, staging, source and destination limits, retries, and file sizes. For Warehouse, use sargable predicates, narrow projections, appropriate joins, and query plan/query insights evidence. For KQL, filter early and use native types. For Eventhouse, tune retention and cache from query behavior. For query acceleration, select the smallest hot period that meets latency.

Capacity is shared. If pipelines, Dataflow Gen2 refreshes, Spark notebooks, Eventstream work, and executive queries all peak at 09:00, each item can be efficient alone while the capacity still queues and throttles. Use Capacity Metrics to attribute demand. Stagger or smooth background work, limit concurrency, remove inefficient retries and scans, and then resize only if optimized demand still violates service objectives. Cost control is architecture, not just a billing report.

Two portfolio projects that cover the complete blueprint

The first DP-700 project is a governed medallion Fabric lakehouse pipeline. Build metadata-driven full and incremental ingestion with pipelines, Dataflow Gen2, and parameterized PySpark. Preserve bronze evidence, create silver validation and quarantine, merge late corrections, and publish gold facts and dimensions. Add a OneLake shortcut, Git, deployment stages, OneLake security, labels, endorsement, audit review, workspace monitoring, Spark UI analysis, quality and freshness alerts, capacity smoothing, cost evidence, and cleanup.

The second project is a real-time event engineering and operations platform. Stream synthetic vehicle telemetry through Eventstream, normalize and filter it, create five-minute windows, route trusted and rejected streams, and query recent data in Eventhouse with KQL. Keep twelve months of Delta history in OneLake, compare a standard shortcut with query acceleration, and implement a checkpointed Structured Streaming path. Inject malformed schemas, late events, destination failures, security denial, query regressions, and capacity pressure. The project is complete only when one incident can be traced from source through dashboard impact and recovered under a runbook.

Use only synthetic or public data. A portfolio should demonstrate contracts, transformations, security, deployment, tests, operations, and decisions without exposing customer data, employer architecture, tenant identifiers, credentials, or screenshots of private workspaces.

A practical twelve-week DP-700 study plan

1. Weeks 1–2: map Fabric architecture, OneLake, capacities, domains, workspaces, environments, and Lakehouse/Warehouse/Eventhouse decisions. Build least-privilege persona and data-contract matrices.
2. Weeks 3–4: implement full and incremental pipeline ingestion, parameters, expressions, triggers, Dataflow Gen2 shaping, watermarks, retries, and monitoring.
3. Week 5: build PySpark bronze-silver-gold transformations with validation, quarantine, deduplication, late-data merge, dimensions, reconciliation, and file measurements.
4. Weeks 6–7: build Eventstream transformations, Eventhouse/KQL queries, dashboards, windowing, a OneLake historical shortcut, query acceleration experiment, and Structured Streaming checkpoint test.
5. Weeks 8–9: configure Git, database projects where applicable, deployment pipelines, item/data access, OneLake security, masking, labels, endorsement, lineage, and audit review.
6. Weeks 10–11: diagnose injected pipeline, Dataflow, notebook, Spark, Eventstream, Eventhouse, T-SQL, shortcut, and capacity failures. Tune from before-and-after evidence.
7. Week 12: complete mixed original practice, flashcard retrieval, both project reports, weak-objective review, and a final check of the official guide.

Use 25 original DP-700 practice questions to test constraint reasoning rather than memorize positions. Use 25 DP-700 flashcards for active recall. For every incorrect answer, open the official reference and explain why each distractor fails the stated latency, security, quality, lifecycle, or operations requirement.

Preparation mistakes to avoid

• Learning tools without data contracts. A pipeline cannot invent grain, keys, quality, or late-data rules.
• Advancing watermarks too early. Commit the target before advancing durable control state.
• Blind append on retries. Use stable keys and idempotent merges where the requirement needs current state.
• Calling every layer medallion. Bronze, silver, and gold need distinct contracts, access, and validation.
• Copying data that could remain governed in place. Evaluate shortcuts and mirroring before building another synchronization flow.
• Treating labels as permissions. Labels classify; workspace, item, SQL/KQL, and OneLake controls authorize.
• Assuming Git covers every item and state. Verify current support and plan schema/checkpoint/data migration separately.
• Deleting streaming checkpoints during incidents. Preserve state and replay evidence.
• Scaling before diagnosis. Skew, small files, non-sargable predicates, broad KQL scans, or shared peaks can make larger capacity an expensive delay.
• Alerting only on failed jobs. A successful job can publish stale, incomplete, or low-quality data.

Official Microsoft references

• Microsoft Learn: Study guide for Exam DP-700
• Data engineering in Microsoft Fabric
• What is OneLake?
• Implement medallion lakehouse architecture in Fabric
• OneLake shortcuts
• Fabric mirroring overview
• Data warehousing in Microsoft Fabric
• Data Factory in Microsoft Fabric
• Dataflow Gen2 overview
• Apache Spark best practices in Fabric
• Fabric Eventstreams overview
• Eventhouse overview
• Query acceleration for OneLake shortcuts
• OneLake security access-control model
• Fabric CI/CD overview
• Fabric workspace monitoring
• Microsoft Fabric Capacity Metrics app

Continue across PrepKloud

• DP-700 five-phase roadmap
• DP-700 original practice questions
• DP-700 flashcards
• DP-700 portfolio projects
• Data engineering jobs
• Technology career paths
• All certification roadmaps
• All PrepKloud guides
• PrepKloud editorial policy

Frequently asked questions