How to pass Databricks Certified Data Engineer Associate

How this exam thinks

What each domain tests and how to study it

The Data-Engineer-Associate blueprint is split across 7 domains. Weights are the official share of the exam; see the official exam guide for the authoritative breakdown.

1. Databricks Intelligence Platform

   6% of exam

   What you must be able to do. Name the parts of the platform and pick the right compute for a stated workload, including when serverless is the answer and when it is not.

   In one sentenceThe lay of the land: workspace, lakehouse, Unity Catalog and the compute options, and how to choose between them for a given job.

   Recall check: answer these from memory first

   • Say in one line what runs in the control plane and what runs in the compute plane.
   • Name the SQL warehouse types and the single thing that distinguishes a serverless one from the others.
   • Give the workload shape that makes job compute the right answer over all-purpose compute.

   What it tests. The architecture of the platform and what each component is for: the workspace, the control plane and compute plane split, the lakehouse model, Delta Lake as the storage format and Unity Catalog as the governance layer. It also tests compute selection, which is where most of the marks are: all-purpose versus job compute, SQL warehouse types, serverless versus classic, and the standard and dedicated access modes.

   How to study it. Learn compute selection as a decision, not a list. For each workload shape, say out loud which compute you would attach and why: an interactive notebook, a scheduled ETL job, a BI dashboard that must respond in seconds after an idle morning, a shared cluster several analysts use at once. Then learn what each choice costs you, because the exam likes scenarios where the obvious compute is technically able to do the job and wrong on startup time or on isolation.

   Easy to confuse

   • All-purpose compute versus job compute. All-purpose compute is shared and interactive, stays up between uses and is priced accordingly; job compute is created for a scheduled run and terminates when the run ends. If the scenario is a notebook someone is typing in, it is all-purpose; if it is a scheduled pipeline, job compute is both cheaper and more isolated.
   • Serverless versus classic compute. Serverless compute is provisioned by Databricks and starts in seconds; classic compute provisions instances in your own cloud account and takes minutes. The exam plants the startup-time requirement in the scenario, usually as a dashboard or a short interactive burst that cannot wait.
   • Standard versus dedicated access mode. Standard access mode isolates several users on one compute resource and is the default for shared work; dedicated access mode binds the compute to a single user or group. The scenario names either multiple concurrent users or a workload that needs a single identity, and that names the mode.

   Worked example from the Data-Engineer-Associate bank

   lock_openFree sampleDatabricks Intelligence Platformmedium

   A Delta table sets delta.logRetentionDuration to 30 days and keeps the default file retention for VACUUM. After a routine VACUUM run, an analyst queries the table with VERSION AS OF set to a version that was committed twenty days ago. What is the expected outcome?

   VACUUM prod.sales.orders;
   SELECT * FROM prod.sales.orders VERSION AS OF 118;

   • AThe query returns the rows as they stood at that version, because the log entry describing the version is retained for the full thirty days.
   • BThe query is rejected before execution, because VERSION AS OF can only address versions committed within the past seven days on any Delta table.
   • CThe query returns an empty result set, because VACUUM rewrites each historical version of the table so that it contains no rows at all.
   • DThe query fails, because VACUUM has removed data files that the twenty-day-old version still references, even though the log entry for that version survives.check_circle Correct

   Delta Lake time travel needs the data files as well as the log entry, so VACUUM retention limits how far back a query can reach. A Delta table version is a list of data files recorded in the transaction log. Log retention governs how long that list is kept, while VACUUM governs how long the files themselves are kept once no current version references them. When the two settings disagree, the shorter file retention wins in practice, because a version whose files have been deleted cannot be reconstructed and the read fails.

   Why A is wrong: This is tempting because the log retention setting really is thirty days, but a log entry only lists the data files a version needs; it does not keep those files alive once VACUUM has removed them.

   Why B is wrong: Seven days is the default VACUUM file retention rather than a fixed limit on time travel syntax, so this invents a hard rule that Delta Lake does not enforce on the query itself.

   Why C is wrong: VACUUM only deletes files that the current version no longer references and never rewrites historical versions, so an empty result would misrepresent what the command does.

   Why D is correct: Correct, because time travel needs both the log entry and the data files it points to, and VACUUM deletes unreferenced files older than the retention threshold regardless of log retention.

