Microsoft DP-700: Ingesting and Transforming Data

Data ingestion and transformation sits at the center of the DP-700 Microsoft Fabric Data Engineer role because nearly every downstream decision depends on how data enters the platform, where it lands, how it is shaped, and what happens when a run fails. The domain is not simply a list of Fabric features. It is a set of engineering choices about movement, state, latency, processing engines, quality, and recoverability.

As of October 1, 2026, DP-700 remains the exam for the Fabric Data Engineer Associate certification. Microsoft has also announced an English-language skills update for October 19, so candidates testing after that date should recheck the official objectives before freezing a study plan. The durable structure is still clear: build and manage analytics solutions, ingest and transform data, and monitor and optimize the result.

The best preparation method is to turn the blueprint into a decision system. When you use DP-700 practice to test that system, ask why a particular ingestion pattern, store, engine, or recovery design fits the scenario. Recognizing a product name is much less useful than being able to explain what changes when the source, latency target, volume, or failure requirement changes.

Start every ingestion problem with source, movement, state, and destination

A reliable way to decompose a DP-700 scenario is to identify four things before choosing a tool. First is the source: database, file, SaaS application, event stream, or existing OneLake asset. Second is movement: must the bytes be copied, can the data be referenced, or can a supported source be mirrored? Third is state: how does the process know what has already been processed? Fourth is destination: where should the result live for the intended consumers and processing engines?

This prevents feature-first reasoning. A pipeline is not automatically right because the question says “ingest.” A shortcut is not automatically right because the organization wants to avoid copying data. A lakehouse is not automatically right because files are involved. The scenario may have relational consumers, strict freshness, KQL-oriented event analysis, or ownership constraints that point elsewhere.

Write these four labels on paper when studying. Then add the transformation engine, quality rules, and recovery behavior. Most complex questions become easier once the architecture is explicit.

Full loads and incremental loads are really state-management problems

A full load can be appropriate for small datasets, replacement patterns, initial ingestion, or sources without reliable change information. The design is simple, but repeated reads and writes become expensive as volume grows. Incremental loading reduces unnecessary movement by processing only new or changed data, but it introduces state that must be managed correctly.

The classic pattern is a watermark. Read the last successful boundary, capture an upper boundary for the current run, extract the eligible changes, transform and write them, validate the result, and only then advance the watermark. The order matters. Advancing state too early can cause data loss after a partial failure. Replaying without idempotent writes can create duplicates.

Late-arriving data complicates the picture further. An event may have occurred yesterday but be ingested today. Filtering on business event time can therefore miss legitimate records. Depending on the source, the design may need a modification marker, overlap window, change tracking, or reconciliation process.

This kind of reasoning is developed further in Fabric data movement and orchestration, where sequencing and recovery are treated as engineering concerns rather than as a collection of pipeline activities.

Choose the analytical store from the workload, not from habit

Fabric gives data engineers several storage and analytical experiences, and DP-700 expects candidates to match the destination to the workload. A lakehouse is a natural fit for lake-oriented engineering and Spark-heavy processing where Delta data and file semantics matter. A warehouse fits strongly relational, T-SQL-centered analytical workloads. Eventhouse and real-time capabilities fit event and time-series workloads where KQL and low-latency exploration are central.

Real architectures can blur these boundaries. SQL consumers may still read lakehouse data. A file-originating workload may ultimately need a warehouse. A streaming source may feed both real-time analysis and curated historical tables. The correct choice therefore depends on the entire path, not the format of the first input.

Practice changing one requirement at a time. If the workload moves from hourly batch to continuous telemetry, does the design change? If the business requires T-SQL-first modeling and governed relational schemas, does the lakehouse remain the best primary store? The lakehouse and warehouse architecture distinction becomes useful when you can explain these trade-offs without relying on a memorized comparison table.

Dataflow Gen2, notebooks, SQL, and KQL overlap without being interchangeable

Several Fabric tools can filter, join, aggregate, derive columns, and reshape data. The exam therefore has room to test operating context rather than raw capability. Dataflow Gen2 is useful for low-code preparation and transformation patterns. Notebooks are strong when the solution needs code-driven Spark processing, reusable logic, libraries, and engineering workflows. T-SQL is a natural fit for relational processing. KQL is central to event and time-oriented analytical work.

