5 Questions to Test Your Databricks Intelligence Platform Knowledge (DBX-DEA)

This set covers Databricks Intelligence Platform, one of the domains of the Databricks Data Engineer Associate (DBX-DEA) exam. It makes up about 6% of the exam. Try each question first, then open the answer to see why every option is right or wrong.

Databricks Data Engineer Associate (DBX-DEA) · Databricks Intelligence Platform · 5 questions with answers and explanations

📊 This set at a glance

Exam: DBX-DEA · 45 questions · 90 minutes
This set: 5 applied · 2 concept check, 2 trade-off, 1 scenario
Topics: Databricks compute, Databricks workspace architecture, Lakeflow Jobs, serverless compute, Delta Lake, Unity Catalog

🧭 What these questions look for

Platform questions check how a Databricks workspace is put together and what it costs to run. Scenarios cover idle clusters, scheduled ETL on shared compute, failed writes and default table formats. The deciding facts are architectural: which plane runs which service, when a Delta write becomes visible, and which compute type fits interactive versus scheduled work.

Three things to look for

• For cost questions, check whether the work is interactive or scheduled; scheduled runs belong on compute that exists only for the run, and idle interactive clusters need auto termination.
• Reason about failed writes through the transaction log: data files are not part of a table until the commit, which also explains how time travel and VACUUM interact.
• Keep the two planes straight: Databricks runs the web application and scheduler, while where Spark processes data depends on classic or serverless compute.

Question 1 of 5

A data scientist develops notebooks interactively for a few hours a day and often forgets to stop the classic all-purpose cluster, which runs overnight. Which setting reduces the cost of this idle time without changing the workflow?

AA Databricks Runtime LTS version, whose cluster stops by itself when no notebook is attached to it

BA higher maximum number of workers, so that queries use more nodes and finish before the user is away

CAn auto termination period, so the cluster shuts down after the chosen number of minutes of inactivity

DA larger driver node, so that the notebook finishes its commands faster and the cluster is released earlier

Show answer

✅ Answer: C

Difficulty: applied · Topic: Databricks compute

Automatic termination
Classic compute bills while it is running, whether or not it executes work. On the compute configuration, automatic termination stops the compute after a set number of minutes of inactivity. The compute can be restarted later (configuration is retained).
• Typical for all-purpose clusters used interactively.
• Autoscaling scales workers with load but does not stop an idle cluster; at least the minimum workers (and the driver) keep running.
• Serverless compute for notebooks avoids the question entirely, since resources are managed by Databricks.

Why each option works or fails
• ✗ A. LTS runtime: the Runtime version decides which Spark and library versions are installed. It has no effect on whether the cluster stops.
• ✗ B. Higher maximum workers: autoscaling affects how many workers run under load, and the cluster still stays up when idle.
• ✓ C. Auto termination (correct): the idle cluster is stopped after the configured inactivity period, so overnight hours no longer cost anything.
• ✗ D. Larger driver: this raises the cost per hour of the running cluster and does not stop it when nobody is using it.

🎯 Key idea: Use automatic termination on all-purpose compute so idle clusters shut down.

Question 2 of 5

A security architect asks where the web application, job scheduler and notebook service of a Databricks workspace run, compared with the place where Spark processes the data of a classic compute cluster. Which description is correct?

ABoth the web application and classic compute run in the control plane, and the customer's cloud account only stores the cloud audit logs of the workspace

BThe web application and scheduling services run in the control plane managed by Databricks; classic compute runs in the compute plane inside the customer's own cloud account

CThe web application and scheduling services run in the customer's cloud account; classic compute runs in a compute plane that Databricks operates in its own account

DBoth the web application and classic compute run in the customer's cloud account, and Databricks supplies only the Spark runtime images used by the clusters

Show answer

✅ Answer: B

Difficulty: applied · Topic: Databricks workspace architecture

Two planes
A Databricks workspace is split into a control plane and a compute plane.
• The control plane holds the backend services that Databricks manages in the Databricks account: the web application, the notebook and job services, cluster management and workspace metadata.
• The compute plane is where data is actually processed. With classic compute the plane lives in the customer's own cloud account, so clusters read data in the customer's network and storage. With serverless compute the resources run in a serverless compute plane in the Databricks account.

Why it matters
Data engineers choose compute partly by this split: classic compute gives control over networking and instance types in the customer account, while serverless removes the infrastructure work.
Example: submitting a job in the Jobs UI sends the request to the control plane, which launches VMs in the compute plane to run the Spark tasks.

Why each option works or fails
• ✗ A. Everything in the control plane: classic compute resources are created in the customer's cloud account, so data processing does not happen in the Databricks-managed control plane.
• ✓ B. Control plane versus compute plane (correct): Databricks hosts the web application and scheduling services, and classic clusters are started as VMs in the customer's own cloud account, which is where Spark processes the data.
• ✗ C. Reversed planes: the web application is a Databricks-managed service in the control plane, not something running in the customer account, and classic compute is the part that runs in the customer account.
• ✗ D. Everything in the customer account: the web application, job service and workspace metadata are backend services that Databricks manages itself, so they are not deployed into the customer's account.

🎯 Key idea: Control plane = Databricks-managed services; compute plane = where data is processed (customer account for classic, Databricks account for serverless).

Question 3 of 5

A nightly ETL notebook runs on an all-purpose cluster that three engineers also use for ad hoc work. The cluster is idle most of the day, and the team wants to lower cost without changing the code. Which change fits best?

AMove the notebook to a SQL warehouse, which is the compute that Databricks designed for scheduled Python data engineering code

BTurn off autoscaling on the all-purpose cluster and set a fixed number of workers, which stops the cluster from paying for idle time

