Managing Data: Databricks Data Analyst Associate Practice Questions

A data governance team is tagging tables in Unity Catalog to support a new data classification initiative. A data steward needs to add a tag with key pii_category and value contact_info to the customers.profiles.email_address column of an existing Delta table. The steward has been granted APPLY TAG on the table, USE SCHEMA on customers.profiles, and USE CATALOG on customers, but is NOT the table owner. Additionally, a junior engineer asks whether they can tag multiple columns on the same table in a single SQL ALTER TABLE statement. Which of the following statements is CORRECT?

1. AThe data steward cannot add the tag because APPLY TAG on a table grants permission to tag only the table-level object itself, not its individual columns. A separate APPLY TAG ON COLUMN privilege must be explicitly granted for each column the steward needs to tag. Furthermore, the junior engineer can tag multiple columns in a single ALTER TABLE SET TAG statement using a comma-separated column list, which is the recommended approach for bulk column tagging to minimize transaction overhead on the Unity Catalog metastore.
2. BThe data steward has the correct privileges to add the column-level tag: APPLY TAG on the table (which covers both table-level and column-level tagging), USE SCHEMA on the parent schema, and USE CATALOG on the parent catalog — all three are the documented minimum requirements for a non-owner to apply tags. The steward would use either Catalog Explorer (navigate to the column, click the tag icon) or execute ALTER TABLE customers.profiles SET TAG ON COLUMN email_address ('pii_category' = 'contact_info'). However, the junior engineer should be aware that you CANNOT tag multiple columns in a single ALTER TABLE command — each column must be tagged in a separate statement, which differs from the COMMENT clause that can target multiple columns at once.
3. CThe data steward does not have sufficient privileges because USE SCHEMA and USE CATALOG are purely navigation permissions that are automatically granted to all workspace users for any accessible catalog; neither contributes to the authorization check for APPLY TAG operations. The only valid authorization path for column tagging is being the table owner. Non-owners who need to tag columns must temporarily be granted table ownership, apply all required tags, and then have ownership transferred back — there is no privilege-based (non-ownership) tagging mechanism for column-level objects.
4. DTag keys in Unity Catalog are case-insensitive and stored in lowercase by default, so pii_category and PII_CATEGORY would be treated as the same tag. Additionally, a single table can have an unlimited number of column tags in total — there is no cap on column-level tagging — and the junior engineer can apply up to 50 tags simultaneously across multiple columns using a single ALTER TABLE SET TAG statement with a WHERE clause filtering by column name pattern.
5. EThe tag value contact_info will be automatically encrypted by Unity Catalog before storage because tag values are classified as sensitive governance metadata. Unity Catalog applies AES-256 encryption to all tag values assigned to PII-related columns, and the encrypted tag values are visible only to users with the VIEW ENCRYPTED METADATA privilege. Tag keys remain in plain text. The junior engineer's ALTER TABLE bulk column tagging approach will succeed only if the data steward pre-approves the tagging batch through a Unity Catalog tag approval workflow that is triggered automatically when 3 or more column tags are applied simultaneously.

A data analyst at a retail company wants to confidently use only high-quality, authoritative datasets for their quarterly revenue report. Their Databricks workspace is enabled for Unity Catalog. Which combination of Unity Catalog features and behaviors BEST supports the analyst in discovering trustworthy datasets, confirming their quality status, and querying them alongside internal tables?

1. AThe analyst should open the Delta Lake transaction log for each candidate table and manually parse the _delta_log directory to check whether a Databricks data steward has appended a custom JSON quality certificate entry. Tables whose _delta_log contains this entry are certified. Queries against certified tables must use a special CERTIFIED ONLY SQL keyword that is automatically injected by the Databricks Runtime to prevent mixing certified and uncertified data in the same SELECT statement.
2. BThe analyst should use the Databricks workspace search bar or Catalog Explorer to browse available tables across catalogs, filter by the 'Certified' endorsement label that data stewards have applied to tables meeting organizational quality standards, read each table's description and documentation for context, and then query the selected tables using the standard three-part Unity Catalog namespace (catalog.schema.table) in the SQL Editor or a notebook — the same syntax used for any other registered table. No special query syntax is needed for certified tables; the certification label is a discoverability and trust signal, not a query restriction.
3. CCertified datasets in Unity Catalog are exclusively stored in a dedicated system catalog named certified_data that is automatically provisioned by Databricks when a workspace is first created. To query any certified dataset, the analyst must run USE CATALOG certified_data before executing any SELECT statement; queries that reference a table in any other catalog alongside a table from certified_data in the same SQL statement will raise a cross-catalog certification violation error and must be rewritten as separate queries joined in Python.
4. DUnity Catalog does not support data certification or quality endorsements at the table level; certification is a feature available only in Databricks Marketplace for externally published datasets. Internal workspace tables can be tagged with a user-defined tag named 'certified=true', but this tag is treated identically to any other arbitrary metadata tag and has no special discoverability behavior in Catalog Explorer, the search bar, or the Unity Catalog permissions system.
5. EThe analyst must first request that a workspace administrator run the proprietary Databricks CLI command databricks unity-catalog certify --table catalog.schema.table --force-quality-scan against each candidate table. This command triggers a background data profiling job that scores each column on a 0–100 completeness scale, and tables scoring above 80 on all columns are automatically promoted to the system.certified schema where they become queryable. Tables that do not meet the threshold remain in their original schema but are flagged with a system-managed UNCERTIFIED comment visible only in the INFORMATION_SCHEMA.TABLE_COMMENTS view.

