Free Data-Engineer-Associate practice questions

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.

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.

A silver load must discard any bronze row that is missing either customer_id or order_ts, while keeping rows whose remaining columns are null. An engineer runs the code below and finds that rows carrying a null customer_id and a populated order_ts still reach the silver table. Which statement explains the result and gives the correction?

df = spark.read.table("bronze.orders")
clean = df.na.drop(how="all", subset=["customer_id", "order_ts"])
clean.write.mode("append").saveAsTable("silver.orders")

• AThe subset list is ignored once how is supplied, so the call inspected every column in the DataFrame; removing the subset argument makes the two key columns govern the drop.
• BThe call drops a row only when the first column named in the subset holds a null, so listing order_ts before customer_id makes both key columns take effect.
• CThe value all drops a row only when every column named in the subset is null, so the call has to use how set to any for a row missing either key to be dropped.check_circle Correct
• DThe call evaluates the two columns independently and drops a row for a null in either one, so the surviving rows must be reintroduced by the append mode used on the write.

Why A is wrong: Tempting because the two arguments do interact. They are independent: subset restricts which columns are inspected and how decides the threshold, and dropping subset would widen the inspection to every column rather than narrow it.

Why B is wrong: Tempting because the observed rows were null in the first listed column. Order within subset carries no meaning, and if this were true the affected rows would have been dropped rather than retained.

Why C is correct: Correct. With how set to all a row survives unless each column in the subset is null, so a row with one populated key is kept; how set to any drops a row on the first null found among the subset columns.

Why D is wrong: Tempting because it describes the intended behaviour and blames the writer instead. That behaviour belongs to how set to any, and an append write adds the rows it is given without resurrecting filtered ones.

A team is defining the boundary between its bronze and silver layers in a medallion architecture built on Unity Catalog. Ingested files land in bronze in the shape they arrived, and reporting teams read gold aggregates. Which statement describes what the silver layer contributes in this arrangement?

• ASilver holds the payloads exactly as they were received together with ingestion metadata such as source file name and load time, so any transformation can be replayed from it once a defect is found.
• BSilver holds business level aggregates shaped for a particular dashboard, so each reporting team keeps the version of the measures it publishes and reads nothing from the layers beneath it.
• CSilver holds a set of views over bronze that store no data of their own, so cleaning logic runs at query time and the platform keeps a single physical copy of every record.
• DSilver holds validated records whose types have been standardised, whose nulls have been handled and whose duplicates have been resolved, giving the conformed version of the data that gold aggregations are built from.check_circle Correct

Why A is wrong: Tempting because replayability is a genuine goal of the architecture. That description belongs to the bronze layer, which is the immutable landing zone; silver sits downstream of it and holds transformed records.

Why B is wrong: Tempting because aggregation is part of the pipeline. This describes the gold layer, and gold is normally derived from silver rather than isolated from the layers beneath it.

Why C is wrong: Tempting because views do avoid duplicate storage. Silver is normally materialised as Delta tables so that cleaning runs once and downstream reads are cheap and reproducible, rather than recomputed per query.

Why D is correct: Correct. Silver is the cleansed and conformed layer: it applies casting, null handling, deduplication and joins across sources, so downstream aggregation works from a trusted shape rather than from raw payloads.

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.

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.

An engineer runs an Auto Loader stream that reads JSON files from a landing folder and appends them to a Delta table. During a redeployment the checkpoint location is pointed at a new, empty directory while the target table is left in place. What is the effect on the next run of the stream?

(spark.readStream
  .format('cloudFiles')
  .option('cloudFiles.format', 'json')
  .load('/Volumes/main/raw/landing'))

• AThe stream refuses to start and raises an error, because an empty checkpoint directory cannot be reconciled with a target table that already holds rows.
• BThe stream resumes from the position of the previous checkpoint, because the ingestion progress is stored in the target table rather than in the checkpoint.
• CThe stream treats every file in the landing folder as new and appends them all again, producing duplicate rows in the target table.check_circle Correct
• DThe stream processes the files whose modification time is later than the moment the new checkpoint directory was created, and older files are ignored.

