Databricks Data Engineer Associate: Complete Guide to Scope, Sample Questions & Pass Strategy

Databricks Certified Data Engineer Associate is the certification that proves your data engineering skills on the Lakehouse. It tests practical understanding of Spark SQL, Python, Delta Lake, Lakeflow Spark Declarative Pipelines, and Unity Catalog, and it is the most-taken exam in the Databricks certification lineup.

This article follows the current Exam Guide revised on May 4, 2026, covering the scoring weights and key topics of the 7 exam sections, sample questions modeled on real exam patterns, and a 2-month study roadmap to pass.

Exam Overview

Let's start with the basics. Here is everything you should check before registering.

One point deserves emphasis: the passing score is not published.The official Databricks FAQ states that "Databricks passing scores are set through statistical analysis and are subject to change as exams are updated with new questions." Numbers like "70%" or "32 of 45 correct" circulate widely, but none of them come from Databricks. Treat any article that quotes a specific cutoff as unverified.

With 45 questions in 90 minutes, you have an average of 2 minutes per question. Most are "choose the best option" style, so you need the judgment to eliminate clearly wrong choices and narrow it down to the final two. A standard approach is to power through high-confidence questions in under 60 seconds and flag the tough ones for a final review pass.

The 7 Exam Sections and Scoring Weights (May 4, 2026 Guide)

The current Exam Guide, revised on May 4, 2026, splits the scope into 7 sections with officially published weights. The section names and the weights both differ from the older 5-domain version (Lakehouse Platform / ELT with Spark SQL and Python / Incremental Data Processing / Production Pipelines / Data Governance), so do not reuse the weight table from older articles or courseware.

Data Ingestion and Loading (21%) plus Data Transformation and Modeling (22%) account for 43% of the exam on their own. Making these two sections your strongest is the shortest path to passing. Next up are Working with Lakeflow Jobs (16%) and Governance and Security (15%). Governance in particular has grown steadily across revisions: 9% (June 2024) → 11% (November 2025) → 15% today, so treating it as a "low-weight section you can skim," as older study plans did, is now a losing strategy. Conversely, Databricks Intelligence Platform is only 6% (~3 questions), so there is no point going deep there.

One more change worth knowing: Delta Sharing and Lakehouse Federation have been removed from the exam scope.Plenty of older courseware and blog posts still cover them as exam topics, so do not spend study time there.

Section 1: Databricks Intelligence Platform (6%)

This section covers Lakehouse architecture concepts and operating the Databricks platform. Expect concept questions ("how does a Data Warehouse differ from a Data Lake?" and "how does Lakehouse unify them?") plus practical questions on compute types and notebooks. Note the weight: the old Databricks Lakehouse Platform domain was 24%, and the current section is only 6% (~3 questions). Treat it as the vocabulary you need for the later sections, not as a place to go deep.

Key Topics and Exam Patterns

• Compute types: The difference between All-Purpose and Job compute is a guaranteed exam topic. On top of "All-Purpose for interactive development, Job compute for production jobs," you'll be asked about job compute auto-terminating after the job finishes and being cheaper than All-Purpose compute. Knowing where SQL Warehouses and serverless compute fit in is also useful.
• Notebook features: Magic commands (%sql, %python, %md), widgets (dbutils.widgets), sharing variables across notebooks via %run, and notebook version history are all in scope.
• Where things live: The account / workspace / Unity Catalog hierarchy, and the difference between managed and external tables, are the vocabulary the ingestion and governance sections assume you already have.

Section 2: Data Ingestion and Loading (21%)

The section about getting data into the Lakehouse, and the second-largest by weight. Auto Loader, COPY INTO, and Structured Streaming are the central topics, and the exam tests your judgment on "which ingestion method do you pick in which situation?" The old Incremental Data Processing domain has essentially been split into this section and the next one.

Key Topics and Exam Patterns

• Auto Loader (cloudFiles): A mechanism for auto-detecting and ingesting new files as they arrive in cloud storage. Expect questions on the difference between Directory Listing and File Notification modes, schema inference (cloudFiles.inferColumnTypes), and schema evolution (cloudFiles.schemaEvolutionMode). "When do you use COPY INTO vs Auto Loader?" is a guaranteed theme. The correct answer is COPY INTO for a small number of files, Auto Loader for continuous ingestion of large file volumes.
• COPY INTO and read_files: COPY INTO is idempotent — it skips files it has already loaded — and you'll be asked about FORMAT_OPTIONS / COPY_OPTIONS (mergeSchema, force) and the CTAS pattern that creates a Delta table from files. The read_files table-valued function for reading files directly in SQL is also worth knowing.
• Structured Streaming: Basic spark.readStream / writeStream syntax, the differences between output modes (append / complete / update), trigger settings (Trigger.availableNow, processingTime), and the role of checkpoints are all tested. "Trigger.availableNow vs Trigger.once" is also a common question.
• Semi-structured data: Expanding nested JSON in Spark SQL — using the ":" notation, explode, from_json, schema_of_json — comes up frequently at the ingestion boundary, where the raw payload arrives as a single string column.

