Published November 14, 2026 · By Henry Palma

Databricks Data Engineer Associate Exam Prep, Lesson 1: Platform, Unity Catalog and Compute

Databricks Data Engineer Associate exam prep, Section 1: control and compute planes, Unity Catalog, managed Delta tables, and picking compute by workload and cost.

Section 1 of the Databricks Data Engineer Associate exam guide (August 2026), the Databricks Intelligence Platform, is only 6% of the exam, but every other section builds on it. It asks you to know the core components (architecture, Delta Lake and Unity Catalog) and to pick the right compute for a workload based on its characteristics, limits and cost. This post follows Lesson 1 of the exam prep series, with a hands-on part in Databricks Free Edition.

Watch on YouTube

The notebook and cheat sheet are in the A01 folder on GitHub. This is independent study material, not official Databricks training.

Control plane and compute plane

Databricks has two planes:

The control plane holds the backend services Databricks manages, including the web application where you write notebooks and queries.
The compute plane is where your data is processed. With serverless compute, it runs in a serverless compute plane in your Databricks account. With classic compute, the machines run in your own cloud account.

Free Edition is serverless only, so everything in this lesson runs in the serverless compute plane.

Account, workspace and metastore

The Databricks account manages identity, workspaces, usage and the Unity Catalog metastore. A workspace is where people run notebooks, jobs, queries and dashboards. A metastore is the top of Unity Catalog governance, and one metastore can be attached to several workspaces in the same region. Free Edition gives you one workspace and one metastore, with no account console.

Unity Catalog's three-level namespace

Unity Catalog organizes data as catalog, then schema, then object. At the third level you find tables, views, volumes, functions and models. A full table name is catalog.schema.table. Unity Catalog is also where access control, lineage and auditing live.

In Free Edition, open Catalog in the sidebar. The default catalog is usually workspace, with a schema named default. The tree you expand is the same three-level namespace drawn as folders.

Create a managed Delta table

In a Python notebook on Serverless, the lesson reads the current catalog instead of hard-coding it, then creates a new schema and a table:

catalog = spark.sql("SELECT current_catalog()").first()[0]
schema = f"bt_platform_{uuid.uuid4().hex[:12]}"     # new every run
spark.sql(f"CREATE SCHEMA {catalog}.{schema} COMMENT 'Build and Teach A01'")
table_fqn = f"{catalog}.{schema}.study_plan"
spark.sql(f"""CREATE TABLE {table_fqn} (
  lesson_id STRING, section STRING, topic STRING, weight_pct INT
) COMMENT 'Fictional study-plan rows'""")   # no LOCATION = managed

There is no LOCATION, so this is a managed table: Unity Catalog decides where the files live and manages their lifecycle. Delta is the default table format on Databricks, so it is a Delta table without saying so.

Three study-plan rows go in: A01 (platform, 6%), A02 (ingestion, 21%) and A07 (transformation, 22%). Those weights come from the exam guide.

What makes it Delta Lake

Delta Lake is the storage layer under Databricks tables. Rows are stored in Parquet files, next to a transaction log. That log gives you atomicity, consistency, isolation and durability (ACID) transactions, so readers never see a half-finished write. Delta also enforces the schema, supports update, delete and merge, and keeps versions you can time travel to.

detail = spark.sql(f"DESCRIBE DETAIL {table_fqn}")
detail.select("format", "numFiles", "sizeInBytes", "createdAt").show(truncate=False)
ext = spark.sql(f"DESCRIBE TABLE EXTENDED {table_fqn}")
ext.filter("col_name = 'Type'").show(truncate=False)        # MANAGED

DESCRIBE DETAIL shows the format as delta, plus file count, size and creation time. DESCRIBE TABLE EXTENDED shows the type as MANAGED. Free Edition uses default storage, and custom workspace storage locations are not supported there.

Read the history

After an UPDATE that changes A07's topic to "Transformation and modeling", DESCRIBE HISTORY lists each version with its operation: CREATE TABLE, then a WRITE for the insert, then the UPDATE. Every commit becomes a new version. If background maintenance such as predictive optimization runs later, you may see extra versions, and that is normal.

Same table, different compute

Free Edition has two kinds of compute:

Serverless compute for notebooks, which ran the Python cells. There is no cluster to configure.
One SQL warehouse, called the Serverless Starter Warehouse, limited to the 2X-Small size. A SQL warehouse is built for SQL queries, BI tools and dashboards.

Query the same table by its full name from the SQL Editor on that warehouse and you get the same three rows under the same Unity Catalog governance. The data does not move. Only the engine running the query changes.

Compute in paid workspaces

The exam expects you to know options that Free Edition does not offer:

Classic all-purpose compute for interactive work. You choose the size and runtime, it can be standard (shared) or dedicated, and auto termination stops it when idle.
Jobs compute is created for a job run and terminates when the run ends.
Instance pools keep idle instances ready to cut startup time.

How compute is billed

Usage is measured in Databricks Units (DBUs), billed per second.

With classic compute, you pay Databricks for DBUs, and your cloud provider bills separately for the virtual machines.
With serverless, the compute runs in the Databricks account, so the serverless DBU price covers it.
Jobs compute has a lower DBU rate than all-purpose compute, which is why scheduled production work belongs on jobs compute.
Pools do not charge DBUs while instances sit idle, but the cloud provider still bills for those instances.

Choosing compute by workload

| Workload | Choice | |---|---| | Interactive notebook exploration | Serverless notebook compute, or all-purpose compute for a custom configuration | | Scheduled production work | Serverless jobs or classic jobs compute | | SQL analytics, BI tools, dashboards | SQL warehouse, ideally serverless for fast startup | | Classic jobs that must start fast | Back them with a pool |

In a scenario question, look for the workload words first: interactive, scheduled, SQL, startup time and cost.

Free Edition limits

Serverless compute only, one 2X-Small SQL warehouse, at most five concurrent job tasks, one active pipeline per pipeline type, restricted outbound internet access and no account console. There is also a fair usage quota. If you exceed it, compute shuts down for the rest of the day, but your data and settings are kept.

Practice challenge

Predict what happens if you delete every row in studyplan where weightpct is below 10, then run DESCRIBE HISTORY again. How many rows remain? What is the newest operation? Can you still read A01?

Answers: two rows remain (A02 and A07). The newest history entry is a DELETE. And you can still read A01 with time travel, using VERSION AS OF the version before the delete, until VACUUM removes the old files after the retention period. The solution cell is commented out in the notebook.

Key takeaways

The control plane runs Databricks services. The compute plane processes your data, serverless or classic.
Unity Catalog names everything catalog.schema.table and governs it in one place.
Managed tables default to Delta, and the transaction log gives you versions and history.
Pick compute by workload, and remember that DBU usage drives cost.

For a deeper walkthrough of time travel, see Build Your First Delta Table. Next, Lesson 2 covers batch, streaming and incremental ingestion.