2. Data Ingestion and Loading

   21% of exam

   What you must be able to do. Choose the right ingestion mechanism for a stated file volume, arrival pattern and latency target, and configure it correctly.

   In one sentenceGetting data in: Auto Loader, COPY INTO, Lakeflow Connect and JDBC, and the file-volume and latency signals that decide between them.

   Recall check: answer these from memory first

   • Describe what Auto Loader does under the default schema evolution mode the first time an unseen column arrives, and what happens on restart.
   • Say why rerunning the same COPY INTO statement over the same path does not duplicate rows.
   • Name the four JDBC options that make Spark read a large table in parallel.

   What it tests. The ingestion surface end to end. Auto Loader and its cloudFiles options, including schema inference, the schema location, schema hints, the rescued data column and what each schema evolution mode actually does when an unseen column arrives. COPY INTO and its idempotency. Lakeflow Connect for applications and operational databases. Reading from JDBC sources, and the partitioning options that turn a single-connection read into a parallel one. Semi-structured data, volumes and the difference between a governed path and the legacy DBFS root.

   How to study it. Build the Auto Loader mental model first, because it carries the most questions. Know what happens on the very next micro-batch when a new column appears under the default evolution mode, and why restarting the stream then succeeds. Then drill the Auto Loader versus COPY INTO choice until it is automatic: the signals are file count over time, whether the same statement may be rerun, and how low the latency needs to be. Finally, get the JDBC parallel-read options right by name, because a question will simply hand you a slow single-threaded read and ask what to add.

   Easy to confuse

   • Auto Loader versus COPY INTO. Auto Loader tracks processed files in a scalable checkpoint and can learn about arrivals from cloud notifications, so it stays efficient into the millions of files; COPY INTO records loaded files per target table and suits a bounded, periodic top-up. File volume over the life of the directory is the signal the exam plants.
   • The rescued data column versus schema evolution. The rescued data column captures values that did not fit the current schema and keeps the stream running; schema evolution changes the schema itself. Rescue mode has to be requested, so a question that describes rescue behaviour under default settings is describing something that will not happen.
   • A Unity Catalog volume versus the DBFS root. A volume is a governed location inside the Unity Catalog namespace with its own READ VOLUME and WRITE VOLUME privileges; the DBFS root is legacy, ungoverned storage. Any scenario with an access-control requirement on files is asking for a volume.

   Worked example from the Data-Engineer-Associate bank

   lock_openFree sampleData Ingestion and Loadingmedium

   A team lands CSV files in a cloud storage folder each hour and loads them into a Delta table with a COPY INTO statement that is rerun on a schedule against the same folder. Files are retained in the folder for thirty days. What happens to a file that a previous run has already loaded successfully?

   COPY INTO prod.raw.events
   FROM 's3://landing/events/'
   FILEFORMAT = CSV
   FORMAT_OPTIONS ('header' = 'true')

   • AIt is read again on every run, so the table accumulates a duplicate copy of each retained file until the folder is emptied.
   • BIt is skipped, because COPY INTO records the files it has loaded for that target table and ingests each one at most once.check_circle Correct
   • CIt is read again unless the statement sets a rescued data column, which is the setting that suppresses files loaded by an earlier run.
   • DIt is read again unless a checkpoint location is supplied, since COPY INTO stores its list of loaded files in that checkpoint directory.

   COPY INTO records which files it has loaded into a target table, so rerunning it against the same folder ingests each file at most once. COPY INTO keeps per-target metadata listing the source files it has already ingested. On each run it compares the folder contents against that record and loads the files it has not seen, which makes repeated scheduled runs idempotent without any streaming checkpoint or manual bookkeeping.

   Why A is wrong: This is the behaviour of a plain read of the folder followed by an append, and candidates often assume COPY INTO works the same way. COPY INTO differs because it maintains its own record of loaded files against the target table.

   Why B is correct: COPY INTO tracks the files it has already ingested for the target table, so rerunning the same statement loads the files that have appeared since the previous run and leaves the rest alone.

   Why C is wrong: The rescued data column captures fields that do not match the expected schema, and it plays no part in deciding which files are ingested. Skipping loaded files is built into COPY INTO itself.

   Why D is wrong: Checkpoint locations belong to Structured Streaming sources such as Auto Loader, and COPY INTO does not take one. Its idempotency comes from metadata held against the target table.

