Overview
Section 1 covers the foundation that every later section assumes. The first objective asks you to explain the core parts of the Databricks Platform: the control plane that Databricks runs, the compute plane where your data is processed, Delta Lake as the default table format, and Unity Catalog as the governance layer with its catalog.schema.object namespace. The second objective is about compute. You need to compare serverless compute, classic jobs compute, all-purpose clusters and SQL warehouses by how they start, what they can run, how they are billed and where they fall short, and then match each to a workload.
This page is based on the exam version Databricks published on 4 May 2026, using the exam guide revised on 6 August 2026. That version is current as of October 2026, with no announced retirement or replacement.
How it's tested
Questions are short and definitional more often than in other sections, but compute items are usually framed as a workload with constraints: a nightly batch job, an analyst dashboard, an ad hoc notebook session. You choose the compute type that fits the startup, cost and language needs. Platform items test which component owns which responsibility.
-
Match workload to compute
A workload is described by schedule, users and language, and you choose serverless, jobs compute, an all-purpose cluster or a SQL warehouse.
-
Name the responsible component
A capability such as ACID transactions, lineage or access control is described and you identify Delta Lake, Unity Catalog or the control plane.
-
Spot the limitation
An option looks right but the compute type cannot run the stated code, such as R or RDD APIs on serverless notebooks.
A team runs a nightly Python notebook that must start quickly and needs no custom cluster configuration or init scripts. An all-purpose cluster would work but bills at a higher rate and stays up between runs. Serverless compute for jobs starts in seconds, scales on its own and is billed only for the run, so it is the best fit for that brief.
Objectives 2
Official objectives from the Databricks outline, in outline order.
1.1 Understand the core components of the Databricks Platform, such as its architecture, Delta Lake, and Unity CatalogHow the control plane, compute plane, Delta Lake and Unity Catalog fit together.
- What it means
- Databricks splits into a control plane, which hosts the web application, job scheduler and notebook service, and a compute plane where clusters and serverless resources process data. Delta Lake stores tables as Parquet files plus a transaction log, giving ACID writes, time travel and schema enforcement. Unity Catalog governs data and AI assets across workspaces attached to the same metastore.
- What to understand
- Classic compute runs in the customer's cloud account, while serverless compute runs in an account Databricks manages. The Delta transaction log in the _delta_log folder records every commit, which is how readers get consistent snapshots and how DESCRIBE HISTORY and VERSION AS OF work. Unity Catalog uses a three-level name, catalog.schema.table, and also governs views, volumes, functions and models. One metastore usually serves all workspaces in a region, and privileges, audit logs and lineage are kept there rather than per workspace.
- How it shows up
- Expect items that describe a capability and ask which component provides it, or that test the three-level namespace.
- Common confusion
- Thinking Unity Catalog stores the table data itself; it governs metadata and access while files live in cloud storage.
1.2 Understand Databricks Platform's compute services, including their characteristics, limitations, and cost models, and select the most suitable option for each workload use caseComparing serverless, jobs, all-purpose and SQL warehouse compute.
- What it means
- Databricks offers several compute types. All-purpose clusters support interactive notebooks and can be shared. Jobs compute is created for a job run and terminated afterwards. Serverless compute for notebooks, jobs and pipelines starts quickly without any cluster settings. SQL warehouses serve SQL queries and BI tools. Each type has a different DBU rate and different limits.
- What to understand
- Jobs compute costs less per DBU than all-purpose compute, which is why production schedules should not reuse interactive clusters. Serverless removes startup waits and infrastructure tuning but supports Python and SQL rather than R or Scala notebooks, does not allow RDD APIs, and only accepts a small set of Spark configuration settings. Classic clusters need access mode choices: standard (formerly shared) for multiple users and dedicated (formerly single user) for one identity. Pools keep idle instances ready to shorten classic startup. Photon speeds SQL and DataFrame work at a different DBU rate.
- How it shows up
- Scenario items give a schedule, users and language mix, then ask for the cheapest or fastest-starting compute that still works.
- Common confusion
- Choosing an all-purpose cluster for a scheduled production job because it is already running.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Control plane
Databricks-managed backend for the UI, jobs scheduler and notebooks.
- Remember
- Your data is processed in the compute plane, not here.
- Tested as
- Architecture identification items.
- Trap
- Saying customer data is stored in the control plane.
-
Serverless compute plane
Compute that runs in a Databricks-managed cloud account.
- Remember
- No VM quotas or images to manage on your side.
- Tested as
- Compute selection questions.
- Trap
- Assuming serverless runs in your own VPC.
-
Delta transaction log
The _delta_log folder of JSON commits and checkpoints.
- Remember
- Source of ACID guarantees and time travel.
- Tested as
- Delta Lake capability items.
- Trap
- Treating Delta as a different file format from Parquet.
-
Three-level namespace
catalog.schema.table naming in Unity Catalog.
- Remember
- Every governed object has a catalog and schema.
- Tested as
- Ingestion and governance syntax.
- Trap
- Writing two-part names and expecting the right catalog.
-
Metastore
Top-level Unity Catalog container, usually one per region.
- Remember
- Shared by many workspaces in that region.
- Tested as
- Cross-workspace governance items.
- Trap
- Thinking each workspace needs its own metastore.
-
Jobs compute
Cluster created for a job run and removed when it ends.
- Remember
- Lower DBU rate than all-purpose compute.
- Tested as
- Cost optimization questions.
- Trap
- Leaving production jobs on interactive clusters.
-
SQL warehouse
Compute for SQL queries, dashboards and BI connections.
- Remember
- Serverless warehouses start in seconds.
- Tested as
- Analyst and BI workload items.
- Trap
- Running Python notebooks on a warehouse.
-
Access modes
Standard (multi-user, isolated) or dedicated (one user or group).
- Remember
- Both work with Unity Catalog.
- Tested as
- Classic cluster configuration items.
- Trap
- Using old names like no isolation shared for governed data.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Compute types
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| All-purpose cluster | Interactive cluster for notebooks, shared by users. | Highest DBU rate; stays up until terminated. | Using it for nightly production jobs. |
| Jobs compute | Ephemeral cluster created per job run. | Cheaper and isolated per run. | Expecting it to be available for ad hoc notebooks. |
| Serverless compute | Managed compute for notebooks, jobs and pipelines. | Fast start, no cluster settings, fewer language options. | Assuming every Spark setting and language is supported. |
| SQL warehouse | Endpoint for SQL and BI queries. | SQL only; serves dashboards and JDBC/ODBC tools. | Picking it for PySpark transformations. |
Platform components
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Delta Lake | Open table format with a transaction log. | Handles storage, ACID and versions. | Crediting it with access control. |
| Unity Catalog | Governance layer for data and AI assets. | Handles privileges, lineage and auditing. | Crediting it with file compaction. |
| Control plane | Databricks-run services such as the UI and scheduler. | Orchestrates; does not hold table data. | Placing customer data in it. |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Interactive cluster for a schedule
- What candidates pick
- An existing all-purpose cluster
- Why it looks right
- It is already running, so the job starts immediately.
- Why it's wrong
- All-purpose compute costs more per DBU and mixes production with ad hoc work; jobs or serverless compute is the intended choice.
Clue to watch for Words like nightly, scheduled or production.
-
Serverless for unsupported code
- What candidates pick
- Serverless compute for an R or Scala notebook
- Why it looks right
- Serverless is the modern default and starts quickly.
- Why it's wrong
- Serverless notebooks support Python and SQL; other languages need classic compute.
Clue to watch for A language or RDD requirement in the scenario.
-
Warehouse for PySpark
- What candidates pick
- A SQL warehouse to run DataFrame code
- Why it looks right
- Warehouses are fast and serverless.
- Why it's wrong
- SQL warehouses run SQL statements only and cannot execute Python notebooks.
Clue to watch for PySpark, DataFrame or Python library in the brief.
-
Unity Catalog as storage
- What candidates pick
- Unity Catalog stores the data files
- Why it looks right
- Tables are created and listed through Unity Catalog.
- Why it's wrong
- Files sit in cloud object storage; Unity Catalog holds metadata, permissions and lineage.
Clue to watch for A question about where bytes physically live.
-
Delta adds a new file type
- What candidates pick
- Delta files replace Parquet
- Why it looks right
- Delta is described as a format.
- Why it's wrong
- Delta tables store data in Parquet files and add a JSON transaction log beside them.
Clue to watch for Mentions of _delta_log or Parquet.
Answer framework
Use these steps for compute selection and platform component questions in Section 1.
- Identify whether the workload is interactive, scheduled, SQL-only or a pipeline, because that alone narrows the compute choice to one or two options.
- Check language and API needs: R, Scala, RDD code or custom init scripts point to classic compute rather than serverless.
- Compare cost behaviour by preferring ephemeral jobs compute or serverless for production runs and all-purpose clusters only for development.
- For capability questions, map ACID, time travel and schema enforcement to Delta Lake, and privileges, lineage and auditing to Unity Catalog.
- Confirm object names use catalog.schema.table and that the stated users can reach the same metastore before accepting the answer.
Practice question
Want more like this? The Databricks DE Assoc practice test has questions for every domain.
Checklist
0 of 10
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Spend a short block, around four to six hours, on this section and treat it as vocabulary for the rest of the exam. Start in a workspace: open Catalog Explorer, find a metastore's catalogs and schemas, and query a table by its three-level name. Run DESCRIBE HISTORY on a Delta table, then read an older version with VERSION AS OF so the transaction log becomes concrete.
For compute, build a small comparison table of your own with columns for startup, billing, supported languages and typical workload. Create a job that uses serverless compute and another that uses a new jobs cluster, then compare their run durations and the compute shown on each run page. Read the serverless limitations page in the documentation, because exam distractors often rely on a feature serverless does not support.
Finish by answering short scenario prompts out loud: who runs this, when, in which language, and what does it cost? If you can justify one compute choice in a sentence, move on to Data Ingestion and Loading, where these ideas are applied.
FAQ
How much of the exam is Databricks Intelligence Platform?
Databricks Intelligence Platform is Section 1 and carries 6% of the exam, so expect about 3 of the 45 scored questions. The section has two official objectives.
Do I need to know cloud networking for this section?
Only at a basic level. Know that classic compute runs in your cloud account and serverless runs in a Databricks-managed account. Detailed VPC design is outside the Associate scope.
Is Hive metastore content still tested?
The current guide focuses on Unity Catalog. Knowing that legacy tables used two-level names helps you spot outdated options, but new work should be framed in Unity Catalog terms.
Which compute should I assume when a question gives no detail?
Read for clues such as schedule, language or SQL-only use. Without any, Databricks generally recommends serverless where it is available, but the scenario wording usually settles the choice.
Are DBU prices tested?
Exact prices are not tested. You should know relative cost: all-purpose compute bills higher than jobs compute, and idle clusters keep accruing charges until auto termination.
What is Photon?
Photon is the vectorized query engine that speeds up SQL and DataFrame operations. It is enabled by default on serverless and SQL warehouses and optional on classic clusters.
Other Data & Analytics certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 1 knowledge
Check whether you can match workloads to compute and name the right platform component before moving to heavier sections.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the Databricks DE Assoc AI tutor Get any concept explained your way