Databricks Data Engineer Professional study plan

Updated September 20, 2026

Six weeks at 8–10 hours a week. Ten sections is a lot of surface, so this plan groups them rather than treating each separately.

You need a Databricks workspace with enough data to make performance visible. Several sections — optimisation, debugging, monitoring — cannot be learned on toy datasets where everything is instant.

Hold the Associate already? See the compressed plan at the end.

Weeks 1 and 2: developing code (22%)

The largest section, two weeks.

Week 1 — reading and reasoning about code:

  • PySpark DataFrame operations: selects, filters, joins, aggregations, window functions.
  • The same logic expressed in SQL, and when each is preferable.
  • Lazy evaluation and what actually triggers work.
  • Reading a snippet and predicting its output — the core exam skill.

Week 2 — writing it well:

  • Structuring reusable, testable transformation code.
  • Common inefficiencies: unnecessary shuffles, collecting to the driver, row-by-row operations.
  • User-defined functions and why they are usually the slow option.
  • Handling errors inside transformations.

Week 3: cost and performance optimisation (13%)

The second largest section and the one that most distinguishes this exam.

  • Reading the Spark UI: stages, tasks, shuffle volume, spill.
  • Data skew — recognising it and redistributing.
  • Small files — how they arise and how compaction fixes them.
  • Partitioning and file layout: choosing columns, avoiding over-partitioning.
  • Join strategies, including broadcasting small tables.
  • Caching — when it helps and when it wastes memory.
  • Cluster sizing, autoscaling, and terminating idle compute.

Week 4: ingestion (7%), transformation and quality (10%), modelling (6%)

Three related sections, 23% together.

  • Ingestion and acquisition at Professional level: incremental patterns, handling source changes, reprocessing safely.
  • Transformation, cleansing and quality: deduplication, null strategies, late-arriving data, and enforcing quality expectations rather than assuming them.
  • Data modelling: dimensional modelling on the lakehouse, slowly changing dimensions, and choosing grain.

Week 5: monitoring (10%), debugging and deploying (10%), security (10%), governance (7%), sharing (5%)

Five sections, 42% together. Cover each properly but briskly.

  • Monitoring and alerting: what to instrument, meaningful thresholds, detecting a pipeline that succeeds while producing wrong data.
  • Debugging and deploying: diagnosing failures from logs and the Spark UI, deployment patterns, rollback.
  • Security and compliance: encryption, access control, sensitive data handling, audit.
  • Governance: Unity Catalog at depth — lineage, ownership, policy.
  • Sharing and federation: sharing data across organisations, and querying external sources without copying.

Week 6: practice and repair

  • Full practice exam under real conditions: 120 minutes, 59 questions.
  • Sort mistakes by section. With ten sections, look for clusters rather than individual misses.
  • Rebuild the weakest two, then take a second practice exam.

Where the hours go

WeekFocusWeightHours
1–2Developing code22%16–20
3Cost and performance13%8–10
4Ingestion, quality, modelling23%8–10
5Monitoring, deploying, security, governance, sharing42%8–10
6Practice and repair8–10

Compressed plan for Associate holders

Three to four weeks:

  1. Weeks 1–2: developing code. Entirely new emphasis.
  2. Week 3: cost and performance optimisation, plus data modelling and data sharing and federation.
  3. Week 4: practice exam, then repair whatever the score report flags.

Do not restudy ingestion, governance and basic transformation — verify with practice questions and move on.

The small sections are the trap. Five of them are 7% or less, which feels negligible until you notice they total 25% of the exam. Give each an hour; give none of them zero.