What you will be able to do
- Identify the full set of privileges needed for common Unity Catalog operations, including the usage privileges on parent containers
- Use privilege inheritance, MANAGE, BROWSE and child privileges to grant no more access than a principal needs
- Grant, revoke and inspect privileges with SQL and Catalog Explorer, and name who is allowed to grant them
Key concept
Default deny with explicit grants — In Unity Catalog nobody can do anything with an object until a privilege is granted on it. To reach a table you also need usage privileges on its parent catalog and schema. Least privilege means granting the narrowest privilege, on the lowest object in the hierarchy, that lets the principal do the job.
1.Securable objects and the default-deny starting point
Unity Catalog stores data and metadata in a metastore. Data is addressed through a three-level namespace, catalog.schema.table, and every object in that hierarchy is a securable object, meaning something you can grant privileges on. The metastore is at the top. Catalogs and schemas are next, and they are *container* objects. Below them are the data objects (tables, views, volumes, functions and models). Other securables, such as external locations, storage credentials, connections and shares, control access to external storage, external services and OpenSharing.
Least privilege is easy to apply here because nothing is open to begin with: a new user has no access to metastore data. Every capability a principal ends up with comes from a grant that someone made on purpose. The one built-in exception to know about: in a workspace that was enabled for Unity Catalog automatically, all workspace users get USE CATALOG on the workspace catalog, plus USE SCHEMA and several CREATE privileges on its default schema. When you design access for production data, take that default into account.
| Object | Container? | Direct children |
|---|---|---|
| Catalog | Yes | Schemas |
| Schema | Yes | Tables, views, volumes, functions |
| Table, view, volume, function | No | None |
Checkpoint 1 of 7· Check yourself
A new analyst joins and is added to a Unity Catalog-enabled workspace. No grants have been made for them. What can they read from a production catalog?
Unity Catalog denies by default. Access exists only where a privilege has been granted. The automatic grants apply to the workspace catalog, not to a production catalog.
“Initially, users have no access to data in a metastore.”Source: docs.databricks.com
2.The three-privilege rule: usage privileges on every parent
USE CATALOG and USE SCHEMA are *usage privileges*. On their own they give no access to data. They are gates that must be open before the privilege on the object itself counts. Most operations on a table, view, volume or function need three privileges together: USE CATALOG on the parent catalog, USE SCHEMA on the parent schema, and the privilege for the operation (SELECT, MODIFY, EXECUTE, READ VOLUME and so on).
The gates matter for governance. Only catalog and schema owners, or users with MANAGE, can grant usage privileges. That means the owner of a single table cannot share it outside the boundary that the catalog and schema administrators have set. Least privilege is then enforced at two levels: administrators decide who can get *into* a container, and object owners decide what those people can do once inside.
| Operation | Required privileges |
|---|---|
| Read data from a table or view | USE CATALOG on catalog, USE SCHEMA on schema, SELECT on table or view |
| Write data to a table | USE CATALOG on catalog, USE SCHEMA on schema, MODIFY on table |
| Create a schema in a catalog | USE CATALOG on catalog, CREATE SCHEMA on catalog |
| Create a table in a schema | USE CATALOG on catalog, USE SCHEMA on schema, CREATE TABLE on schema |
| Execute a function | USE CATALOG on catalog, USE SCHEMA on schema, EXECUTE on function |
| Read files from a volume | USE CATALOG on catalog, USE SCHEMA on schema, READ VOLUME on volume |
Checkpoint 2 of 7· Check yourself
A data engineer needs to create new tables in sales.staging and do nothing else. Which grant set follows least privilege?
Creating a table needs both usage privileges and CREATE TABLE on the schema. Anything less fails, and the catalog-wide options grant far more than the task requires.
“USE CATALOG on catalog, USE SCHEMA on schema, CREATE TABLE on schema”Source: docs.databricks.com
Checkpoint 3 of 7· Exam question
A data engineer runs `SELECT * FROM sales.gold.transactions` as user `analyst_maria`. An admin has granted `SELECT` on the table `sales.gold.transactions` directly to `analyst_maria`, but the query still fails with a permission-denied error, and `analyst_maria` has no other grants on the `sales` catalog or the `gold` schema. What is the most likely cause, and what should the admin grant to fix it?
Correct answer: A — The `SELECT` grant alone is insufficient because reaching a table also requires `USE CATALOG` on `sales` and `USE SCHEMA` on `sales.gold`; granting both usage privileges to `analyst_maria` resolves the failure.
- A. Unity Catalog's securable-object hierarchy requires usage privileges on every containing catalog and schema before a privilege granted on a child object, such as `SELECT` on a table, takes effect. Adding `USE CATALOG` on `sales` and `USE SCHEMA` on `sales.gold` supplies the missing path-level access without widening the analyst's rights beyond that one table.
- B. This is incorrect because `SELECT` applies equally to managed tables, external tables, and views in Unity Catalog. `MODIFY` grants insert, update, and delete rights and would not fix a read-only query failure, and it would also over-grant write access the analyst does not need.
- C. `WITH GRANT OPTION` only allows the grantee to re-grant the same privilege to other principals; it does not add coverage for parent catalogs or schemas and would not change whether the query itself succeeds.
- D. Unity Catalog grants take effect immediately once issued; there is no propagation delay to wait out. The failure here is caused by missing usage privileges on the object hierarchy, not by replication lag.
3.Inheritance, MANAGE, BROWSE and child privileges
A privilege granted on a container object is inherited. It applies to every current child and every future child. SELECT on a catalog lets the grantee read every table in that catalog (given usage privileges), including tables created next year. That is convenient, and it is also the most common way access ends up broader than intended. For least privilege, grant at the lowest level that covers the real need, and use catalog-level grants only when access to the whole catalog really is intended.
The privileges below exist mainly so you can hand out *part* of an owner's power:
- MANAGE lets a user manage privileges, transfer ownership, rename and drop an object without owning it. On a container, MANAGE is inherited by all children. It also needs fewer usage privileges: MANAGE on a catalog needs none at all. That reduction covers metadata management only. Data-access privileges such as SELECT still need the usual usage privileges. - ALL PRIVILEGES means every applicable privilege for the object type, but it does not include MANAGE or READ METADATA (or the EXTERNAL USE privileges). Granting ALL PRIVILEGES does not let someone administer grants. - BROWSE, granted at catalog level, lets users discover objects, see names, descriptions and tags, and request access, without any access to data. Databricks recommends granting it on catalogs to the All account users group. - Composite and child privileges. MANAGE has the children READ METADATA and MANAGE ACCESS CONTROL. MODIFY has the children INSERT, UPDATE and DELETE (Beta). A composite and its children are granted and revoked independently. A writer who should only append can get INSERT instead of MODIFY.
Checkpoint 4 of 7· Match them up
Match each privilege to the narrow need it serves
Tap a term, then the definition that fits it.
Each of these is a narrower alternative to a broader grant: BROWSE instead of SELECT for discovery, READ METADATA and MANAGE instead of ownership, INSERT instead of MODIFY.
“READ METADATA grants read-only visibility into an object's metadata, without the modification and management abilities that MANAGE includes.”Source: docs.databricks.com
Checkpoint 5 of 7· Exam question
The platform team is onboarding a new BI team that needs read-only access to explore data in the `dev_catalog.reporting` schema only, and nothing else in the metastore. Which of the following GRANT statements, issued together for the group `bi_readers`, correctly implement least-privilege access for this requirement? (Select all that apply.)(Select 3)
Correct answers: A, B, C — `GRANT USE CATALOG ON CATALOG dev_catalog TO bi_readers;` — required so members of the group can reference objects inside the catalog before any deeper schema- or table-level grant can take effect.; `GRANT USE SCHEMA ON SCHEMA dev_catalog.reporting TO bi_readers;` — required so members of the group can reference objects inside that specific schema without gaining access to the rest of the catalog.; `GRANT SELECT ON SCHEMA dev_catalog.reporting TO bi_readers;` — grants read access to every current and future table and view in that schema without exposing any other schema in the catalog.
- A. Usage on the containing catalog is a prerequisite for reaching any schema or table inside it, and granting only `USE CATALOG` does not by itself expose data, so it is a correctly scoped part of a least-privilege setup.
- B. Usage on the specific schema narrows the group's reach to that one schema rather than every schema in the catalog, which is exactly the boundary a least-privilege design for a single reporting team needs.
- C. A schema-level `SELECT` grant covers current and future tables and views in `dev_catalog.reporting` automatically, giving the BI team read access to everything they need for exploration without a separate grant per table.
- D. This over-grants access: it gives the group create, modify, and administrative rights across every schema in `dev_catalog`, far beyond the read-only access to one schema that the BI team requires.
- E. `MODIFY` grants write access (insert, update, delete) on the schema's tables, which contradicts the read-only exploration requirement and is unnecessary for a BI team that only queries data.
- F. Transferring ownership hands the group full administrative control, including the ability to grant and revoke other principals' access and drop objects, which is a much broader right than the read-only access the requirement calls for.
Sources1
4.Granting, revoking and auditing privileges
You can manage privileges with SQL, the Databricks CLI, Terraform or Catalog Explorer. Four kinds of principal can grant a privilege on an object: the object's owner, the owner of the catalog or schema that contains it, a user with MANAGE on it, and a metastore admin. Every securable has an owner, and the owner holds all privileges on it.
The documented example below grants a group what it needs to create tables in one schema. It is the three-privilege rule written as SQL:
GRANT CREATE TABLE ON SCHEMA main.default TO `finance-team`;
GRANT USE SCHEMA ON SCHEMA main.default TO `finance-team`;
GRANT USE CATALOG ON CATALOG main TO `finance-team`;Grant to groups where you can. Principals can be users, service principals (identified by their applicationId) or groups, and names that contain special characters must be wrapped in backticks. Registered models are a type of function, so model privileges use ON FUNCTION:
Checkpoint 6 of 7· Fill the gap
Which securable type completes this grant of inference access to a registered model?
GRANT EXECUTE ON ? prod.ml_team.iris_model TO `ml-team-acme`;Registered models are a type of function, so the grant uses GRANT ON FUNCTION.
Source: docs.databricks.comTo review access, run SHOW GRANTS. Metastore admins, owners, owners of the containing catalog or schema, and users with READ METADATA or MANAGE see every grant on the object. Everyone else sees only their own. REVOKE ... FROM removes a privilege. It is idempotent and succeeds even when the privilege was never granted. Because composite and child privileges are independent, revoking MODIFY does not remove an INSERT that was granted separately, so check SHOW GRANTS after revoking.
SHOW GRANTS ON SCHEMA main.default;Checkpoint 7 of 7· Put it in order
Put the Catalog Explorer steps for granting a privilege in order
- 1.Select the object, such as a catalog, schema, table, or view
- 2.Click Grant
- 3.Go to the Permissions tab
- 4.Select the permissions to grant
- 5.Enter the email address for a user or the name of a group
- 6.In your Databricks workspace, click Catalog
You go to the object first and open its Permissions tab. Then you pick the principal and the privileges.
“Select the object, such as a catalog, schema, table, or view.”Source: docs.databricks.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Granting SELECT on a table is enough for a user to query it.Why is that wrong?
Reading also requires USE CATALOG on the parent catalog and USE SCHEMA on the parent schema. All three privileges are required.
Covered in The three-privilege rule: usage privileges on every parent
2.ALL PRIVILEGES on an object lets the grantee manage grants on it.Why is that wrong?
ALL PRIVILEGES excludes MANAGE and READ METADATA, so it does not let someone administer access.
3.Privileges on a registered model are granted with GRANT ... ON MODEL.Why is that wrong?
Registered models are a type of function, so model privileges are granted with GRANT ... ON FUNCTION.
Covered in Granting, revoking and auditing privileges
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://docs.databricks.com/aws/en/data-governance/unity-catalog/access-control/permissions-conceptsOfficial docs
“Schemas contain tables, views, volumes, and functions as direct children.”
↩︎ Securable objects and the default-deny starting point“this prevents table owners from granting access outside approved boundaries.”
↩︎ The three-privilege rule: usage privileges on every parent“that privilege automatically applies to all current and future child objects.”
↩︎ Inheritance, MANAGE, BROWSE and child privileges“Data-access privileges such as SELECT and MODIFY still require USE CATALOG and USE SCHEMA, even for users with MANAGE.”
↩︎ Inheritance, MANAGE, BROWSE and child privileges“BROWSE allows users to discover objects and view their metadata without granting access to the underlying data.”
↩︎ Inheritance, MANAGE, BROWSE and child privileges“MODIFY is a composite privilege, and INSERT, UPDATE, and DELETE (Beta) are its children.”
↩︎ Inheritance, MANAGE, BROWSE and child privileges“Granting a composite privilege does not grant its child privileges”
↩︎ Granting, revoking and auditing privileges“A user or group must be explicitly granted a privilege to perform an action.”
↩︎ Key concept“Having only the SELECT privilege on a table is not sufficient to read it”
↩︎ Exam trap 1“ALL PRIVILEGES does not include the EXTERNAL USE SCHEMA, EXTERNAL USE LOCATION, MANAGE, or READ METADATA privileges.”
↩︎ Exam trap 2“Having only the SELECT privilege on a table is not sufficient to read it”
↩︎ Prediction“USE CATALOG on catalog, USE SCHEMA on schema, CREATE TABLE on schema”
↩︎ Checkpoint“READ METADATA grants read-only visibility into an object's metadata, without the modification and management abilities that MANAGE includes.”
↩︎ Checkpoint - 2.
“All workspace users receive the USE CATALOG privilege on the workspace catalog.”
↩︎ Securable objects and the default-deny starting point“A REVOKE statement succeeds even if the specified privileges were not granted in the first place.”
↩︎ Granting, revoking and auditing privileges“To grant a privilege on a model, you must use GRANT ON FUNCTION.”
↩︎ Exam trap 3“Initially, users have no access to data in a metastore.”
↩︎ Checkpoint“Select the object, such as a catalog, schema, table, or view.”
↩︎ Checkpoint - 3.https://docs.databricks.com/aws/en/data-governance/unity-catalog/access-control/privileges-referenceOfficial docs
“Required to interact with any object inside a schema. Does not itself grant access to data.”
↩︎ The three-privilege rule: usage privileges on every parent