3. Data Transformation and Modeling

   22% of exam

   What you must be able to do. Transform data correctly in PySpark and SQL, and model it through bronze, silver and gold in a way the exam recognises.

   In one sentenceThe largest domain: joins, unions, explode, deduplication, aggregation, quality checks and the medallion layers, plus the Spark behaviour that decides what a transformation actually returns.

   Recall check: answer these from memory first

   • Two tables, one key value duplicated three times on the left and twice on the right: how many rows does an inner join on that key return?
   • What does explode produce for a row whose array is empty, and for a row whose array is null?
   • Give the one-line rule for what belongs in silver and what belongs in gold.

   What it tests. Transformation in both PySpark and SQL, and the medallion model that organises it. Joins and what each join type returns when keys are missing or duplicated, union versus unionByName, explode and its behaviour on empty and null arrays, deduplication, aggregation, window functions, and casting under ANSI mode. Bronze to silver cleaning, data quality checks and expectations, and the gold-layer objects that serve reporting. It is the heaviest domain on the exam.

   How to study it. Practise predicting output, not describing concepts. Given two small tables with duplicate keys, say how many rows the join returns before you reason about anything else; the exam asks this directly. Do the same for explode on a row whose array is empty and on a row whose array is null, because those two cases differ and the difference is examinable. Learn what ANSI mode does to a cast that cannot succeed, since the platform default changed the old silent-null behaviour. Then walk a real table from bronze through silver to gold and name what each layer is allowed to assume about the one before it.

   Easy to confuse

   • union versus unionByName. union combines by column position and unionByName combines by column name. If the two DataFrames have the same columns in a different order, union silently produces wrong data while unionByName is correct, which is exactly the scenario the exam builds.
   • explode versus explode_outer. explode drops the row entirely when the array is empty or null; explode_outer keeps the row and emits a null. A requirement to retain every input row is the signal for the outer variant.
   • A cast under ANSI mode versus the legacy permissive behaviour. Under ANSI mode a cast that cannot succeed raises an error rather than returning null, and TRY_CAST is the way to ask for a null instead. Older material describes the permissive behaviour, so read the requirement for whether a failure should surface or be tolerated.

   Worked example from the Data-Engineer-Associate bank

   lock_openFree sampleData Transformation and Modelingmedium

   A bronze table holds a column amount_raw typed STRING, in which most values look like 19.99 while a small share hold the text n/a. A silver load must produce a DECIMAL(10,2) column, must not fail when it meets an unparseable value, and must keep those rows in the silver table with a missing amount. The workspace runs with ANSI behaviour in effect. Which expression meets the requirement, and why?

   -- silver load, one expression per candidate
   SELECT order_id, <expression> AS amount FROM bronze.orders

   • AUse CAST(amount_raw AS DECIMAL(10,2)), because a cast to a decimal type substitutes NULL for a value it cannot parse and lets the load continue.
   • BUse TRY_CAST(amount_raw AS DECIMAL(10,2)), because it returns NULL for a value it cannot parse and leaves the row present in the silver table.check_circle Correct
   • CUse CAST(CAST(amount_raw AS DOUBLE) AS DECIMAL(10,2)), because routing the value through a floating point type suppresses the parse error before the decimal conversion.
   • DUse CAST(amount_raw AS DECIMAL(10,2)) after filtering out rows whose amount_raw does not match a numeric pattern, because a silver row cannot carry a missing amount.

   TRY_CAST returns NULL for values it cannot convert, while CAST raises a runtime error under ANSI behaviour. Under ANSI behaviour a CAST that cannot represent its input in the target type raises a runtime error and aborts the query. TRY_CAST applies the identical conversion rules but returns NULL on failure, which is the supported way to standardise a dirty string column into a typed silver column while preserving the offending rows for later inspection.

   Why A is wrong: Tempting because CAST did behave this way under the legacy non-ANSI behaviour, where a failed cast returned NULL. With ANSI behaviour in effect a failed cast raises a runtime error and the load fails, which the requirement forbids.

   Why B is correct: Correct. TRY_CAST performs the same conversion as CAST but yields NULL instead of raising an error when the input cannot be represented in the target type, so unparseable rows survive with a missing amount.

   Why C is wrong: Tempting because a double is more permissive about scale than a decimal. The first cast still has to parse the string n/a and fails under ANSI behaviour, so the error occurs before the second cast is reached.

   Why D is wrong: Tempting because filtering does avoid the error. It discards the affected rows, whereas the requirement states they must remain in the silver table with a missing amount, and silver tables can hold nullable columns.

