Task 1.1: Understand the core components of the Databricks Data Intelligence Platform, such as its architecture, Delta Lake, and Unity Catalog.

• ASELECT * FROM sales.silver.orders VERSION AS OF 41

  Incorrect

  A time travel query reads the old version for that one query only; the table's current version stays 42 for every other reader.

• BVACUUM sales.silver.orders RETAIN 0 HOURS

  Incorrect

  VACUUM deletes data files that the current version no longer references, which would destroy the files needed to go back to version 41.

• CRESTORE TABLE sales.silver.orders TO VERSION AS OF 41

  Correct

  RESTORE writes a new commit that returns the table to the state of version 41, so every reader that queries the table by name sees the earlier contents.

• DDESCRIBE HISTORY sales.silver.orders LIMIT 1

  Incorrect

  DESCRIBE HISTORY is a read-only command; it changes nothing, so readers keep seeing version 42.

Every write to a Delta table creates a version in the transaction log. Time travel reads an old version for a single query, while RESTORE rolls the table itself back so all readers get the earlier state.

• AIn the control plane, next to the Databricks web application

  Incorrect

  The control plane holds the backend services and the web application that Databricks manages; data is processed in the compute plane.

• BIn the classic compute plane, inside the customer's own AWS account

  Correct

  Classic compute resources run in your AWS account, in what Databricks calls the classic compute plane.

• CIn the serverless compute plane, inside the Databricks account

  Incorrect

  The serverless compute plane runs serverless compute; classic clusters are created in your own account instead.

• DIn the workspace storage bucket that holds notebooks and job results

  Incorrect

  The workspace storage bucket stores workspace system data such as notebook revisions and job results; it does not run compute.

Databricks splits a workspace into a control plane and a compute plane. Serverless compute runs in a compute plane in the Databricks account; classic compute runs in the customer's cloud account.

• ACreate a metastore for each workspace and copy the tables between them each night

  Incorrect

  Separate metastores mean separate grants and duplicate data, which is the opposite of one governed view.

• BShare the engineering tables to the analytics workspace through OpenSharing

  Incorrect

  OpenSharing shares data across platforms, clouds and regions; workspaces in the same region can simply use the same metastore.

• CKeep the tables in the DBFS root of one workspace and mount that path in the other

  Incorrect

  DBFS root and mounts are legacy patterns without Unity Catalog governance, so grants would not be shared.

• DAttach both workspaces to the same Unity Catalog metastore

  Correct

  A metastore can be linked to multiple workspaces in the same region, giving each workspace the same data view with access controls managed across them.

The Unity Catalog metastore is the governance container for catalogs, schemas and tables. Attaching it to several workspaces in one region gives them one shared, centrally governed view of the data.

• AA write is visible once its commit is recorded in the transaction log

  Correct

  Files from a failed transaction are never added to the log, so they are not part of the table state; VACUUM can later remove them.

• BDelta Lake writes into a temporary table and renames it when the job ends

  Incorrect

  Delta Lake writes data files into the table directory and commits them through the log; it does not swap table names.

• CDelta Lake locks the table so readers wait until the writer finishes

  Incorrect

  Databricks uses optimistic concurrency control without locks; readers get a snapshot instead of waiting.

• DThe writer deletes its partial files right away when it detects the failure

  Incorrect

  Uncommitted files can remain in the directory; they are ignored because the log does not reference them.

The transaction log decides what the table contains. Each commit adds a version that references its files, so a write is all or nothing for readers.

• ABronze

  Incorrect

  Bronze holds raw, unvalidated data, with only minimal validation.

• BGold

  Incorrect

  Gold holds aggregated, business-level datasets such as average spend per customer, built for business users.

• CSilver

  Correct

  Silver is the layer for cleaning and validation; it keeps detailed records that analysts and data scientists use.

• DA landing volume for raw files

  Incorrect

  A volume stores files before ingestion; it is not a layer of validated tables.

Data improves as it moves from bronze (raw) to silver (cleaned and validated) to gold (modeled and aggregated). Detailed, validated joins of entities belong in silver.