Section 3: Data Transformation and Modeling (22%)

The highest-weighted section, testing practical transformation skills with Spark SQL and PySpark plus the modeling judgment behind the Medallion architecture. Reading and writing code is tested directly, so theory alone won't cut it — hands-on experience translates directly to your score.

Key Topics and Exam Patterns

• Spark SQL basics: Data transformations using SELECT / JOIN / GROUP BY / HAVING / window functions (ROW_NUMBER, RANK, LAG, LEAD). The CTAS (CREATE TABLE AS SELECT) pattern for creating Delta tables is especially common.
• MERGE INTO and CDC: The UPSERT pattern of "UPDATE if the record exists, INSERT if it doesn't." You'll be tested on writing WHEN MATCHED THEN UPDATE / WHEN NOT MATCHED THEN INSERT precisely. Applying INSERT/UPDATE/DELETE events from a source database to a Delta table, and SCD Type 1/2 scenarios, are very common; the declarative equivalent (APPLY CHANGES INTO / apply_changes) is in scope too.
• PySpark DataFrame API: On top of the basics (select / filter / withColumn / groupBy / agg), you'll see questions on equivalent ways to express the same operation in DataFrame API and Spark SQL, including the pattern of running SQL via spark.sql().
• UDFs (User Defined Functions): The performance gap between Python UDFs and Spark SQL built-in functions (Python UDFs incur serialization/deserialization overhead), and the syntax for creating SQL UDFs (CREATE FUNCTION), are both in scope.
• Medallion architecture and declarative pipelines: How Bronze → Silver → Gold maps onto real tables, the @dlt.table / @dlt.view decorators of Lakeflow Spark Declarative Pipelines, the difference between streaming tables and materialized views, and the three levels of Expectations for data quality (@dlt.expect / @dlt.expect_or_drop / @dlt.expect_or_fail) come up frequently. "Drop bad data" → expect_or_drop, "halt the pipeline" → expect_or_fail.

Section 4: Working with Lakeflow Jobs (16%)

This section covers orchestration — bundling the work you built into a job and running it on a schedule. Note the naming: the product formerly called Databricks Workflows is now Lakeflow Jobs, and the current Exam Guide uses that name throughout.

Key Topics and Exam Patterns

• Tasks and dependencies: Which task types a single job can bundle (notebook, SQL, pipeline, Python script, and so on), and how to build a DAG with depends_on. Expect to define multi-task dependencies like "run task B only if task A succeeds," along with the Run if conditions that cover the failure branches.
• Triggers and scheduling: Beyond cron schedules, file-arrival and table-update triggers, and continuous mode, are all fair game. Questions often frame it as "which trigger fits this requirement?"
• Failure handling and notifications: Retry policies, timeouts, Repair run for re-running only the failed tasks, and alert notifications (email / webhook) on start, success, failure, and duration overrun.
• Passing values: Job and task parameters, widgets receiving those parameters, and passing values between tasks with taskValues.

Section 5: Implementing CI/CD (10%)

A section that did not exist as a standalone domain in the old guide: getting code from a notebook into production safely. Two products cover almost all of it — Databricks Git Folders and Declarative Automation Bundles.

Key Topics and Exam Patterns

• Databricks Git Folders (formerly Databricks Repos): How Git integration works, switching branches, the code-review flow via pull requests, and which file types can be managed (notebooks, Python files, configuration files) are all fair game. A classic trap: pulling discards the notebook's local output.
• Declarative Automation Bundles (formerly Databricks Asset Bundles): Declaring jobs and pipelines as code in databricks.yml, separating dev / staging / prod with targets, and parameterizing with variables. The difference between development and production mode is a common question.
• Deployment automation: Deploying bundles with the Databricks CLI and wiring it into a CI pipeline (for example GitHub Actions). Expect "which environment should this run in, and who owns the deployed job?" style questions.

Section 6: Troubleshooting, Monitoring, and Optimization (10%)

The section about what you do after something is already running: find where it broke, watch what it costs, and make it faster. Delta table maintenance commands live here, which is where the OPTIMIZE / VACUUM material from the old Lakehouse Platform domain moved to.

Key Topics and Exam Patterns