4. Working with Lakeflow Jobs

   16% of exam

   What you must be able to do. Build a multi-task job with the right dependencies, triggers and failure handling, and know what each setting does when a run goes wrong.

   In one sentenceOrchestration: tasks and dependencies, the trigger types, task values and parameters, retries, repair runs and the concurrency settings that stop a job overlapping itself.

   Recall check: answer these from memory first

   • Name the trigger types and say in one line what each one is watching.
   • A cron job sometimes runs longer than its interval. Which setting stops two runs overlapping, and what becomes of the trigger that fires during a run?
   • Explain what a repair run re-executes and what it leaves alone.

   What it tests. Lakeflow Jobs as an orchestrator. Tasks and their dependencies, conditional execution, iterating a task over a collection, and passing values between tasks. The trigger types and what each one fires on: a cron schedule, continuous, and file arrival. Retries, repair runs and how a partially failed job is resumed. Maximum concurrent runs and run queueing. Which compute a task attaches to, including shared job clusters.

   How to study it. Draw a job with four tasks and a branch, then say for each setting what would change if you altered it. Learn the trigger types by what they watch rather than by name. Then take the overlap scenario seriously, because it recurs: a cron job whose runtime exceeds its interval will start a second run on top of the first, and knowing which setting prevents that, and what happens to the skipped trigger, is worth real marks. Finally, understand a repair run as re-running only what failed and what depended on it, not the whole job.

   Easy to confuse

   • A time-based trigger versus a file-arrival trigger. A schedule fires on the clock whether or not there is anything to do; a file-arrival trigger watches a governed storage location and starts a run when new files appear. A scenario with unpredictable arrival times and mostly empty scheduled runs is asking for file arrival.
   • Retries versus a repair run. Retries are automatic and re-attempt a task that failed within the same run; a repair run is a manual re-execution of the failed tasks of a completed run. If the question is about recovering after the run has finished, it is repair.
   • Maximum concurrent runs versus run queueing. The concurrency limit caps how many runs of one job are active together; queueing decides what happens to a trigger that arrives when the limit is reached. With queueing off the trigger is skipped, with it on the run waits, so a requirement to drop rather than defer needs both settings.

   Worked example from the Data-Engineer-Associate bank

   lock_openFree sampleWorking with Lakeflow Jobshard

   A Lakeflow Job graph contains an If/else condition task named check_volume. Two tasks hang off it: load_full depends on the true outcome and load_incremental depends on the false outcome. A fourth task named publish depends on load_full alone, with its Run if condition left at the default. On tonight's run the condition evaluates to false and load_incremental completes successfully. What is the state of load_full, publish and the run as a whole?

   • Aload_full is skipped, publish is marked failed because a dependency did not succeed, and the run is reported as failed even though load_incremental finished.
   • Bload_full is skipped, publish is skipped because its only dependency did not succeed, and the run is reported as successful because no task failed.check_circle Correct
   • Cload_full is marked failed because the condition ruled it out, publish is skipped, and the run is reported as failed because a task on the untaken branch carries a failure state.
   • Dload_full is skipped, publish still runs because a skipped dependency counts as a success under the default Run if condition, and the run is reported as successful.

   An untaken condition branch is skipped, that skip propagates to dependants under the default Run if condition, and skips do not fail the run. The If/else condition task resolves to exactly one outcome and the tasks wired to the other outcome are skipped. Skipping is a terminal state distinct from failure, so it propagates down the dependency chain under the default Run if condition of All succeeded while leaving the overall run result successful.

   Why A is wrong: It is tempting because the default Run if condition does block publish, but a dependency that was skipped produces a skipped task rather than a failed one, and a skipped task does not fail the run.

   Why B is correct: The false outcome skips the true branch, the default Run if condition of All succeeded propagates that skip to publish, and a run made up of successful and skipped tasks is reported as successful.

   Why C is wrong: This mistakes the untaken branch for an error. A condition task selects a branch, so the branch that was not selected is skipped, and a skipped task is not a failure state.

   Why D is wrong: The outcome for the run is right but the mechanism is wrong: All succeeded requires the dependency to have actually succeeded, so a skipped dependency skips publish rather than releasing it.

