5.2 Access Control and Permissions

Quick Answer: Unity Catalog uses GRANT/REVOKE on securable objects. Privileges are inherited down the hierarchy: a grant on a catalog flows to its schemas and tables. To read a table a principal needs three privileges together — USE CATALOG, USE SCHEMA, and SELECT. Every object has one owner with full control, and you should assign privileges to groups, not individuals.

Securable Objects and the Privilege Hierarchy

Securable objects in Unity Catalog are arranged as a tree: metastore → catalog → schema → table/view/volume/function/model. Because the tree is hierarchical, privileges cascade downward. If you grant SELECT on a catalog, the principal can select from every current and future table in every schema inside it. This inheritance is what makes UC manageable at scale — you set broad access high in the tree and refine it lower down.

The Privileges You Must Know

Unity Catalog privileges are explicit verbs. The exam focuses on this core set:

A critical exam trap: USE CATALOG and USE SCHEMA are traversal-only — they let you "walk into" a container but grant no data access on their own.

The Three-Grant Rule for Reading a Table

To query prod.sales.orders, a principal needs all three of the following, cumulatively:

1. USE CATALOG on prod
2. USE SCHEMA on prod.sales
3. SELECT on prod.sales.orders

Missing any one returns a permission error. This is the single most-tested governance rule on the exam. The pattern generalizes: traverse the containers (USE …), then act on the object (SELECT, MODIFY, EXECUTE).

Sample SQL:

GRANT USE CATALOG ON CATALOG prod TO `analysts`;
GRANT USE SCHEMA ON SCHEMA prod.sales TO `analysts`;
GRANT SELECT ON TABLE prod.sales.orders TO `analysts`;

To remove access, use REVOKE:

REVOKE SELECT ON TABLE prod.sales.orders FROM `analysts`;

Ownership, Groups, and Who Can Grant

Every securable object has exactly one owner (a user or, preferably, a group). The owner holds all privileges on that object and can grant or revoke them for others. Ownership can be transferred with ALTER … OWNER TO.

Who can grant access?

• The object owner.
• A metastore admin (account-level role) over the whole metastore.
• A principal with the MANAGE privilege, which delegates grant administration on an object without making them the owner.

Best practice is to assign privileges and ownership to account-level groups rather than individual users, because groups are managed once at the account and reused across all workspaces. Removing a person from a group instantly revokes their inherited access everywhere — far safer than tracking individual grants. Use SHOW GRANTS ON <object> to audit who has access.

ALL PRIVILEGES, BROWSE, and Dangerous Exclusions

ALL PRIVILEGES is a convenience grant that confers every applicable privilege on an object and its children at once, but it is not truly everything: MANAGE, EXTERNAL USE SCHEMA, and EXTERNAL USE LOCATION are deliberately excluded so that a broad grant cannot accidentally enable data exfiltration to outside engines. Those must be granted explicitly.

BROWSE is the discovery privilege: it lets a principal see an object's metadata (its existence, schema, comments) in Catalog Explorer without granting SELECT on the data. This supports a "discover then request" workflow for self-service analytics.

Practical Grant Patterns

A common pattern is to grant USE CATALOG broadly (it exposes nothing on its own), then control real access with SELECT/MODIFY at the schema or table level. To let a data-engineering group build in a schema, you grant USE CATALOG, USE SCHEMA, CREATE TABLE, and MODIFY. To audit access, run SHOW GRANTS ON TABLE prod.sales.orders, which lists every principal and their privileges. Privileges and ownership should map to account groups that mirror job functions (analysts, engineers, pii_admins), so onboarding a person is just a group membership change rather than dozens of individual grants.

Identity, Account Groups, and Auditing Access

Unity Catalog identities are managed at the account level, not per workspace, which is what makes a single grant effective everywhere. Account admins (or an identity provider via SCIM) define users and groups once; you then reference those groups in GRANT statements. Nesting groups inside groups lets you model an organization (for example, an engineers group inside an all_staff group) so a single membership change cascades the right access.

When access questions arise, SHOW GRANTS TO \analysts`andSHOW GRANTS ON TABLE …` reveal exactly what a principal can do, and the audit log records every grant and revoke for accountability. The recurring exam theme is that groups, not individual users, are the unit of access management — they make permissions auditable, portable across workspaces, and trivial to revoke. Combined with the three-grant rule for reads and the inheritance model, this gives you a complete picture of how a principal ends up able to query a given table.