• Delta table maintenance: ACID transactions, time travel (DESCRIBE HISTORY / RESTORE), schema evolution (mergeSchema), and the difference between OPTIMIZE and VACUUM are guaranteed to show up. OPTIMIZE compacts small files; VACUUM deletes files that are no longer referenced — mixing up the two is the classic mistake.
• Layout and performance: Data skipping, partitioning pitfalls (over-partitioning small tables), ZORDER, and the small-file problem. The performance gap between built-in functions and Python UDFs shows up here too.
• Error handling and diagnosis: Retry strategies on pipeline failure, diagnosing errors via the Lakeflow Spark Declarative Pipelines event log and job run history, and deciding when to reset a streaming job's checkpoint are all in scope. Knowing which log to open — event log, driver log, or Query History — is the skill being tested.

Section 7: Governance and Security (15%)

The section that grew the most. Governance was 9% in the June 2024 guide and 11% in the November 2025 guide; it is now 15% (~7 questions), on par with Lakeflow Jobs. Study plans written for the old guide treat this as a domain you can skim — that advice is out of date. Unity Catalog is the backbone of the whole section.

Key Topics and Exam Patterns

• Unity Catalog 3-level namespace: The catalog.schema.table hierarchy, default catalog settings, and how to use USE CATALOG / USE SCHEMA are the basics.
• GRANT / REVOKE: The syntax for granting permissions on tables and schemas (GRANT SELECT ON TABLE catalog.schema.table TO group_name). Also common: without USE CATALOG / USE SCHEMA on the parents, a table grant alone gets you nothing, and ownership decides who can grant in the first place.
• Data lineage and auditing: The mechanism by which Unity Catalog automatically records lineage between tables, the use cases for the lineage graph (impact analysis, compliance), and looking up who did what through the system tables and INFORMATION_SCHEMA.
• Fine-grained access control: Dynamic views using CURRENT_USER() and group-membership functions, plus row filters and column masks, for row-level and column-level control. "Show each department only its own rows" and "mask a column for everyone outside one group" are the standard framings.
• Credentials: Storing tokens and passwords in secret scopes instead of hard-coding them in a notebook, and reading them via dbutils.secrets, is the expected answer whenever a question shows a credential in source code.

One caveat for this section: Delta Sharing and Lakehouse Federation are no longer in scope.Both used to be governance topics, and older courseware still drills them, but the current guide has dropped them.

2-Month Roadmap to Pass

Below is an 8-week roadmap based on 1-2 hours per weekday and 3-4 hours per weekend day. It assumes basic familiarity with Spark and data engineering, and it follows the 7 sections in order, with time allocated in proportion to their weights.

For learning resources, build your prep around three pillars: Databricks Academy (free Learning Paths), the official Practice Exam (accessible from Webassessor after exam registration), and hands-on labs on Community Edition. Cycling through theory → hands-on → question practice for each topic produces the highest retention. Since the passing score is not published, there is no "X% on the Practice Exam and you're safe" threshold — judge yourself by whether you can answer consistently in every section, not by a single number.

Exam Patterns from People Who Passed

Here are the patterns distilled from feedback by people who actually passed.

• "Choose the best option" makes up over 70%: Rather than obvious wrong answers, expect "all options are partially correct — which is the best?" style questions. You'll often narrow to two and agonize over the final pick, so you need to precisely distinguish each feature's purpose, constraints, and best practices.
• Code questions only require reading skills: No question asks you to write code from scratch. They ask about the output, behavior, or error cause of given SQL or PySpark code. That said, the syntax of MERGE INTO, Auto Loader, and Lakeflow Spark Declarative Pipelines may appear in fill-in-the-blank form, so memorize the skeleton.
• Delta Lake spans every section: Delta Lake shows up in Section 2 (ingestion targets), Section 3 (MERGE INTO and Medallion tables), and Section 6 (OPTIMIZE / VACUUM / time travel), which effectively makes it the most-tested topic of all. Lock down OPTIMIZE, VACUUM, Z-ORDER, time travel, and schema evolution.
• Elimination works: 1-2 of the 4 options will be clearly unrelated features (e.g., Unity Catalog appearing where MLflow is the answer), so narrow it down to 2 by elimination first.

Stepping Up to Related Certifications

Once you pass Data Engineer Associate, two certifications are strong next steps.

DEA → DEP deepens your data engineering career, while DEA → MLA opens the path toward becoming an ML engineer. Either way, the Delta Lake, Spark, and Unity Catalog knowledge from DEA carries over as the foundation, so it's most efficient to take the next exam while DEA material is still fresh. As a rule of thumb, aim to take the next exam within 2-3 months of passing DEA.

Check Your Understanding

Frequently Asked Questions