Governance and Security
Governance and Security
This domain tests Unity Catalog permissions, identity, data protection, and auditing. Questions ask who can see or change an object, how to mask data, and how to secure storage and network access.
Governance rules
- Unity Catalog secures objects in a hierarchy: metastore, catalog, schema, table/view, volume, function, model, external location, storage credential, and share. Privileges include
USE CATALOG,USE SCHEMA,SELECT,MODIFY,CREATE TABLE,EXECUTE, andALL PRIVILEGES. A user needsUSEon parent objects as well as the privilege on the object. - Grant to account groups, not individuals; sync groups from Microsoft Entra ID with SCIM. Ownership carries implicit rights; transfer ownership deliberately.
- Row filters restrict rows; column masks obscure values. Both are UC functions applied to tables or views. Dynamic views are an alternative but can be bypassed if users query base tables, so revoke base-table access.
- Storage: an external location combines a storage credential (managed identity or service principal) with an ADLS path. Access connectors for ADLS Gen2 are the recommended managed-identity path. DBFS root is not UC-governed.
- Network and keys: private link, IP access lists, no-public-IP clusters, and customer-managed keys reduce exposure. Audit with
system.access.auditand diagnostic logs. - Cluster policies and workspace admin controls are separate from UC data privileges.
Worked example
An analyst in the EU team must read a global sales table but only see EU rows, with email masked.
Reasoning: create a row-filter function returning region = 'EU' and a column-mask function returning a masked email unless the caller is in an admin group. Apply both to the table, then grant SELECT to the EU group and USE CATALOG/USE SCHEMA on parents. Revoke direct base-table access if a dynamic view is used instead.
Traps
- Granting privileges to individual users instead of groups.
- Forgetting
USEprivileges on catalog and schema. - Assuming workspace admin implies UC metastore admin.
- Relying only on a view while leaving base tables readable.
- Putting storage keys in code instead of using a storage credential.
- Ignoring audit logs and data-classification tags.