5. Implementing CI/CD

   10% of exam

   What you must be able to do. Promote workspace assets between environments with bundles and Git folders, and know what each CLI step does and does not touch.

   In one sentencePromotion and source control: Declarative Automation Bundles, their targets and variables, the CLI verbs, and how Databricks Git Folders fit a branching workflow.

   Recall check: answer these from memory first

   • Rank the sources of a bundle variable's value from strongest to weakest.
   • Say what bundle validation changes in the target workspace.
   • Describe how a change made in a Databricks Git Folder reaches a production deployment.

   What it tests. Declarative Automation Bundles, formerly Databricks Asset Bundles, as the packaging and promotion mechanism: the configuration file, resources, targets, deployment modes, and variables including how a value supplied on the command line ranks against a target's own value and the declared default. The CLI verbs and what each one changes. Databricks Git Folders for source control inside the workspace, and how a branch-based workflow reaches a deployment.

   How to study it. Get the precedence order for variables exact, because the exam asks it directly: a value passed on the deploy command outranks the target's mapping, which outranks the declared default. Then learn the CLI verbs by their side effects rather than their names, and in particular be clear that validation resolves and reports without creating, updating or deleting anything in the workspace. That read-only property is the whole reason validation belongs in a pull-request gate, and it is the point most questions are built on.

   Easy to confuse

   • Validating a bundle versus deploying it. Validation parses the configuration, applies the selected target's overrides and resolves variables, then reports the result without touching the workspace; deploying uploads artefacts and creates or updates resources. A pull-request gate wants the one that writes nothing.
   • A development target versus a production target. Development mode prefixes deployed resources and isolates them per user so several engineers can deploy the same bundle without collision; production mode deploys under the declared names. The scenario names either parallel engineers or a single shared deployment.
   • A Git folder versus a bundle. A Git folder brings source control into the workspace so notebooks can be branched and reviewed; a bundle packages and promotes the resources themselves. Source-control questions are folders, promotion questions are bundles.

   Worked example from the Data-Engineer-Associate bank

   lock_openFree sampleImplementing CI/CDmedium

   A data engineer has finished work on a feature branch inside a Databricks Git folder linked to a hosted Git provider. The team requires the change to be reviewed before it reaches the main branch. Which sequence reflects how the workspace UI and the Git provider divide that work?

   • ACommit and push the branch from the Git folder dialog, then open, review and merge the pull request in the linked Git provider, which the dialog links out to.check_circle Correct
   • BPush the branch from the Git folder dialog and then run a merge command in a notebook cell, so that the branch is combined into main from inside the workspace.
   • CCreate the pull request from the Git folder dialog, which raises the request inside the workspace and merges the branch as soon as a reviewer approves it there.
   • DAsk a workspace administrator to merge the branch from the admin settings page, because branches in Databricks Git Folders are governed at the account level.

   Databricks Git Folders performs branch, commit and push operations, while pull request review and merge happen in the linked Git provider. A Git folder is a working copy of a remote repository inside the workspace. Its dialog can create a branch, stage a commit and push that commit to the remote, but the repository's review workflow is a feature of the hosting provider, so the pull request is opened and merged there and the workspace simply links out to it.

   Why A is correct: Correct, because Databricks Git Folders handles the branch, commit and push, while the pull request itself lives in the provider that hosts the repository.

   Why B is wrong: It is tempting because notebooks can run shell commands, but a Git folder is not a general command line checkout and merging this way bypasses the review the team requires.

   Why C is wrong: Plausible because the dialog does mention pull requests, but the workspace hosts no review surface of its own; approval and merge belong to the linked provider.

   Why D is wrong: Tempting for teams used to central control, but admin settings govern the Git provider integration and credentials, not the branch history of a linked repository.

