What you will be able to do
- Explain which Unity Catalog securables are containers and how a grant on a container reaches its current and future children
- Distinguish catalog- and schema-level grants, which inherit, from metastore-level grants, which do not
- Work out the full set of grants a principal needs to read or write a table, including the USE CATALOG and USE SCHEMA usage privileges
Key concept
Privilege inheritance — In Unity Catalog, a privilege granted on a container object (a catalog or a schema) applies to every object inside that container. That includes objects that exist now and objects created later. Privileges granted on the metastore are the exception: they cover metastore-level operations only and do not flow down to catalogs.
1.The hierarchy that access control is built on
Unity Catalog stores data and metadata in a top-level container called the metastore. Inside the metastore, data is addressed through a three-level namespace, catalog.schema.table. That namespace is more than a naming scheme. The documentation describes the hierarchy as the foundation for access control. Every object in it is a *securable object*, and you control access by granting privileges such as SELECT, MODIFY or USE SCHEMA on those securables to a principal (a user, service principal, or group).
Securables fall into two kinds, and the difference decides how far a grant reaches.
- Container objects hold child objects. There are two. A catalog is the top level of the namespace, and its direct children are schemas. A schema is the middle level, and its direct children are tables, views, volumes and functions. - Non-container objects are tables, views, volumes and functions. They have no children.
Container objects play a special role in the permissions model. A grant on a container can affect its children through inheritance. Owning a container also lets you manage all of its children. Containers also carry *creation* privileges that let users create children inside them, such as CREATE SCHEMA on a catalog and CREATE TABLE on a schema.
No. A table is a non-container object, so it has no children for a privilege to flow to. A grant on a table covers that table only. Inheritance only starts at catalogs and schemas.
Checkpoint 1 of 6· Check yourself
Which of these securable objects is a container object, so that a privilege granted on it can be inherited by child objects?
Catalogs and schemas are the container objects. Tables, volumes and functions are non-container objects with no children, so nothing can inherit from them.
“Schemas: The middle level of the three-level namespace. Schemas contain tables, views, volumes, and functions as direct children.”Source: docs.databricks.com
Sources1
2.How catalog and schema grants flow downward
Inheritance is what makes the model manageable at scale. Grant SELECT on a schema and the grantee can read every table and view in it, including ones added later. Grant SELECT on a catalog and it reaches every table in every schema of that catalog. The privileges reference lists the object-level privileges you can grant on a catalog for this purpose, among them SELECT, MODIFY, EXECUTE, READ VOLUME, WRITE VOLUME, CREATE TABLE and USE SCHEMA. It says granting them at the catalog level applies them to current and future objects in the catalog. A schema accepts the same kind of grant for the objects it contains.
Denials follow the same path. When you deny a privilege on a parent object, that privilege is automatically denied on all current and future child objects. These inheritance rules apply whether you assign a privilege manually with GRANT or use attribute-based access control (ABAC) policies to grant or deny it.
Inheritance makes a grant easy to over-scope. For catalogs, the documentation warns that catalog-level privileges are broad and tells you to be careful when granting them. For schemas, it tells you to review what objects a schema contains before granting privileges on it.
Inheritance described here is the behaviour of Privilege Model version 1.0. A metastore created during the public preview, before August 25, 2022, might still be on an earlier privilege model that doesn't support the current inheritance model. It must be upgraded to get privilege inheritance.
| Grant made on | Reaches | Documentation caution |
|---|---|---|
| Catalog | All current and future schemas, tables, views, volumes and functions in the catalog | Catalog-level privileges are broad. Be careful when granting them. |
| Schema | All current and future tables, views, volumes and functions in the schema | Review what objects the schema contains before granting. |
| Table or view | That object only (it has no children) | None. This is the narrowest grant. |
| Metastore | Metastore-level operations only. Does not inherit to child objects, except READ METADATA, which inherits to all objects in the metastore. | CREATE CATALOG does not grant access to data in the catalog. |
Checkpoint 2 of 6· Check yourself
A data steward wants a group to be able to read every view, now and in future, in the schema finance.curated, but nothing in other schemas of the finance catalog. Where should the SELECT grant be made?
SELECT on the schema reaches current and future views in that schema only. A catalog grant would also cover the other schemas, and metastore grants do not inherit at all.
“SELECT granted at the schema or catalog level applies to all current and future views in that schema or catalog.”Source: docs.databricks.com
Checkpoint 3 of 6· Exam question
A platform team grants `SELECT` on the `finance` catalog to the group `analysts`. The catalog currently holds the `reporting` and `raw` schemas, and the team plans to add a new `budgets` schema with several tables next quarter. No further grants are planned. Once `budgets` exists and is populated, what access will `analysts` have to its tables?
Correct answer: A — The group can query the new tables immediately, because a catalog-level `SELECT` grant automatically extends to every current and future child schema and object.
- A. Unity Catalog privilege inheritance is dynamic: a grant on a container object such as a catalog applies to objects that exist now and to objects created afterward, so the new schema and its tables inherit the grant without any extra action.
- B. This describes a static snapshot model that Unity Catalog does not use; re-running the grant is unnecessary because inheritance already covers objects added after the original grant.
- C. This assumes inheritance is limited to pre-existing children, which reverses the actual behavior — a direct grant on the new schema would be redundant since the catalog-level grant already covers it.
- D. This misstates the depth of propagation; catalog-level grants flow through every level of the container hierarchy beneath them, not just the immediate child level.
3.Where inheritance stops: the metastore
The metastore is the top-level securable. It contains every catalog in a region and also holds objects such as storage credentials, external locations, connections, shares, recipients, providers and clean rooms. You might expect a grant at the very top to flow into everything below it. It does not.
Metastore privileges authorise metastore-level operations. For example, CREATE CATALOG lets a user create a catalog in the metastore, but it does not give that user access to data in any catalog. The securable objects reference says metastore-level grants are scoped to metastore-level operations only. It contrasts this explicitly with catalog and schema grants, which do inherit to current and future children.
Checkpoint 4 of 6· Check yourself
A platform engineer has CREATE CATALOG on the metastore and nothing else. Which statement is accurate?
Metastore privileges authorise metastore-level operations and do not inherit to child objects. CREATE CATALOG lets them create catalogs, not read data inside catalogs.
“privileges granted at the metastore level do not inherit to child objects in the hierarchy.”Source: docs.databricks.com
4.Usage privileges: the gate inheritance does not remove
Inheritance tells you which objects a privilege reaches. It does not let a user past the containers above those objects. USE CATALOG and USE SCHEMA are *usage privileges*. To work with any object in a catalog you need USE CATALOG on that catalog. To work with any object in a schema you need USE SCHEMA on that schema. Most operations on a table, view, volume or function need all three of the following:
1. USE CATALOG on the parent catalog
2. USE SCHEMA on the parent schema
3. The operation's own privilege, such as SELECT, MODIFY, EXECUTE or READ VOLUME
The usage privileges themselves give no access to data. They are prerequisites that sit alongside the object-level privilege. The documentation's own example of granting a group the ability to create tables in a schema uses three statements, one for each level:
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`;The gate also limits what owners can share. A table owner may want to share a table with other users, but those users still cannot access it without USE CATALOG and USE SCHEMA on its parents. Only catalog and schema owners, or users with MANAGE, can grant those usage privileges. The documentation says this prevents table owners from granting access outside approved boundaries. So inheritance pushes privileges down, and usage privileges let administrators at higher levels decide who can get in at all.
Ownership is a separate route to access. The principal that creates an object becomes its initial owner, and object owners can automatically perform all capabilities on the object they own. So a principal who creates a catalog owns it and can act on it, for example by granting privileges on it, without being granted those capabilities separately. Ownership does not inherit downward, though. The catalog owner does not automatically own the schemas inside it, but does automatically get the ability to manage all of its child objects. The explicit GRANT statements above matter for everyone else: principals who do not own the objects.
Checkpoint 5 of 6· Fill the gap
Complete the statement that gives the finance-team the usage privilege on the main catalog.
GRANT ? ON CATALOG main TO `finance-team`;USE CATALOG is the usage privilege for a catalog. It is the outermost gate a principal needs before it can work with anything inside main. USE SCHEMA is the matching gate on a schema, and CREATE SCHEMA is a creation privilege, not a usage privilege.
Checkpoint 6 of 6· Exam question
A metastore admin grants `CREATE CATALOG` at the metastore level to the group `platform-eng`, expecting members to also gain the ability to create tables inside any catalog they subsequently create. After creating a new catalog, a `platform-eng` member finds they cannot create a table inside it without an additional grant. What explains this behavior?
Correct answer: A — Privileges granted at the metastore level do not propagate to catalogs or their child objects, so usage and data privileges on the new catalog still need separate grants.
- A. Metastore-scoped grants control metastore-level operations, such as creating catalogs, but they are an exception to the general inheritance rule and do not cascade into the catalogs, schemas, or tables created beneath the metastore.
- B. Ownership of the metastore is not a prerequisite for metastore-level privileges to function; the actual cause is that those privileges simply do not cascade into child containers.
- C. There is no refresh delay involved here; the missing table-creation privilege is a direct consequence of metastore grants not inheriting to catalogs, not a propagation lag.
- D. The premise is wrong: `CREATE CATALOG` already succeeded and produced a new catalog, so the privilege clearly did more than expose metadata — the real issue is that it does not cascade further down.
Sources1
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A privilege granted on the metastore flows down to every catalog, schema and table, the same way catalog grants do.Why is that wrong?
Metastore-level grants cover metastore-level operations only and do not inherit. The single documented exception is READ METADATA.
Covered in Where inheritance stops: the metastore
2.SELECT on a table, whether granted directly or inherited, is enough to query it.Why is that wrong?
The user also needs USE CATALOG on the parent catalog and USE SCHEMA on the parent schema. All three are required.
Covered in Usage privileges: the gate inheritance does not remove
3.A schema- or catalog-level grant only covers the tables that existed when the grant was made.Why is that wrong?
Container grants apply to current and future child objects. Tables created later are covered automatically.
Covered in How catalog and schema grants flow downward
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
“Catalogs: The top level of the three-level namespace. Catalogs contain schemas as direct children.”
↩︎ The hierarchy that access control is built on“Schemas contain tables, views, volumes, and functions as direct children.”
↩︎ The hierarchy that access control is built on“Non-container objects, like tables, views, volumes, and functions, don't contain child objects.”
↩︎ The hierarchy that access control is built on“When you grant a privilege on a container object, that privilege automatically applies to all current and future child objects.”
↩︎ How catalog and schema grants flow downward“Denials inherit downward the same way.”
↩︎ How catalog and schema grants flow downward“These inheritance rules apply whether you assign a privilege manually with GRANT or use attribute-based access control (ABAC) policies to grant or deny it.”
↩︎ How catalog and schema grants flow downward“Having only the SELECT privilege on a table is not sufficient to read it if you lack USE CATALOG or USE SCHEMA”
↩︎ Usage privileges: the gate inheritance does not remove“this prevents table owners from granting access outside approved boundaries.”
↩︎ Usage privileges: the gate inheritance does not remove“The principal that creates an object becomes its initial owner.”
↩︎ Usage privileges: the gate inheritance does not remove“Object owners can automatically perform all capabilities on the object they own.”
↩︎ Usage privileges: the gate inheritance does not remove“When you grant a privilege on a container object, that privilege automatically applies to all current and future child objects.”
↩︎ Key concept“Having only the SELECT privilege on a table is not sufficient to read it if you lack USE CATALOG or USE SCHEMA”
↩︎ Exam trap 2“Schemas: The middle level of the three-level namespace. Schemas contain tables, views, volumes, and functions as direct children.”
↩︎ Checkpoint - 2.
“Due to inheritance, catalog-level privileges are broad. Be careful when granting them to users.”
↩︎ How catalog and schema grants flow downward“Review what objects are contained in the schema before granting privileges to users.”
↩︎ How catalog and schema grants flow downward“However, this doesn't grant the user access to data within the catalog.”
↩︎ Where inheritance stops: the metastore“privileges granted at the metastore level do not inherit to child objects in the hierarchy.”
↩︎ Exam trap 1“granting SELECT on a schema automatically grants SELECT on all current and future tables in that schema.”
↩︎ Prediction“SELECT granted at the schema or catalog level applies to all current and future views in that schema or catalog.”
↩︎ Checkpoint“privileges granted at the metastore level do not inherit to child objects in the hierarchy.”
↩︎ Checkpoint - 3.https://docs.databricks.com/aws/en/data-governance/unity-catalog/access-control/privileges-referenceOfficial docs
“If you created your Unity Catalog metastore during the public preview (before August 25, 2022), you might be on an earlier privilege model”
↩︎ How catalog and schema grants flow downward“When granted on the metastore, READ METADATA inherits down to all objects in the metastore.”
↩︎ Where inheritance stops: the metastore“You can grant these privileges at the catalog level to apply them to current and future objects in the catalog.”
↩︎ Exam trap 3