Why A is wrong: A fresh checkpoint is a valid starting state and the stream starts cleanly. Auto Loader does not compare the checkpoint against the contents of the sink before starting.

Why B is wrong: This confuses Auto Loader with COPY INTO, whose loaded-file record is held against the target table. Structured Streaming progress lives in the checkpoint directory instead.

Why C is correct: The checkpoint is the record of which files Auto Loader has already ingested, so an empty checkpoint means no file has been seen and the whole folder is reprocessed.

Why D is wrong: A modification-time cutoff can be requested with a start-time option, but it is not applied by default. Without it a fresh checkpoint treats every file in the folder as unseen.

A data team must pull tables from a Salesforce account and from a self-managed PostgreSQL database into Unity Catalog, keeping both refreshed incrementally without writing custom extraction code. Which statement correctly describes how Lakeflow Connect covers these two sources?

• ABoth sources are handled by Auto Loader, which discovers rows through the cloudFiles source once each system has been registered as an external location in Unity Catalog.
• BBoth sources are handled by COPY INTO with a source connection specified in FORMAT_OPTIONS, since that statement is the supported entry point for connector-based ingestion.
• CThe Salesforce application alone is in scope, because Lakeflow Connect covers SaaS applications and databases must instead be exported to files and read with a file source.
• DManaged connectors handle both, with the Salesforce application ingested end to end and database sources such as PostgreSQL ingested through a configured ingestion gateway that captures changes.check_circle Correct

Why A is wrong: Auto Loader is genuinely the incremental ingestion tool for files, which makes it a tempting answer. It reads objects from cloud storage paths and has no ability to connect to an application API or a database.

Why B is wrong: COPY INTO does load data into Delta tables, so it looks relevant, but it reads files of a given format from a storage path. It cannot take an application or database connection as its source.

Why C is wrong: This reflects an earlier and narrower view of the product. Lakeflow Connect covers database sources as well as SaaS applications, so a manual file export is unnecessary.

Why D is correct: Lakeflow Connect provides fully managed connectors for SaaS applications and for operational databases, and the database connectors deploy an ingestion gateway close to the source to capture its changes.

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.

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.

A Lakeflow Job has a task named transform configured with a maximum of three retries and a two minute interval between them, and a dependent task named publish. On tonight's run, transform appends rows to a Delta table and fails part way through, after several thousand rows have already been committed. Which statement describes what the retry policy does here?

• AEach retry resumes the transform task from the point at which it failed, using progress the jobs service records for the task, so the rows already committed are not appended a second time.
• BThe retry count set on transform applies to the whole dependency chain, so publish is retried three times as well once transform has exhausted its own attempts and the run is marked failed.
• CEach retry starts the transform task again from the beginning, so the rows already committed can be appended a second time unless the task is written to be idempotent, and publish begins only after an attempt succeeds.check_circle Correct
• DThe retry policy covers infrastructure failures such as a lost node, so a task that raises an error inside its own code is marked failed on the first attempt and the two minute interval is not used.

Why A is wrong: This borrows the idea of a streaming checkpoint. The jobs service records the attempt outcome, not a resumable position inside the task, so nothing partial is carried into the next attempt.

Why B is wrong: Retries are configured and counted per task. A dependant of a failed task is skipped rather than attempted, so there is nothing for a retry policy on publish to re-run.

Why C is correct: A retry is a fresh attempt at the whole task, so partial side effects from the failed attempt remain in the table and duplication is prevented by the task logic, not by the retry policy.

Why D is wrong: Plausible because cloud failures are the common reason for setting retries, but the policy applies to task failures generally, including an error raised by the task code itself.

A Lakeflow Job runs three ingestion tasks in parallel, and a final task named notify depends on all three. The team requires notify to post a run summary on every run, including runs where one ingestion task fails and runs where a task is skipped, and it must not be held back when a dependency ends in a state other than success. Which Run if condition on notify meets the requirement?

• AAt least one succeeded, which starts notify as soon as any dependency has succeeded and leaves it skipped on a run in which every ingestion task fails.
• BNone failed, which starts notify when every dependency has finished in a state other than failure and leaves it skipped as soon as one ingestion task fails.
• CAll succeeded, the default, which starts notify only when all three ingestion tasks have succeeded and leaves it skipped whenever one fails or is skipped.
• DAll done, which starts notify once every dependency has reached a terminal state, whether that state is success, failure or skipped.check_circle Correct