6. Troubleshooting, Monitoring, and Optimization

   10% of exam

   What you must be able to do. Read a symptom and name its cause, then pick the maintenance or tuning action that addresses that cause rather than its symptom.

   In one sentenceDiagnosis: skew, spill and driver memory in the Spark UI, cluster and library faults, pipeline health, and the layout work that OPTIMIZE, VACUUM, liquid clustering and predictive optimization do.

   Recall check: answer these from memory first

   • A handful of tasks in one stage run far longer than the rest. Name the cause and the fix that addresses it.
   • Which tables does predictive optimization maintain, and which are left for you to schedule?
   • Say what stops you from adding liquid clustering to an existing partitioned table.

   What it tests. Reading a failing or slow workload and naming the cause. Spark UI signals for skew, spill and shuffle cost. Driver out-of-memory faults, including the collect-to-driver and broadcast cases. Cluster library problems and the difference between cluster-scoped and notebook-scoped installs. Job run history and pipeline health. Table maintenance and layout: OPTIMIZE, VACUUM, liquid clustering, and what predictive optimization runs on your behalf and on which tables.

   How to study it. Work backwards from symptoms. Take each of the common failures in turn, a few tasks far slower than the rest, a driver that dies on a large result, a job that got steadily slower over months, and say what causes it and which action addresses that cause rather than papering over it. Adding memory is almost always the distractor. On maintenance, be exact about which tables predictive optimization covers, because the boundary between managed and external tables is examinable, and about the fact that liquid clustering cannot be layered onto a table that already has partition columns.

   Easy to confuse

   • Data skew versus general under-provisioning. Skew shows as a few tasks far slower than the rest in the same stage while the cluster is otherwise idle; under-provisioning slows everything evenly. The exam plants an add-more-workers distractor on a skew scenario, where it buys almost nothing.
   • Driver out-of-memory versus executor out-of-memory. The driver dies when a large result is pulled back to it or a broadcast is too big; an executor dies on its own partition of the data. Collecting a large DataFrame names the driver, so the fix is to stop pulling the data back rather than to resize the workers.
   • A cluster-scoped library versus a notebook-scoped install. A cluster library is installed through the compute configuration and applies to every session on that cluster; a notebook-scoped install builds an environment for the calling notebook alone and leaves the others on the cluster version. A requirement to change one notebook without disturbing the others names the notebook-scoped route.

   Worked example from the Data-Engineer-Associate bank

   lock_openFree sampleTroubleshooting, Monitoring, and Optimizationmedium

   A Delta table in Unity Catalog is partitioned by event_date and is queried mostly by customer_id, which filters poorly because it is not a partition column. The team decides to move the table to liquid clustering on customer_id and event_date, and recreates it with the statement below. Which two statements correctly describe what liquid clustering means for the new table? (Select TWO.)

   CREATE OR REPLACE TABLE prod.events.page_views
   CLUSTER BY (customer_id, event_date)
   AS SELECT * FROM prod.events.page_views_legacy;

   • AA table that uses liquid clustering cannot also declare partition columns, which is why the move required the table to be recreated rather than altered in place.check_circle Correct
   • BClustering keys are fixed at table creation, so a later change in the team's query filters would require the table to be recreated and reloaded from the source data.
   • CClustering keys can be revised later with an ALTER TABLE statement carrying a new CLUSTER BY clause, and files already written stay as they are until a later OPTIMIZE run.check_circle Correct
   • DZ-ordering should be applied over the same two columns during each OPTIMIZE run, so that data skipping keeps working alongside the declared clustering keys.
   • EEach clustering key must be a generated column derived from the ingest timestamp, so that the resulting layout follows the order in which the rows arrived at the table.

   Liquid clustering replaces partitioning and Z-ordering on a Delta table, and its keys can be redeclared later without an immediate rewrite. Liquid clustering is an alternative to partition directories and to Z-ordering, so a clustered table carries neither, and a partitioned table has to be recreated to adopt it. Because the keys only direct how future writes and OPTIMIZE runs arrange files, redeclaring them later with ALTER TABLE takes effect gradually rather than rewriting the existing files at once.

   Why A is correct: Liquid clustering and Hive style partitioning are alternative layout strategies on a Delta table, and clustering cannot be added to a table that already carries partition columns.

   Why B is wrong: This is tempting because partition columns really are fixed for the life of a table, but clustering keys are deliberately not: they can be redeclared at any time.

   Why C is correct: Redeclaring the keys changes the layout that future writes and future OPTIMIZE runs target; it does not rewrite history at the moment the statement is issued.

   Why D is wrong: It sounds like belt and braces, but ZORDER BY is not supported on a liquid clustered table; the clustering keys are what OPTIMIZE uses to lay the data out.

   Why E is wrong: Generated columns are a real Delta feature often used with partitioning, which makes this plausible, but liquid clustering places no such requirement on its keys.