A data engineer wrote a notebook six months ago that reads from gold.finance.revenue_summary and writes to gold.reporting.quarterly_kpis. A colleague now opens the quarterly_kpis table in Catalog Explorer to trace where the data originally came from. They also want to understand whether column-level lineage is captured. Which combination of statements CORRECTLY describes Unity Catalog's lineage behavior for this scenario?

1. AUnity Catalog lineage is captured only for tables that are explicitly registered for lineage tracking by a workspace administrator using ALTER TABLE ... ENABLE LINEAGE. Tables that were created before lineage was enabled have no retroactive lineage history. Because the notebook was written six months ago and lineage may not have been enabled at that time, the colleague should not expect to see any upstream lineage for quarterly_kpis. Column-level lineage is only available for tables stored in the Iceberg format — Delta tables support only table-level lineage.
2. BUnity Catalog automatically captures runtime lineage for all queries run on Databricks against tables registered in the Unity Catalog metastore — no configuration is required. Lineage is captured for all languages (Python, SQL, Scala, R) using Spark DataFrame or Databricks SQL interfaces. The colleague can view the lineage graph in Catalog Explorer by navigating to quarterly_kpis, selecting the Lineage tab, and clicking 'See Lineage Graph' to see the upstream table revenue_summary. Column-level lineage is supported and can be viewed by clicking a specific column in the graph to reveal which upstream columns it was derived from. Lineage data is retained for one year, so the six-month-old notebook run should still be visible assuming it ran within the past 12 months.
3. CUnity Catalog lineage is captured only for queries executed via the Databricks SQL Editor and AI/BI Dashboards — notebook-based queries (Python and Scala DataFrames) are excluded from lineage tracking because notebooks operate in the classic compute plane, which is architecturally isolated from the Unity Catalog lineage capture service running in the serverless compute plane. The colleague will see the quarterly_kpis table as a lineage endpoint but will not see any upstream connections from notebooks.
4. DLineage in Unity Catalog is aggregated only within a single Databricks workspace; if the notebook that wrote to quarterly_kpis was run in a different workspace than the one the colleague is using — even if both workspaces share the same Unity Catalog metastore — the upstream lineage will not be visible to the colleague. Column-level lineage is captured but requires a data steward to manually annotate column-to-column mapping relationships through the Catalog Explorer UI before the graph is populated; it is not automatically inferred from SQL queries.
5. EUnity Catalog retains lineage data indefinitely — there is no time-based expiration of lineage records. Once a pipeline writes to a table, the lineage link between source and target table persists permanently in the metastore until a workspace administrator explicitly runs ALTER TABLE quarterly_kpis DROP LINEAGE to purge it. Column-level lineage is captured for all transformation types including user-defined functions (UDFs), wildcard selects referencing path-based tables (select * from delta.'s3://...'), and RDD-based operations — these are all fully supported lineage scenarios.

A data analyst needs to find all tables in their organization's Databricks Unity Catalog environment that are relevant to customer purchase behavior, then query one of those tables alongside a separate internal order-fulfillment table that lives in a different catalog. The analyst's account has SELECT on the target tables and USE CATALOG and USE SCHEMA on both parent objects. Which approach CORRECTLY demonstrates Unity Catalog's discovery and cross-catalog querying capabilities?

