Security and Governance: free practice questions

Unity Catalog supports **tags** (key-value metadata) on catalog objects including columns. You apply them with `ALTER TABLE <t> ALTER COLUMN <c> SET TAGS ('classification' = 'PII')` and then discover tagged columns by querying `SYSTEM.INFORMATION_SCHEMA.COLUMN_TAGS`. **Option A** (column comments) are free-text annotations with no structured discovery mechanism — you cannot reliably filter or enforce them. **Option B** filtering `COMMENT` fields is fragile, unstructured, and not the intended governance mechanism; comments are not indexed or queryable as tags. **Option D** describes Databricks Lakehouse Monitoring, which produces data quality metrics and statistics — it has no sensitivity classification field and is unrelated to metadata tagging.

Option A is correct. Unity Catalog's native row filter feature (GA in DBR 12.2+) allows creating a SQL function that returns a BOOLEAN and applying it to a table with `ALTER TABLE ... SET ROW FILTER func ON (column)`. The function can reference other tables (like a mapping table) and use `current_user()` or `IS_ACCOUNT_GROUP_MEMBER()` to make it session-aware. This is the recommended, governed approach for row-level security in Unity Catalog. Option B is incorrect: While a view-based approach is a valid workaround (and was the pre-Unity-Catalog pattern), it is not a row filter. It also requires removing direct table access for users and managing an additional object. The question asks for the correct row filter approach, which is the native Unity Catalog feature. Option C is incorrect: 'Dynamic Views' with WHERE clauses in table properties is not a Unity Catalog feature. Dynamic Views are a Hive metastore pattern. Unity Catalog uses row filter functions applied via DDL. Option D is incorrect: Column masks control the visibility of column values, not entire rows. Masking the `rep_id` to NULL would not hide the row — it would simply display NULL for that column while still showing all rows to all users, which is not the desired behavior.

**Option A** is correct: the front-end Private Link endpoint exposes the workspace UI and REST API on a private IP within the customer VNet, so traffic never traverses the public internet. **Option C** is correct: Databricks also supports a back-end Private Link endpoint that routes control-plane-to-data-plane (and data-plane-to-control-plane) traffic privately, which is important for environments requiring full network isolation. **Option B** is wrong: Private Link is a network-layer feature; data-at-rest encryption with CMK is a separate, independent capability configured through key vault integration. **Option D** is wrong: NSG rules are still required to control intra-VNet traffic and to restrict outbound access from cluster nodes — Private Link does not replace NSG policy. **Option E** is partially misleading: while Premium tier is required for many security features, Private Link does use a dedicated subnet for its endpoints, but framing it as a single combined requirement in this way conflates distinct configuration steps.

In Databricks audit logging, SQL query execution events are captured under `action_name = 'commandSubmit'` (or `runCommand` for Jobs), and the SQL text (including the queried table) is embedded in `request_params`. Filtering on `commandSubmit` and then inspecting `request_params` for the table name is the correct approach for finding SELECT activity. **Option B** is wrong because `action_name = 'select'` is not a valid Unity Catalog audit event name — Unity Catalog data-access events for credential generation use different action names. **Option C** describes the `generateTemporaryTableCredential` action, which is fired when short-lived credentials are vended for cloud storage access — it reflects credential issuance, not every SELECT query, and joining on `table_id` is complex and incomplete. **Option D** (parsing raw workspace storage logs) is outdated — `SYSTEM.ACCESS.AUDIT` is the governed, SQL-queryable surface for audit data and is preferred over raw JSON log parsing.

Option C is correct. The Databricks IP Access Lists API uses `PUT` semantics for updating a list, which means the entire list of IP addresses is replaced with whatever is provided in the request body. To preserve the existing `198.51.100.0/24` entry, the PUT body must include both CIDR ranges. Option A is incorrect: The `PUT` endpoint does not merge — it replaces. Sending only the new range would remove the existing `198.51.100.0/24` entry, potentially locking out users at the original office. Option B is incorrect: While Databricks does support multiple IP access lists, creating a second ALLOW list is an unnecessarily complex approach and could cause management confusion. The standard practice is to update the existing list. More importantly, this option would work functionally but is not the best/correct approach compared to C. Option D is incorrect: The Databricks IP Access Lists API does not expose a `PATCH` method for appending entries. The supported update verb is `PUT`, which always replaces the full list.