Why A is wrong: It loosens the default enough to survive a single failure, but it still needs one success, so the run where all three ingestion tasks fail is exactly the run that produces no summary.

Why B is wrong: This tolerates skipped dependencies, which is half of the requirement, but a single failed ingestion task suppresses the summary, and failures are the case the team most wants reported.

Why C is wrong: This is the setting already in place and the reason no summary appears on a bad night, since any non-successful dependency skips the dependent task.

Why D is correct: All done waits only for the dependencies to finish and ignores the outcome, which is the condition designed for cleanup and notification tasks that must run on every path.

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.

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.

The account group support holds SELECT on the schema prod.customer, which contains twelve tables. A governance requirement states that members of support must be unable to read prod.customer.pii_contacts, while their access to the other eleven tables stays exactly as it is. Which single statement satisfies the requirement?

• AREVOKE SELECT ON TABLE prod.customer.pii_contacts FROM `support`, which withdraws the privilege that the group inherited from the parent schema.
• BDENY SELECT ON TABLE prod.customer.pii_contacts TO `support`, which blocks the privilege that the group inherits from the schema for that one table.check_circle Correct
• CREVOKE SELECT ON SCHEMA prod.customer FROM `support`, relying on table level grants that had been issued separately to cover the remaining eleven tables.
• DGRANT SELECT ON SCHEMA prod.customer TO `support` a second time, which re-evaluates inheritance and excludes any table holding personal data.

Why A is wrong: Tempting because REVOKE is the natural counterpart of GRANT, but REVOKE can only remove a privilege that was explicitly granted on that object, and no table level grant exists here, so the inherited SELECT survives untouched.

Why B is correct: Correct, because DENY is evaluated ahead of any inherited grant and is scoped to the securable it names, so the group loses read access to that table alone while the schema level grant continues to cover the other eleven.

Why C is wrong: Plausible as a way to remove inheritance at its source, but the scenario states the group's access comes from the schema grant, so revoking it removes read access to all twelve tables and breaks the requirement to leave the others unchanged.

Why D is wrong: Attractive to a candidate who assumes Unity Catalog classifies sensitive tables automatically, but repeating a grant is idempotent and carries no notion of personal data, so the group's access would be identical afterwards.

On Monday an administrator grants SELECT on the schema prod.finance to the account group auditors, which already holds USE CATALOG on prod and USE SCHEMA on prod.finance. On Tuesday a different engineer creates a new managed table in that schema. Which statement describes the group's access to the new table?

• AThe group can read the new table only once the table's owner issues an explicit table level GRANT SELECT naming the group.
• BThe group can read the new table only if the schema level grant is reissued after the table has been created in the schema.
• CThe group can read the new table straight away, because a privilege granted on a schema is inherited by every table the schema contains now or in future.check_circle Correct
• DThe group cannot read the new table, because privileges held on a schema govern metadata browsing rather than access to the rows in its tables.

Why A is wrong: Tempting because a table level grant would certainly work, but it is not required: the schema level privilege already reaches the table, so waiting for the owner to act adds a step that changes nothing.

Why B is wrong: Plausible if inheritance is imagined as a snapshot taken at grant time, but Unity Catalog evaluates inheritance when the query runs, so reissuing the grant would leave the outcome unchanged.

Why C is correct: Correct, because Unity Catalog privileges flow downward through the securable hierarchy and are resolved at query time, so any table created later inside the schema is already covered by the earlier schema level grant.

Why D is wrong: Attractive because a separate BROWSE privilege does exist for metadata discovery, but SELECT on a schema is a data privilege, and confusing it with BROWSE understates what the schema grant conveys.

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.

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.

A data engineer working in a Databricks Git folder that currently has the branch release-2026 checked out uses the Git dialog to create a new branch named feature-orders. No commit has been made yet. Which statement describes the state of that new branch?