CRun the notebook as a Lakeflow Jobs task on job compute, or serverless compute for jobs, so resources exist only while the run lasts

DKeep the all-purpose cluster running all day with a larger node type, so the nightly run finishes sooner and ends before the day begins

Show answer

✅ Answer: C

Difficulty: applied · Topic: Lakeflow Jobs, serverless compute

Interactive versus automated compute
• All-purpose compute is for interactive work: it is shared, stays up until it auto-terminates and is billed at the all-purpose rate while it runs.
• Job compute (classic) is created for a job run and terminated when the run ends; it is billed at the lower jobs rate.
• Serverless compute for jobs runs Lakeflow Jobs without configuring or deploying infrastructure; Databricks provisions and scales resources.
For a scheduled nightly workload with no need for a persistent cluster, running as a job on job compute or serverless removes the idle time and the interactive rate.

Why each option works or fails
• ✗ A. SQL warehouse: a SQL warehouse runs SQL queries for analytics and BI. It does not run notebooks of Python data engineering code.
• ✗ B. Fixed workers: removing autoscaling does not stop idle charges, because the fixed-size cluster keeps all workers running until it is terminated.
• ✓ C. Job compute or serverless jobs (correct): the resources exist only for the duration of the nightly run, so there is no idle cost, and the notebook code runs unchanged.
• ✗ D. Larger always-on cluster: the cluster still runs all day, so the idle hours, which are the source of the cost, remain and the node size only increases the hourly rate.

🎯 Key idea: Scheduled, non-interactive pipelines belong on job compute or serverless jobs, not on a shared all-purpose cluster.

Question 4 of 5

A nightly job runs INSERT INTO sales_silver SELECT * FROM staging_sales on a Delta table. The cluster is terminated by an out-of-memory error after the write has produced some data files but before the job finished. What does a reader querying sales_silver see afterwards?

AAn error on every query until someone runs VACUUM, since the orphaned files make the table state inconsistent for readers

BThe partial rows from the files written before the failure, because Delta appends each data file to the table as soon as it is written

COnly the rows from the first half of the job, since Delta rolls back the failed commit but keeps the files that were completed

DThe table in its state before the failed job, because the files are added to the table only when the transaction log commit succeeds

Show answer

✅ Answer: D

Difficulty: applied · Topic: Delta Lake

How Delta Lake provides atomicity
A Delta table is a set of Parquet data files plus a transaction log (the _delta_log folder). The log records each commit as an ordered list of actions, such as "add this file" or "remove that file". Readers build the table from the log, not by listing files in the folder.
• A write first creates new data files, which at that point belong to no table version.
• The write becomes visible only when the commit entry is atomically added to the log.
• If the job dies before the commit, the files stay orphaned and no reader ever sees them.
This is the A (atomicity) of ACID: a transaction either fully applies or not at all. The orphaned files are removed later by VACUUM.

Why each option works or fails
• ✗ A. Errors until VACUUM: orphaned files are invisible to readers and cause no query errors. VACUUM only reclaims their storage space later.
• ✗ B. Partial rows: Delta never appends files to the table as they are written. Files count only after the log commit, which is why readers cannot see half-finished writes.
• ✗ C. Partial rollback: there is no half-commit; a failed transaction leaves no rows visible at all, not the ones finished before the failure.
• ✓ D. Readers see the previous table state (correct): the data files from the failed job are not referenced by any commit in the transaction log, so the table behaves as if the job never ran.

🎯 Key idea: Delta data files become part of a table only when the transaction log commit succeeds, so failed writes are invisible.

Question 5 of 5

A team creates a table with CREATE TABLE main.sales.orders (id BIGINT, amount DECIMAL(10,2)) and no USING clause in a Unity Catalog enabled workspace. In which storage format is the table created?

AParquet, because it is the open file format that Spark uses when a table definition does not name any other format

BDelta Lake, because it is the default table format on Databricks when the format is not specified

CCSV, because the schema contains only simple types and Spark writes a delimited text file when no format is named

DApache Iceberg, because Unity Catalog managed tables use that format whenever the statement omits the format clause

Show answer

✅ Answer: B

Difficulty: applied · Topic: Delta Lake, Unity Catalog

Delta Lake as the default
Delta Lake is the optimized storage layer under tables on Databricks. It extends Parquet data files with a file-based transaction log, which adds ACID transactions, time travel and scalable metadata handling. It is open source and is the default format for all operations on Databricks: unless you name another format, tables are Delta tables.
• Other formats exist (USING PARQUET, USING CSV), but they lack the transaction log and its guarantees.
• A Delta table's data files are still Parquet, which is why the log, not the files alone, defines the table.

Why each option works or fails
• ✗ A. Parquet: the data files inside a Delta table are Parquet, but the table format is Delta, because Databricks defaults to it rather than to plain Parquet.
• ✓ B. Delta Lake (correct): without a USING clause Databricks creates a Delta table, giving the new table transactions, history and time travel from the start.
• ✗ C. CSV: plain CSV would have to be requested explicitly, and a table in that format has no ACID guarantees. It is never the default.
• ✗ D. Iceberg: Iceberg is supported through interoperability features but must be requested. The default is still Delta Lake.

🎯 Key idea: On Databricks, a table with no format clause is a Delta table.

🔗 Keep practicing on this blog

• All DBX-DEA practice sets
• Every exam on this blog

📚 Beyond this set

More DBX-DEA questions: https://hyunhp.github.io/cert-bank/#exam=DBX-DEA
Study guide: https://hyunhp.github.io/cert-bank/study.html#exam=DBX-DEA

These are original practice questions, not real exam questions, and cert-bank is not affiliated with any certification vendor.

Original practice questions written for this blog, not exam dumps.