Ask which engine is already in use, what skills the team has, how complex the logic is, where the source and destination live, how the work will be orchestrated, and how it will be maintained. A tool can technically perform a join and still be a poor fit for the solution.

Also separate transformation from orchestration. A pipeline may coordinate a notebook or dataflow without being the place where the business transformation itself belongs. That distinction helps candidates interpret scenarios that mix schedules, parameters, dependencies, compute engines, and destinations.

Shortcuts and mirroring solve different data-movement problems

OneLake shortcuts are useful when consumers need access to supported data without creating another conventional copy. They can reduce movement and simplify reuse, but they retain a dependency on the referenced data and its permissions. The architecture should still define source ownership, access, availability, and what happens when the source changes.

Mirroring addresses a different need: maintaining a Fabric representation that follows changes from a supported source. The exact list of supported sources can evolve, so exam preparation should use current Microsoft documentation for implementation details. Conceptually, the key question is whether the requirement is to reference data where it is or to keep a synchronized representation in Fabric.

Draw both patterns. Label the source of truth, data movement, freshness path, consumer location, failure dependency, and security boundary. Diagrams make the difference much harder to confuse than a set of feature bullets.

Data quality requires a business definition before a technical operation

“Remove duplicates,” “fix nulls,” and “clean bad rows” are incomplete instructions. A duplicate requires a definition of identity. A missing value can mean unknown, not applicable, delayed, or invalid. An outlier can be an error or the most important business event in the dataset. DP-700 scenarios reward candidates who preserve meaning rather than applying a generic cleanup command.

For deduplication, identify the business or event key, version precedence, and whether duplicate control applies only within one batch or across history. For nulls, decide whether to reject, preserve, impute, derive, or route the record for remediation. For aggregations, decide what detail is intentionally lost. For denormalization, decide what duplication is introduced and whether the downstream query benefit justifies it.

Validation should follow every structural transformation. Compare row counts after joins, measure unmatched keys, verify expected uniqueness, reconcile totals after aggregation, and make conversion errors visible. Data engineering is not complete when a job reports “success”; it is complete when the output is demonstrably consistent with the business rule.

Batch and streaming differ in state, time, and recovery

Batch workloads process bounded sets of data at intervals. Streaming workloads process continuously arriving events and must reason about event time, windows, state, late arrival, and ongoing progress. Treating streaming as “batch that runs very often” hides the most important engineering differences.

Use the latency requirement as a design input. “Daily file” and “overnight refresh” point naturally toward batch. “Detect within seconds” or “process events as they arrive” points toward streaming. A five-minute freshness target may be met through several patterns depending on scale and architecture; the exam does not reward choosing the most complex real-time technology simply because it sounds modern.

Eventstreams and Eventhouse become more meaningful when studied as part of that end-to-end path. Ask where events originate, what filtering or transformation should happen before storage, where they are routed, how operators know that the stream has stopped, and how schema changes or late events are handled.

DP-700 readiness is the ability to explain trade-offs under failure

A strong candidate can take an unfamiliar scenario and explain why one design is safer or more maintainable than another. That means studying beyond the happy path. What if a pipeline writes half its rows and fails? What if the watermark advances too early? What if an upstream schema changes? What if a shortcut source becomes unavailable? What if a streaming event arrives after the reporting window appears closed?

A DP-700 readiness matrix is useful when every rating is backed by evidence from labs or scenario explanations. Broader comparison with DP-600 and DP-700 responsibilities can also prevent role confusion: data engineering emphasizes ingestion, transformation, and operational data paths, while analytics engineering goes deeper into analytical assets and semantic modeling.

Finally, keep the wider Microsoft Fabric and data skills landscape in view without letting it dilute the immediate exam. DP-700 preparation is strongest when you can reason from source to destination, explain the state carried between runs, choose an engine from workload needs, validate data quality, and recover from failure without corrupting the result. Those are durable data-engineering skills even as individual Fabric features continue to evolve.