7. Governance and Security

   15% of exam

   What you must be able to do. Grant exactly the access a scenario requires through Unity Catalog, and predict what happens to the data when an object is dropped.

   In one sentenceUnity Catalog: the three-level namespace, privilege inheritance, GRANT and REVOKE and DENY, row filters and column masks, attribute-based policies, and managed versus external table semantics.

   Recall check: answer these from memory first

   • A user has SELECT on a table and the query still fails. Name the two privileges to check above it.
   • What happens to the underlying files when you drop a managed table, and when you drop an external one?
   • Say where a row filter is enforced, and whether changing the query surface can get around it.

   What it tests. Unity Catalog as the governance layer. The metastore, catalog, schema and object hierarchy and how privileges inherit down it, including the USE CATALOG and USE SCHEMA privileges that a SELECT alone does not imply. GRANT, REVOKE and DENY and how a denial interacts with an inherited grant. Row filters and column masks and where they are enforced. Attribute-based policies. Managed versus external tables, external locations and storage credentials, and what DROP TABLE does to the underlying files in each case.

   How to study it. Draw the hierarchy once and keep it in front of you: metastore, catalog, schema, table. Then for every access question, walk the whole path rather than checking the table grant alone, because the exam's favourite scenario is a correct SELECT with a missing USE somewhere above it. Learn the managed versus external distinction by its consequence: dropping a managed table deletes its files, dropping an external one leaves them, and that single consequence is what most of these questions are really asking. Know that an external table can be converted in place to a managed one, and by which statement.

   Easy to confuse

   • A managed table versus an external table. Unity Catalog owns a managed table's storage lifecycle and deletes the files on DROP TABLE; an external table's files sit at a path you supplied inside a registered external location and survive the drop. The presence of a LOCATION clause is the tell in the code, and the consequence on drop is what the question usually wants.
   • REVOKE versus DENY. REVOKE removes a grant that was made; DENY blocks access regardless of any grant inherited from above. A requirement to exclude one group from access that everyone else inherits is asking for a denial, not a revocation.
   • A row filter versus a column mask. A row filter decides which rows an identity sees; a column mask transforms the values in a column for identities that should not see them raw. Hiding a whole category of records is a filter, obscuring a card number in records the user may otherwise see is a mask.

   Worked example from the Data-Engineer-Associate bank

   lock_openFree sampleGovernance and Securityhard

   An administrator runs the grant below so that members of the account group analysts can read a Unity Catalog table. The grant succeeds, but an analyst querying prod.sales.orders from a SQL warehouse receives an error saying the table cannot be found. The table exists and the analyst is in the group. What explains the behaviour?

   GRANT SELECT ON TABLE prod.sales.orders TO `analysts`;

   • AThe analyst also needs USE CATALOG on prod and USE SCHEMA on prod.sales, because every parent securable in the path must be traversable before SELECT applies.check_circle Correct
   • BThe SELECT privilege applies to the table owner's own sessions, so the analyst needs an equivalent grant issued at the metastore level instead.
   • CSQL warehouses resolve privileges through the workspace Hive metastore, so the same grant has to be repeated there before the table becomes visible.
   • DTable level grants take effect at the next warehouse restart, so the analyst has to wait for the privilege cache on the SQL warehouse to be rebuilt.

   Reading a Unity Catalog table requires USE CATALOG and USE SCHEMA on the parent securables in addition to SELECT on the table. Unity Catalog authorises a query by walking the full securable path from catalog to schema to table. The USE CATALOG and USE SCHEMA privileges make each parent traversable; without them the name cannot be resolved at all, so the engine reports that the object does not exist rather than revealing that a privilege is missing.

   Why A is correct: Correct, because Unity Catalog evaluates the whole path to a securable, and without USE CATALOG on the catalog and USE SCHEMA on the schema the analyst cannot resolve the name, which surfaces as a table not found error rather than a permission error.

   Why B is wrong: Tempting because metastore administrators can see everything, which suggests privileges must be assigned high in the hierarchy, but SELECT granted on a table applies to the named principal, not to the owner alone, and Unity Catalog does not require a metastore level grant for ordinary reads.

   Why C is wrong: Plausible for anyone who remembers the legacy table access control model, but a three level name such as prod.sales.orders is resolved by Unity Catalog, and the workspace Hive metastore is a separate legacy catalog that holds no privileges for it.

   Why D is wrong: Attractive because caching does explain some delayed behaviour in distributed systems, but Unity Catalog grants are evaluated per statement against the metastore, so a restart would change nothing while the traversal privileges are missing.

A study plan that works

1. Get current on the platform and its 2026 names

   Week 1

   Walk the architecture and the compute options, and make a short list of the renamed components: Lakeflow Jobs, Lakeflow Spark Declarative Pipelines, Lakeflow Connect, Declarative Automation Bundles and Databricks Git Folders. Older tutorials are still useful, but the exam uses the current names and you should not meet one for the first time in a question.

