Databricks Certified Data Engineer Associate practice questions

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.

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.

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.