What you will be able to do
- Identify who is allowed to grant and revoke privileges on a Unity Catalog object
- Grant and revoke privileges with SQL and from the Permissions tab in Catalog Explorer
- Explain where DENY works, how it takes precedence, and how to undo it
- Grant at the metastore level and inspect existing grants with SHOW GRANTS
1.Who is allowed to grant
Every Unity Catalog securable has an owner. The owner has every privilege on the object, including the right to grant privileges to others. Four kinds of principal can grant privileges on an object:
- the object's owner
- the owner of the catalog or schema that contains it
- a user with MANAGE on the object
- a metastore admin
Account admins can also grant privileges directly on the metastore. Owners can pass MANAGE to someone else, which lets that person administer the object's permissions without owning it. For revoking, the documentation lists the same set: metastore admin, MANAGE on the object, the object's owner, or the owner of the parent catalog or schema.
Ownership of a container is also why a schema owner can manage tables they did not create: owning a catalog or schema gives the ability to manage all of its child objects. When a workspace is enabled for Unity Catalog automatically, workspace admins are the default owners of the workspace catalog, so they can manage privileges on it and everything inside it.
MANAGE is similar to ownership but is not the same. An owner holds all privileges on the object. A user with MANAGE is not automatically granted SELECT or any other specific privilege, although they can explicitly grant those privileges to themselves. MANAGE is also not part of ALL PRIVILEGES.
Checkpoint 1 of 7· Check yourself
A user has been granted MANAGE on a table but does not own it. Which statement is correct?
MANAGE lets a user manage privileges on the object, but it does not give them the object's data privileges. They would have to grant those to themselves explicitly.
“Users with MANAGE are not automatically granted all privileges on the object.”Source: docs.databricks.com
2.Granting with SQL and with Catalog Explorer
The SQL form is GRANT <privilege-type> ON <securable-type> <securable-name> TO <principal>. You can run it in a notebook or the SQL query editor. Because of the usage-privilege rule, a working grant usually takes several statements. To let the finance-team group create tables in main.default, the group needs the usage privilege on each parent and also the creation privilege. Start at the top of the hierarchy:
GRANT USE CATALOG ON CATALOG main TO `finance-team`;GRANT USE SCHEMA ON SCHEMA main.default TO `finance-team`;GRANT CREATE TABLE ON SCHEMA main.default TO `finance-team`;The principal can be a user, a group or a service principal. A service principal is written as its application ID, in backticks because of the dashes:
GRANT SELECT ON TABLE t TO `fab9e00e-ca35-11ec-9d64-0242ac120002`;Catalog Explorer does the same thing through the UI. For catalogs, schemas, tables and views, the Permissions tab is where grants are shown, added and removed. The securable type in SQL has one quirk. Registered models are a type of function, so privileges on a model are granted with ON FUNCTION.
Checkpoint 2 of 7· Put it in order
Put the Catalog Explorer steps for granting a privilege in order
- 1.Go to the Permissions tab and click Grant
- 2.Select the object, such as a catalog, schema, table, or view
- 3.Enter the email address for a user or the name of a group
- 4.Select the permissions to grant, then click OK
- 5.In your Databricks workspace, click Catalog
The UI flow is: open Catalog, choose the object, open Permissions, click Grant, pick the principal, choose the privileges, confirm.
“Enter the email address for a user or the name of a group.”Source: docs.databricks.com
Checkpoint 3 of 7· Fill the gap
Which securable type completes this grant of EXECUTE on 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 has to use ON FUNCTION.
Source: docs.databricks.com3.REVOKE: making sure a privilege is gone
REVOKE uses the same form as GRANT, with FROM in place of TO: REVOKE CREATE TABLE ON SCHEMA main.default FROM finance-team;. In Catalog Explorer, open the object's Permissions tab, select a granted privilege, click Revoke, then confirm.
Revoking ALL PRIVILEGES removes the ALL PRIVILEGES grant and every individual privilege it implied. It does not touch privileges outside ALL PRIVILEGES: MANAGE, READ METADATA, EXTERNAL USE LOCATION and EXTERNAL USE SCHEMA stay in place. A REVOKE takes away only an *explicit* grant on the object you name. A privilege that comes from a parent container through inheritance stays until it is revoked on that container.
Ownership is a different thing from a grant, and a REVOKE does not change it. Ownership is moved with ALTER ... OWNER TO. You can transfer it if you are the current owner, a metastore admin, the owner of the container (the catalog for a schema, the schema for a table), or a user with MANAGE on the object.
ALTER SCHEMA some_schema OWNER TO `some-group`;Checkpoint 4 of 7· Check yourself
A user holds ALL PRIVILEGES and, through a separate grant, MANAGE on a schema. An admin runs REVOKE ALL PRIVILEGES ON SCHEMA ... FROM that user. What remains?
Revoking ALL PRIVILEGES removes the privileges it implied. MANAGE was never part of ALL PRIVILEGES, so it is left alone.
“In Unity Catalog, when ALL PRIVILEGES is revoked, both the ALL PRIVILEGES grant and any individual privileges implied by it are revoked.”Source: docs.databricks.com
Checkpoint 5 of 7· Exam question
A data engineer is leaving the team and needs to transfer ownership of the schema `sales.orders` to a teammate, `jane@company.com`, without dropping or recreating the schema. Which approach is correct?
Correct answer: A — Run `ALTER SCHEMA sales.orders OWNER TO \`jane@company.com\`` so that ownership, and the ability to manage grants on every object the schema contains, transfers to the new principal directly.
- A. Correct. `ALTER SCHEMA ... OWNER TO` reassigns ownership of the schema directly, giving the new owner full control over the schema and management rights over its contained objects, without dropping anything.
- B. Incorrect. `ALL PRIVILEGES` grants every applicable capability except a defined set that includes `MANAGE`, and it never transfers ownership; ownership changes require the `OWNER TO` clause.
- C. Incorrect. Unity Catalog schema ownership can be reassigned in place with `ALTER SCHEMA ... OWNER TO`, so dropping and recreating the schema is unnecessary and destructive.
- D. Incorrect. Account admin membership does not transfer ownership of a specific schema; ownership is reassigned explicitly with an `ALTER ... OWNER TO` statement, not by group membership.
4.DENY: precedence, cascade and its legacy scope
The exam guide lists DENY alongside GRANT and REVOKE, but its scope is narrow. The DENY statement belongs to the legacy hive_metastore catalog. On those objects, a DENY takes precedence over any grant, explicit or implicit. It also cascades: denying SELECT on a schema implicitly denies it on every object in that schema, and denying a privilege on a catalog denies it on every schema in that catalog. To lift a DENY, you REVOKE the same privilege.
-- Deny Alf the right to query `t`.
> DENY SELECT ON TABLE t TO `alf@melmak.et`;
-- Undo the `DENY`.
> REVOKE SELECT ON TABLE t FROM `alf@melmak.et`;Unity Catalog has no DENY statement. The DENY page points instead to ABAC DENY policies (Beta). These are attached at the metastore, catalog or schema level, match on governed tags, and always take precedence over any grant. They are narrow in what they deny: today they deny only the MANAGE ACCESS CONTROL privilege, which covers granting and revoking privileges, changing ownership and managing ABAC policies. MANAGE ACCESS CONTROL can be denied but not granted. So an ABAC DENY policy cannot block SELECT on a table the way the hive_metastore DENY statement can. Those policies belong to the ABAC topic. For this objective, the point is that plain SQL DENY is a hive_metastore statement.
| Statement | Effect | Where it applies |
|---|---|---|
| GRANT | Gives a privilege on a securable to a principal | Unity Catalog securables (metastore, catalog, schema, table and more) |
| REVOKE | Removes an explicitly granted or denied privilege; succeeds even if none existed | Unity Catalog securables, and undoes DENY on hive_metastore objects |
| DENY | Blocks a privilege, overriding any explicit or implicit grant; cascades from schema or catalog | hive_metastore catalog and its objects only |
Checkpoint 6 of 7· Check yourself
On a hive_metastore schema, a user was granted SELECT on a table and was also denied SELECT on the parent schema. What is the outcome, and how is it fixed?
A DENY overrides any explicit or implicit grant and cascades from the schema to its objects. Revoking the same privilege lifts it.
“To undo a DENY you REVOKE the same privilege from the principal.”Source: docs.databricks.com
5.Metastore-level grants and inspecting grants
Only a metastore admin or an account admin can grant or revoke on the metastore itself, which is where privileges such as CREATE CATALOG live. The SQL has no object name: GRANT <privilege-type> ON METASTORE TO <principal>; and REVOKE <privilege-type> ON METASTORE FROM <principal>;. Unity Catalog assumes the metastore attached to the current workspace. In Catalog Explorer, click the gear icon at the top of the Catalog pane, choose Metastore, and use its Permissions tab to grant, or select a user or group and click Revoke.
Use SHOW GRANTS to check the result. It lists the privileges that affect an object, whether inherited, denied or granted, and you can narrow it to one principal. Metastore admins, the object's owner, the owner of the parent container, and anyone with READ METADATA or MANAGE on the object can see all of its grants. Everyone else sees only their own.
SHOW GRANTS ON SCHEMA main.default;Checkpoint 7 of 7· Check yourself
A user is not the owner of a table, has no MANAGE or READ METADATA on it, and is not a metastore admin. What does SHOW GRANTS ON TABLE show them?
Without the listed permissions, a user can still view their own grants on the object, but not those of other principals.
“If you do not have the above permissions, you can view only your own grants on the object.”Source: docs.databricks.com
A metastore grant takes no name, because the metastore attached to the workspace is assumed. The correct form is GRANT CREATE CATALOG ON METASTORE TO <principal>. The same holds for revoking: REVOKE <privilege-type> ON METASTORE FROM <principal>.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.You can use the SQL DENY statement to block a group from a Unity Catalog table.Why is that wrong?
The DENY statement applies only to the hive_metastore catalog. Unity Catalog points to ABAC DENY policies instead.
2.An ABAC DENY policy can be used to block SELECT on a Unity Catalog table.Why is that wrong?
ABAC DENY policies are currently scoped to the MANAGE ACCESS CONTROL privilege only.
3.A REVOKE fails if the principal never held the privilege, so you have to check SHOW GRANTS first.Why is that wrong?
REVOKE succeeds either way. It only ensures the privilege is absent.
Covered in REVOKE: making sure a privilege is gone
Practise it for real
Give a group the right to create tables in main.default, check the grants, then remove table creation
1.Run the three GRANT statements: CREATE TABLE and USE SCHEMA on SCHEMA main.default, and USE CATALOG on CATALOG main, each TO
finance-team.Why: Creating a table needs USE CATALOG, USE SCHEMA and CREATE TABLE together.
You should see: Each statement completes without error.
2.Run SHOW GRANTS ON SCHEMA main.default;
Why: This confirms which privileges the group now holds on the schema.
You should see: Rows for finance-team with CREATE TABLE and USE SCHEMA on SCHEMA main.default.
3.Run REVOKE CREATE TABLE ON SCHEMA main.default FROM
finance-team;Why: This removes the creation right but keeps the usage privileges.
You should see: The statement succeeds.
4.Run SHOW GRANTS ON SCHEMA main.default; again, or open the schema's Permissions tab in Catalog Explorer.
Why: This checks the revoke from SQL or from the UI.
You should see: Only the USE SCHEMA row remains for finance-team.
Stuck? Get a nudge
If the GRANT is rejected, check that you are the schema's owner, the catalog's owner, a metastore admin, or hold MANAGE on the schema.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Object owners have all privileges on that object, including the ability to grant privileges to other principals.”
↩︎ Who is allowed to grant“Note that registered models are a type of function.”
↩︎ Granting with SQL and with Catalog Explorer“You can transfer object ownership if you are the current owner, a metastore admin, the owner of the container”
↩︎ REVOKE: making sure a privilege is gone“you do not include the metastore name, because the metastore that is attached to your workspace is assumed.”
↩︎ Metastore-level grants and inspecting grants“REVOKE <privilege-type> ON METASTORE FROM <principal>;”
↩︎ Metastore-level grants and inspecting grants“It ensures that the privileges are not present, regardless of their previous state.”
↩︎ Exam trap 3“Enter the email address for a user or the name of a group.”
↩︎ Checkpoint“If you do not have the above permissions, you can view only your own grants on the object.”
↩︎ Checkpoint - 2.https://docs.databricks.com/aws/en/data-governance/unity-catalog/access-control/permissions-conceptsOfficial docs
“When you own a container object, you automatically get the ability to manage all child objects”
↩︎ Who is allowed to grant - 3.https://docs.databricks.com/aws/en/data-governance/unity-catalog/access-control/privileges-referenceOfficial docs
“Users with MANAGE are not automatically granted all privileges on the object.”
↩︎ Who is allowed to grant - 4.
“A user, service principal, or group to which the privileges are granted.”
↩︎ Granting with SQL and with Catalog Explorer - 5.
“Revokes an explicitly granted or denied privilege on a securable object from a principal.”
↩︎ REVOKE: making sure a privilege is gone“A REVOKE statement succeeds even if the specified privileges were not granted in the first place.”
↩︎ Prediction“In Unity Catalog, when ALL PRIVILEGES is revoked, both the ALL PRIVILEGES grant and any individual privileges implied by it are revoked.”
↩︎ Checkpoint - 6.
“Denying a privilege takes precedent over any explicit or implicit grant.”
↩︎ DENY: precedence, cascade and its legacy scope“This statement applies only to the hive_metastore catalog and its objects.”
↩︎ Exam trap 1“This statement applies only to the hive_metastore catalog and its objects.”
↩︎ Prediction“To undo a DENY you REVOKE the same privilege from the principal.”
↩︎ Checkpoint - 7.
“always taking precedence over any grant”
↩︎ DENY: precedence, cascade and its legacy scope“deny the MANAGE ACCESS CONTROL privilege on the supported securable types”
↩︎ DENY: precedence, cascade and its legacy scope - 8.
“Displays all privileges (inherited, denied, and granted) that affect the securable object.”
↩︎ Metastore-level grants and inspecting grants
Also cited
“currently scoped to the MANAGE ACCESS CONTROL privilege”
↩︎ Exam trap 2