2. Build one real pipeline end to end

   Week 1

   In a workspace, land files with Auto Loader, clean them into a silver table, aggregate into gold, and schedule the whole thing as a multi-task job. Everything in the two heaviest domains is easier to remember once you have watched it run, and the failures you hit along the way are the exam's favourite scenarios.

3. Drill ingestion and transformation, the two heaviest domains

   Weeks 2-3

   These carry the largest share of the exam between them. Practise predicting output on joins, unions and explode, and get the Auto Loader schema-evolution behaviour and the COPY INTO idempotency guarantee exact rather than approximately right.

4. Work through orchestration and governance

   Week 3

   Cover Lakeflow Jobs triggers, dependencies and failure handling, then Unity Catalog's hierarchy, privilege inheritance and the managed versus external distinction. Both domains reward walking a complete path rather than recalling a single fact.

5. Cover CI/CD and troubleshooting

   Week 4

   Learn the bundle variable precedence order and what each CLI verb touches, then practise reading symptoms back to causes: skew, spill, driver memory, and the maintenance operations that address table layout rather than compute size.

6. Practise on scenarios with every option explained

   Week 4

   Move to full practice sets and read the explanation on every question, including the ones you got right. This exam separates candidates on the plausible wrong answer, so knowing why a distractor fails is where the marks are.

7. Close your weak domains, then sit a timed mock

   Week 5

   Use per-domain accuracy to pick the two domains dragging you down rather than re-reading what you already know. Then take at least one full timed run to rehearse pacing, and review every missed item before you book.

Know when you're ready

Exam-day tips

• Read the requirement in the last line first, then judge each option against it. Several options will be true statements about the platform and only one answers what was asked.
• Ask which option you have actually watched happen. This exam is built on the gap between what sounds reasonable and what the engine does.
• On any access question, walk the whole path. A SELECT grant with a missing USE CATALOG or USE SCHEMA above it is the exam's favourite trap.
• When a scenario names file volume or arrival pattern, it is choosing between Auto Loader and COPY INTO. Let the growth of the directory decide.
• For a row-count question, work out the answer on paper before reading the options. The options are designed to be individually plausible.
• Adding memory or workers is usually the distractor. Name the cause first, then pick the action that addresses that cause.
• Flag and move on. An unfamiliar product name is often a renamed thing you already know, and it will surface later while you are answering something easier.

Frequently asked questions

Related certifications

Other Cloud certifications with a study guide.

• Google Cloud Professional Data Engineer (PDE) study guideGoogle Cloud
• Microsoft Azure Administrator (AZ-104) study guideMicrosoft
• Microsoft Azure Data Fundamentals (DP-900) study guideMicrosoft
• Microsoft Power Platform Fundamentals (PL-900) study guideMicrosoft
• Microsoft 365 Certified: Endpoint Administrator Associate (MD-102) study guideMicrosoft
• Microsoft 365 Administrator (MS-102) study guideMicrosoft
• Microsoft Power BI Data Analyst (PL-300) study guideMicrosoft
• Designing Microsoft Azure Infrastructure Solutions (AZ-305) study guideMicrosoft
• Designing and Implementing Microsoft DevOps Solutions (AZ-400) study guideMicrosoft
• Microsoft Azure Fundamentals (AZ-900) study guideMicrosoft
• AWS Certified Solutions Architect - Associate (SAA-C03) study guideAmazon Web Services
• AWS Certified CloudOps Engineer - Associate (SOA-C03) study guideAmazon Web Services
• AWS Certified Developer - Associate (DVA-C02) study guideAmazon Web Services
• AWS Certified Cloud Practitioner (CLF-C02) study guideAmazon Web Services
• AWS Certified Solutions Architect - Professional (SAP-C02) study guideAmazon Web Services
• AWS Certified DevOps Engineer - Professional (DOP-C02) study guideAmazon Web Services
• SnowPro Core Certification (COF-C03) study guideSnowflake
• Microsoft Fabric Analytics Engineer Associate (DP-600) study guideMicrosoft
• GitHub Actions (GH-200) study guideGitHub
• Microsoft Fabric Data Engineer (DP-700) study guideMicrosoft
• Tableau Certified Data Analyst (Analytics-DA-201) study guideTableau
• Kubernetes and Cloud Native Associate (KCNA) study guideCloud Native Computing Foundation
• Google Cloud Associate Cloud Engineer (GCP-ACE) study guideGoogle Cloud
• HashiCorp Certified: Terraform Associate (TF-Associate-004) study guideHashiCorp