1. AUnity Catalog does not support cross-catalog queries in a single SQL SELECT statement. To join tables from two different catalogs, the analyst must first use CREATE TABLE AS SELECT to copy one table's data into the same catalog as the other, then run the JOIN query on the two co-located copies, and finally drop the temporary copy after the query completes. This two-catalog isolation policy is enforced at the SQL Warehouse level and cannot be bypassed by granting additional privileges.
2. BThe analyst can use the Databricks workspace search bar to type keywords related to customer purchases (for example, 'customer orders') to return matching tables, views, and schemas across all catalogs visible to the analyst's account — including matches found in table names, column names, descriptions, comments, and tags. The analyst can then run a cross-catalog SQL query using fully qualified three-part names: SELECT c.customer_id, o.fulfillment_status FROM retail.customers.purchase_history c JOIN logistics.orders.fulfillment o ON c.order_id = o.order_id — no data copying, catalog switching, or special privileges beyond SELECT, USE SCHEMA, and USE CATALOG on each respective catalog are required.
3. CUnity Catalog workspace search only indexes table names and schema names; it does not index column names, table comments, or user-defined tags. To find customer purchase-related tables, the analyst must run a full scan query against the INFORMATION_SCHEMA.TABLES table in every catalog individually, using a LIKE '%purchase%' filter, and then manually compile the results into a cross-catalog inventory. Cross-catalog queries require a SET SEARCH_PATH TO catalog1, catalog2 command before the JOIN query to instruct the SQL Warehouse which catalogs to make available in the current session.
4. DThe analyst must first establish a cross-catalog connection by running CREATE CATALOG LINK retail_to_logistics BETWEEN retail AND logistics to register a bidirectional catalog federation link in Unity Catalog. Without this link, the SQL parser will reject any query that references table names from two different catalogs, returning a 'CatalogLinkNotFound' error. Once the link is created, cross-catalog queries use a special two-part prefix syntax: [retail]customers.purchase_history instead of the standard three-part name.
5. EThe Databricks workspace search bar is exclusively for searching workspace objects such as notebooks, jobs, and dashboards. To search for Unity Catalog tables by content or business context, the analyst must install the separately licensed Databricks Data Discovery Add-on and configure it to crawl Unity Catalog metastore metadata nightly. Cross-catalog queries are supported but require both catalogs to be registered in the same Unity Catalog metastore and to use the same cloud storage region as the SQL Warehouse executing the query.

A data analyst is cleaning a Unity Catalog Delta table named silver.customers.profiles. The table has a signup_date column (DATE type) that contains some NULL values, and an email column (STRING type) where some rows contain an empty string '' instead of a valid email address. The analyst wants to: (1) replace NULL signup_date values with the date '2020-01-01' in a query result (without modifying the underlying table), and (2) permanently delete all rows where email is either NULL or an empty string from the underlying table. Which SQL approach CORRECTLY accomplishes both requirements?

1. ARequirement 1: Use REPLACE(signup_date, NULL, '2020-01-01') — the REPLACE function is the standard SQL function for substituting NULL values with a default in a SELECT query. Requirement 2: Run UPDATE silver.customers.profiles SET email = NULL WHERE email = '' — this converts the empty strings to NULLs, making both forms of missing email consistently represented as NULL. A subsequent DELETE FROM silver.customers.profiles WHERE email IS NULL then removes all rows with missing email, completing the two-step process.
2. BRequirement 1: Use COALESCE(signup_date, DATE '2020-01-01') or equivalently NVL(signup_date, '2020-01-01') in the SELECT clause — COALESCE returns the first non-NULL argument, so it returns the actual signup_date when it is not NULL and substitutes '2020-01-01' when it is NULL, without modifying the underlying table data. Requirement 2: DELETE FROM silver.customers.profiles WHERE email IS NULL OR email = '' — this single DELETE statement permanently removes all rows where the email is either NULL or an empty string, satisfying both conditions in one operation on the Delta table.
3. CRequirement 1: Use IFNULL(signup_date, CURRENT_DATE()) — the IFNULL function replaces NULL with today's current date; a static replacement like '2020-01-01' is not supported because DATE literals cannot be used as the second argument of IFNULL in Databricks SQL. Requirement 2: Run TRUNCATE TABLE silver.customers.profiles and then re-insert all rows from a subquery that filters out NULL and empty emails — TRUNCATE followed by re-insert is the recommended approach for selective row deletion in Delta tables because the DELETE statement is not supported for Delta tables registered in Unity Catalog.
4. DRequirement 1: COALESCE(signup_date, '2020-01-01') works correctly only after first running ALTER TABLE silver.customers.profiles ALTER COLUMN signup_date SET DEFAULT '2020-01-01', because COALESCE in Databricks SQL respects the column DEFAULT definition and will skip its second argument if no DEFAULT is set on the column. Without setting the DEFAULT first, COALESCE returns NULL for NULL input values. Requirement 2: DELETE FROM silver.customers.profiles WHERE email IS NULL OR email = '' is correct, but the analyst must first disable Delta Lake ACID transactions on the table with ALTER TABLE silver.customers.profiles SET TBLPROPERTIES ('delta.enableAcid' = 'false') before a DELETE will be committed without errors.
5. ERequirement 1: The only way to handle NULL signup_date values in a non-modifying SELECT query in Databricks SQL is to use a CASE expression: CASE WHEN signup_date IS NULL THEN CAST('2020-01-01' AS DATE) ELSE signup_date END. Functions like COALESCE and NVL modify the underlying column data and cannot be used in a SELECT without a preceding BEGIN TRANSACTION block to wrap the substitution in a rollback-safe context. Requirement 2: DELETE FROM silver.customers.profiles WHERE email IS NULL OR email = '' is correct.