Databricks DE Pro: ingestion, manipulation, modelling
Data Ingestion & Acquisition (12%), Data Manipulation (12%) and Data Modelling (5%) are 29% of the Databricks Data Engineer Professional exam between them in the outline that applies from 9 October 2026: around 17 of the 60 scored questions.
The October 2026 outline reshaped all three. Ingestion grew from 7% and absorbed the old Data Sharing and Federation section. Data Transformation, Cleansing, and Quality became Data Manipulation and gained semi-structured data and AI functions. Modelling now names table layouts, materialised views and metric views. The exam format page lists every move.
Ingestion and acquisition (12%)
About seven questions, pitched well above the Associate:
- Formats and sources. Delta Lake, Parquet, JSON, Iceberg, CSV and binary files, from cloud storage and from message buses such as Kafka, Kinesis and Pub/Sub.
- Incremental CDC pipelines in Lakeflow pipelines, with Delta or Iceberg as the target format. Changes must be applied in order, including deletes, and must tolerate late or out-of-order events.
- CDC from relational databases with Lakeflow Connect: SQL Server, MySQL and PostgreSQL as sources, rather than hand-built extraction jobs.
- Incremental by default, schema changes handled deliberately, and the ability to reprocess a target from source without duplicating.
Sharing and federation
These used to be their own section and now sit inside ingestion. Two directions, and questions offer both:
OpenSharing (formerly Delta Sharing) is outbound: your data, someone else’s access, without copying it or giving them workspace accounts. The October 2026 outline uses the new name, “OpenSharing (D2D and Databricks-to-Open)”, matching the Databricks and Microsoft Learn documentation, whose old /delta-sharing/ pages now redirect to OpenSharing; older material and answer options may still say Delta Sharing, and it is the same feature. Databricks-to-Databricks (D2D) sharing serves recipients with a Unity Catalog-enabled workspace; Databricks-to-Open (open) sharing serves recipients on other platforms. See the OpenSharing guide for the full comparison. The scenario is always a partner, supplier or customer who needs live data you do not want to export.
Clean Rooms go a step further for privacy-preserving collaboration: parties run agreed analysis over combined data without either side seeing the other’s raw tables.
Lakehouse Federation is inbound: querying data that lives in an external system without ingesting it first. The outline stresses governance: the connection holds the credentials, and Unity Catalog permissions decide who can query the foreign catalog.
All three exist to avoid the default bad answer: exporting a copy. A copy is stale the moment it is made, doubles storage and creates a governance object nobody tracks.
Data manipulation (12%)
About seven questions. The renamed section keeps advanced transformation and quality, and adds two newer capabilities.
Transformations. Window functions, joins and aggregations in Spark SQL and PySpark on large data: deduplicating on a business key and choosing which record survives, ranking, running totals, and handling late-arriving records for a period already processed.
Semi-structured data with VARIANT. Store JSON as the VARIANT type with parse_json, then extract fields with variant_get or path syntax, instead of forcing a rigid schema on data whose shape changes.
AI functions. ai_query calls a model from SQL or a pipeline, so enrichment or classification can run as a column expression inside the transformation.
Quality as expectations. In Lakeflow Declarative Pipelines an expectation can keep violating rows and record the metric, drop them, or fail the update. Quarantine means routing the failing rows to their own table so they stay investigable. The exam expects you to match the response to the stakes. The scenario to recognise: a pipeline that succeeds while producing wrong data. Job success proves the code ran; only quality validation proves the output is right.
Data modelling (5%)
About three questions:
- Table layout for large data. Partitioning only where it matches the data grain, clustering aligned to how tables are joined and filtered, and compaction to keep file sizes balanced, for Delta and Iceberg tables.
- Dimensional models for analytics: facts and dimensions, the grain of a fact table, and slowly changing dimensions. Type 1 overwrites and loses history; Type 2 adds a row with validity dates so historical facts join to the values current at the time. Section 1 tests building them with AUTO CDC.
- Materialised views for pre-computed aggregations, and Unity Catalog metric views for metric definitions that are governed and reused instead of re-implemented per dashboard.
Any scenario requiring point-in-time correctness, such as “the region as it was when the order was placed”, is a Type 2 question.
Sample questions
Question 1. A nightly pipeline reports success every run, but a finance metric has been understated for three weeks. What control was missing?
- A. Cluster resource monitoring
- B. Data quality expectations validated against the output, with alerting on violations
- C. Longer log retention on the job
- D. A larger cluster to avoid resource contention
Show answer
Answer: B
Job success confirms only that the code executed, so data quality expectations validated against the output are what would have caught an incorrect metric. Cluster monitoring, longer retention and a bigger cluster address unrelated concerns.
Want more questions like this? Full Data Engineer Pro practice tests →
Question 2. A customer's assigned sales region changes. Historical orders must continue to report under the region that applied at the time of the order. Which dimension design is required?
- A. Type 1 slowly changing dimension
- B. Store the region directly on each order row and never update it
- C. Delete and recreate the dimension each night
- D. Type 2 slowly changing dimension with validity dates
Show answer
Answer: D
A type 2 slowly changing dimension inserts a new row with validity dates on change, so historical facts join to the values current when they occurred. Type 1 overwrites and loses history, storing the region on the fact table denormalises without solving dimension management, and deleting history is the opposite of the requirement.
Want more questions like this? Full Data Engineer Pro practice tests →
Question 3. A partner organisation needs ongoing read access to three tables. They must not have workspace accounts, and the data must not be exported to a location you no longer control. Which approach fits?
- A. A nightly export to a shared cloud storage bucket
- B. OpenSharing (formerly Delta Sharing) with the partner organisation
- C. Create workspace accounts for the partner’s analysts
- D. A scheduled extract emailed to the partner
Show answer
Answer: B
OpenSharing (formerly Delta Sharing) gives an external organisation live read access without workspace accounts and without exporting copies, which matches both constraints. A nightly export creates uncontrolled copies, partner accounts grant workspace access, and emailed extracts are both stale and uncontrolled.
Want more questions like this? Full Data Engineer Pro practice tests →
Question 4. Device events arrive as JSON whose fields change every few weeks. Engineers want to land them without redefining a schema each time, then extract a few fields in SQL. What fits best?
- A. Store the payload as VARIANT with parse_json and extract fields with variant_get
- B. Store every field as a string column and cast at query time
- C. Define a fixed struct schema and update it on each change
- D. Flatten the JSON to CSV before loading
Show answer
Answer: A
The VARIANT type stores semi-structured data without a fixed schema, and functions such as variant_get extract fields at query time. Casting everything to strings loses types and makes extraction fragile, a rigid struct breaks when fields change, and converting to CSV loses the nesting entirely.
Want more questions like this? Full Data Engineer Pro practice tests →
What to practise
Define three expectations on a pipeline table and violate each, choosing a different response for each: keep and record, drop, fail. Then build a Type 2 dimension and run a point-in-time join against it. Finally, load a JSON feed into a VARIANT column and pull two fields out with variant_get.
Those exercises cover the most examined ideas across all three sections.