• AThe new branch starts from the default branch of the remote repository, whichever branch the Git folder happens to have checked out at the time of creation.
• BThe new branch starts from the commit that the Git folder currently has checked out, and it appears in the remote repository only after the first push from that folder.check_circle Correct
• CThe new branch is registered in the remote repository straight away, so a colleague can check it out from the provider before any commit has been pushed to it.
• DThe new branch is created in the remote repository alone, so the Git folder keeps release-2026 checked out until the engineer pulls the new branch back down.

Why A is wrong: Tempting because many providers show the default branch first, but the dialog offers the current branch as the base and does not silently rebase the work onto main.

Why B is correct: Correct, because branch creation in the Git folder is a local operation against the checked out commit, and the remote learns of the branch when a commit is pushed to it.

Why C is wrong: Attractive because the branch is visible in the workspace at once, but visibility in the Git folder is local; the remote gains the reference on the first push.

Why D is wrong: Plausible for anyone thinking of provider side branch creation, but creating a branch from the dialog switches the folder onto that branch immediately.

A colleague merged a pull request into the main branch of a repository an hour ago. A data engineer whose Databricks Git folder has main checked out opens a notebook in that folder and finds the previous version of the code, with no sign of the merged change. The Git provider shows the merge on main. What accounts for this, and what should the engineer do?

• AA Git folder tracks its remote branch continuously, so stale content means the merge landed on a branch of a different repository than the one the folder is linked to.
• BA Git folder refreshes its contents whenever a notebook in it is opened, so closing the notebook and opening it once more brings the merged commit into the folder.
• CA Git folder changes only when someone performs a Git operation in it, so the engineer should pull the branch from the Git dialog to bring the merged commit into the folder.check_circle Correct
• DA Git folder is synchronised by a background workspace job that runs roughly hourly, so the engineer should wait for the next cycle before reading the notebook again.

Why A is wrong: Tempting because a wrong repository would indeed explain it, but the provider shows the merge on the same linked repository, and Git folders do not track continuously.

Why B is wrong: Plausible because opening a notebook does reload it, but the reload reads the workspace copy of the file and fetches nothing from the remote repository.

Why C is correct: Correct, because the folder holds a working copy fixed at the commit last checked out or pulled, and a pull is what advances it to the remote branch tip.

Why D is wrong: Attractive because other workspace features do run on schedules, but no scheduled process pulls commits into Git folders, so waiting changes nothing.

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.

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.

A nightly Lakeflow Job has settled at roughly forty minutes per run across the last two months of its run history. The team wants to be notified while a run is heading well past that baseline, but a slow run must still be allowed to finish rather than being stopped. Which statement describes how the job's duration threshold settings meet that requirement?

• ASet a warning threshold at the duration that counts as slow, since it sends the configured notification and lets the run carry on, while a timeout is a separate limit that cancels a run once reached.check_circle Correct
• BSet a timeout at the duration that counts as slow, since exceeding it raises the notification, and a run is cancelled only when a second and higher timeout value is also configured on the same job.
• CSet the warning threshold and the timeout to the same duration, since a warning notification is only ever emitted for a run that the accompanying timeout has already cancelled on the same job.
• DSet neither value, since a notification is raised automatically once a run exceeds the median duration of the runs already recorded in that job's run history, without any configuration on the job.

Why A is correct: The warning threshold and the timeout are distinct settings with distinct consequences: the warning notifies the configured recipients and leaves the run executing, and only the timeout cancels the run, so a warning alone gives the alerting the team wants without stopping the work.

Why B is wrong: This is tempting because both settings are configured in the same part of the job definition and both are expressed as a duration, but a job carries one timeout and reaching it cancels the run, so this choice stops exactly the runs the team wants to let finish.

Why C is wrong: It sounds plausible that the two settings are linked so that a warning reports a cancellation, but the warning fires independently while the run is still executing, and pairing the values here would cancel every run that the team wanted to observe.

Why D is wrong: The run history does display past durations, which makes an automatic comparison against them sound reasonable, but no such implicit baseline alert exists, and leaving both settings unconfigured means a long run passes with no notification at all.

A platform team currently maintains a nightly Lakeflow Job whose only work is to run OPTIMIZE and VACUUM across a schema of Unity Catalog tables. The schema holds both managed tables and several external tables registered over a partner storage path. The team is considering enabling predictive optimization for the schema instead. Which two statements about predictive optimization are correct? (Select TWO.)

