Secure and govern Unity Catalog objects Study Guide — DP-750

Secure and Govern Unity Catalog Objects

This domain tests your ability to implement security controls, governance policies, and compliance features within Unity Catalog (UC) on Azure Databricks. It covers the full lifecycle of data governance: who can access what (privileges, ABAC, row/column security), how secrets and identities are managed, how objects are discovered and described, and how sharing and auditing work. Weighted at 17% of the exam, this is one of the heaviest domains and requires both conceptual understanding and hands-on knowledge of exact syntax, privilege names, and feature behavior.

Privileges for Users, Service Principals, and Groups on Securables

Concepts

Unity Catalog uses a hierarchical securable object model: Metastore → Catalog → Schema → Table/View/Volume/Function. Privileges flow downward through inheritance but must be explicitly granted at the right level. The three principal types are:

• Users – identified by email address
• Service principals – non-human identities for automation and apps
• Groups – collections of users and/or service principals (can be nested)

Account-level groups are defined in the Databricks account console and are the recommended approach. Workspace-level groups are legacy and should not be confused with account-level groups on the exam.

Privilege Hierarchy

Key rule: To read a table, a principal needs USE CATALOG on the catalog AND USE SCHEMA on the schema AND SELECT on the table. Missing any level blocks access.

Ownership matters: the owner of an object can grant/revoke privileges on that object. The metastore admin can manage all objects. Data Stewards is not a built-in UC role — do not confuse with workspace roles.

Common Traps

• ALL PRIVILEGES on a schema does not automatically grant USE CATALOG on the parent catalog — you must grant that separately.
• Workspace admins ≠ Metastore admins. Workspace admins cannot manage UC privileges unless also assigned as metastore admin.
• Granting SELECT directly on a table does not bypass the need for USE CATALOG and USE SCHEMA.
• Account-level groups are synced via SCIM; workspace-local groups are not available in Unity Catalog privilege grants.
• MODIFY on a table allows INSERT, UPDATE, DELETE — not schema changes. DDL changes require object ownership or ALL PRIVILEGES.

Worked Scenario

Requirement: A data engineer group needs to create tables in the silver schema of the analytics catalog, but must not be able to create new schemas or catalogs.

Reasoning: Grant USE CATALOG on analytics, USE SCHEMA + CREATE TABLE on silver. Do not grant CREATE SCHEMA on the catalog or any catalog-level DDL. ALL PRIVILEGES on the catalog would be wrong because it would include CREATE SCHEMA.

Table/Column-Level Access Control and Row-Level Security

Concepts

Table-level access control is enforced via UC's SELECT privilege. Column-level security is implemented using column masks (see the dedicated section) or by granting SELECT on specific views that expose only certain columns.

Dynamic views are a legacy pattern for column-level and row-level security — a view using current_user() or is_member() to filter rows/columns. Unity Catalog now provides native row filters and column masks as the preferred approach (see dedicated section).

Row-Level Security via Dynamic Views (Legacy)

CREATE VIEW secure_orders AS
SELECT * FROM orders
WHERE region = current_user()
   OR is_account_group_member('admin_group');

Common Traps

• current_user() returns the Databricks user identity, not an Azure AD display name.
• Dynamic views require the user to have SELECT on the view, not the underlying table. If they have SELECT on the table directly, the view restriction is bypassed.
• Column-level privileges (GRANT SELECT (col1, col2) ON TABLE ...) are not supported in Unity Catalog — use column masks or views instead.
• is_member() checks workspace-level group membership; is_account_group_member() checks account-level groups. Use the account-level function in UC contexts.