• AIt rewrites the clustering keys of each table whenever the query patterns against that table shift, so the team never has to consider which columns to cluster on.
• BIt runs maintenance operations including OPTIMIZE and VACUUM on eligible tables automatically, so the team no longer needs to schedule those statements in a job of its own.check_circle Correct
• CIt applies to every table the workspace can see, including tables that still live in the legacy workspace Hive metastore, which lets the team retire the job in one step.
• DIt covers Unity Catalog managed tables, so the external tables in this schema still need their maintenance scheduled by the team rather than being handled for them.check_circle Correct
• EIt removes the need for any file retention setting, because it keeps every historical data file so that time travel to any past table version continues to work.

Why A is wrong: Tempting because the feature is described as predictive, but its job is to schedule maintenance operations, not to decide a table's clustering keys for the team.

Why B is correct: Running the file compaction and file cleanup operations on the team's behalf, at times it judges worthwhile, is exactly what the feature is for.

Why C is wrong: This overstates the scope: predictive optimization is a Unity Catalog feature, and tables in the legacy workspace Hive metastore are outside it.

Why D is correct: Eligibility is limited to managed tables, so a schema mixing managed and external tables is only partly covered and the external ones remain the team's responsibility.

Why E is wrong: It is tempting to assume automation makes retention moot, but the feature runs VACUUM, which removes files beyond the retention threshold rather than keeping them all.

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

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.

A data engineer drops two Unity Catalog tables that sit in the same schema. One is a managed table. The other is an external table registered over a path inside a working external location. Neither table has been cloned. What happens to the underlying data files in each case?

• AThe managed table's files become eligible for deletion by Databricks, while the external table's files stay untouched in the external location.check_circle Correct
• BThe files behind both tables are deleted straight away, because Unity Catalog owns the storage lifecycle of every table it governs.
• CThe files behind both tables stay in place, because DROP TABLE in Unity Catalog removes the metastore entry and nothing else.
• DThe managed table's files stay in place for a retention period, while the external table's files are removed together with its metastore entry.

Why A is correct: Correct, because Unity Catalog owns the storage lifecycle of a managed table and only owns the metadata of an external table, whose files remain the responsibility of the storage account.

Why B is wrong: This is tempting because Unity Catalog does govern both tables, but governing access is not the same as owning storage, and deleting external files would destroy data other systems may still read.

Why C is wrong: This generalises external table behaviour to every table, which is a common carry-over from the legacy Hive metastore, and it misses that a managed table's data is deleted with it.

Why D is wrong: This inverts the two behaviours, and although managed table data is retained briefly before permanent deletion, the external files are never deleted by the DROP statement.

Two independent Lakeflow Jobs write to the same Delta table at the same moment. One appends a batch of new rows while the other deletes rows matching a predicate on an unrelated set of dates. Neither job takes an explicit lock. Which statement describes how Delta Lake handles this?

• AThe second writer waits on a table-level lock held by the first writer, and its own commit proceeds only once the first writer has finished its transaction.
• BDelta Lake applies optimistic concurrency control, so each writer reads a snapshot, then commits, and retries or fails only when the files the two transactions touch overlap.check_circle Correct
• CBoth commits are accepted unconditionally, because Delta Lake reconciles the two sets of changes at the file level during the next OPTIMIZE run on the table.
• DThe table is left in an intermediate state until a later reader repairs the transaction log by comparing the committed entries against the files in storage.

Why A is wrong: This describes pessimistic locking, which is a reasonable expectation from relational systems, but Delta Lake does not block writers up front and instead resolves conflicts at commit time.

Why B is correct: Correct, because writers proceed without blocking and the commit protocol checks for conflicting file changes, which lets disjoint writes such as these two succeed together.

Why C is wrong: OPTIMIZE compacts small files and does not merge competing transactions, so treating it as a conflict resolver would allow a lost update between the moment of the commit and the moment of compaction.

Why D is wrong: Readers never repair the log, and a commit is atomic, so no intermediate state is ever visible; this confuses Delta Lake with systems that need a recovery pass after a crash.