What you will be able to do
- Identify who can grant privileges on a Unity Catalog object and how ownership differs from the MANAGE privilege
- Distinguish account admins, workspace admins and metastore admins by scope and capability
- Describe the default privileges that workspace admins and workspace users receive on an automatically enabled workspace
- Configure Restrict sharing for groups so that users acting as a role can't share the workspace assets that role owns
1.Ownership, MANAGE and who can grant
A new metastore starts locked. Initially, users have no access to its data. From there, ownership is the anchor of control. Every securable object has an owner, and the owner holds all privileges on it, including the right to grant privileges to others. Owning a container goes further: the owner of a catalog or schema can manage every child object, even children someone else owns.
The MANAGE privilege lets you hand over that control without handing over ownership. A user with MANAGE can manage privileges on the object, transfer its ownership, rename it and drop it. MANAGE granted on a container also covers every child object. MANAGE has lighter usage requirements. MANAGE on a catalog needs no usage privileges at all, and MANAGE on a schema needs only USE CATALOG on the parent. That relaxation covers metadata and management actions only. Reading or writing data still needs the usage privileges, even for users who hold MANAGE.
Transferring ownership follows the same pattern. The current owner, a metastore admin, the owner of the container, or a user with MANAGE on the object can transfer it. To see who owns an object, run DESCRIBE ... EXTENDED or open the object's Overview tab in Catalog Explorer.
DESCRIBE <securable-type> EXTENDED <catalog>.<schema>.<securable-name>;Checkpoint 1 of 6· Exam question
A senior analyst named Priya creates several Unity Catalog tables under the `marketing` schema while onboarding a new team. Six months later she transfers to a different department, and no one remaining on the marketing team can update table grants because she is still the sole listed owner. What should the team lead have done when the tables were first created to avoid this situation?
Correct answer: C — Reassign ownership of the tables and schema to a group representing the marketing team, rather than leaving an individual user as the sole owner, so ownership survives personnel changes.
- A. `MODIFY` only authorizes changing table contents such as inserting or deleting rows; it does not grant the ability to change ownership or manage privileges, so this would not have prevented the lockout Priya's departure caused.
- B. Sharing credentials violates basic account security practice and does not actually change who Unity Catalog recognizes as the owner, so grants would still be tied to Priya's individual account and this approach should never be used.
- C. Assigning ownership of production objects to a group rather than an individual is the recommended Unity Catalog practice specifically because group membership can change without leaving an object ownerless, which is exactly the failure mode described here.
- D. Workspace-level restrictions control which workspaces can bind to a catalog; they have no effect on who owns a specific table or schema and would not have transferred ownership away from Priya automatically.
Checkpoint 2 of 6· Check yourself
A steward holds MANAGE on the schema main.hr and USE CATALOG on main. They want to query main.hr.salaries themselves. What else do they need?
MANAGE lets the steward manage grants. It does not let them read data. Reading still needs USE SCHEMA and SELECT. The steward could grant those privileges to themselves, but they are not implied.
“Data-access privileges such as SELECT and MODIFY still require USE CATALOG and USE SCHEMA, even for users with MANAGE.”Source: docs.databricks.com
2.Account, workspace and metastore admin roles
Databricks has many admin roles. For Unity Catalog permissions, three matter most. Each has a different scope, so assigning the right one limits how far a single person's power reaches.
| Admin role | Scope | Required? | Primary purpose |
|---|---|---|---|
| Account admin | Entire Databricks account | Yes | Create metastores and workspaces, link metastores to workspaces, assign admin roles |
| Workspace admin | Single workspace | Yes | Manage workspace membership, job ownership, and workspace objects; create catalogs and other top-level Unity Catalog securables |
| Metastore admin | Single Unity Catalog metastore (one per cloud region) | No (optional) | Create and govern top-level Unity Catalog securables: catalogs, connections, external locations, and other metastore objects |
On a workspace enabled for Unity Catalog automatically (every workspace created after November 8, 2023), workspace admins receive metastore privileges such as CREATE CATALOG, CREATE EXTERNAL LOCATION and CREATE SHARE by default. They also own the workspace catalog. That ownership lets them manage privileges on anything inside it, including granting themselves access to its data. They have no direct data access by default, and every grant is audit-logged. Ordinary workspace users get USE CATALOG on the workspace catalog. On its default schema they also get USE SCHEMA, CREATE TABLE, CREATE VOLUME, CREATE MODEL, CREATE FUNCTION and CREATE MATERIALIZED VIEW.
With those defaults, the metastore admin role is optional. Workspace admins have one notable gap: they can create objects, but they can't make grants on, or change ownership of, existing objects they don't own. For that, for example to take over a catalog after its owner's account is removed, you need a metastore admin. Metastore admins own the metastore, so they can manage privileges or transfer ownership of any object in it. Databricks recommends assigning the metastore admin role to a group rather than an individual. Account admins can also limit workspace admins through the RestrictWorkspaceAdmins setting.
Checkpoint 3 of 6· Exam question
The `sales.transactions` table contains order records for customers across the US, EU, and APAC regions. Regional sales analysts should each see only the orders belonging to their own region when they query this single table, without the team maintaining three separate copies of the data. Which Unity Catalog feature should the engineer apply?
Correct answer: A — Apply a row filter function to `sales.transactions` with `ALTER TABLE ... SET ROW FILTER`, so rows are excluded whenever the function evaluates to false for the querying user's region.
- A. A row filter is a SQL user-defined function attached to the table that Unity Catalog evaluates per row at query time, excluding any row where the function returns false for the current user; this is the built-in mechanism for exactly this per-region visibility requirement on a single shared table.
- B. A column mask transforms or redacts the value of a specific column rather than removing entire rows, so it would hide or alter region-related values instead of restricting which order rows an analyst can see, which does not match the stated goal.
- C. Duplicating the table into three separate filtered views could technically work but directly contradicts the requirement to avoid maintaining multiple copies of the data, and it does not scale as regions or analysts change.
- D. Unity Catalog does not automatically infer row-level scoping from a group's name or an assumed region tag; without an explicit row filter attached to the table, granting plain `SELECT` would expose all regions' rows to every analyst group equally.
Checkpoint 4 of 6· Match them up
Match each admin role to its scope
Tap a term, then the definition that fits it.
Account admins span the whole account. Workspace admins act within one workspace. The optional metastore admin governs one metastore.
“Workspace admins operate within a single workspace.”Source: docs.databricks.com
Sources3
3.Workspace asset sharing controls for roles
Unity Catalog grants protect the data, but workspace assets bring their own risk. When users assume a role, they can create notebooks, SQL queries, SQL warehouses and jobs that the role owns, and by default the role can share those assets. Without another control, a user acting as a role with access to sensitive data could build a dashboard on that data and share it with users who lack access. To close that gap, Databricks provides a workspace-level setting called Restrict sharing for groups. Only a workspace administrator can configure it.
The scope is deliberately narrow. Admins can put an isolation boundary around roles used for exclusive access without stopping everyday collaboration. A user acting as a listed group can't share assets owned by that group, even with Can Manage permission on the asset. The restriction also applies to groups nested under a listed group. If clinical-trial-1-analysts is nested under clinical-trial-1, users acting as clinical-trial-1-analysts are restricted too. Two limits apply. System groups such as all account users, admins, users and account admins can't be added to the list. By default the list holds up to 100 groups.
To configure the setting, click your username in the upper right and select Settings, open the Advanced tab, find Restrict sharing for groups, click the edit button, select the groups, and click Save. To check that it works, assume the restricted role, open an asset the role owns and try to share it. The share option should be unavailable.
Checkpoint 5 of 6· Put it in order
Put the steps for restricting a group from sharing its workspace assets in order
- 1.Click Save
- 2.Click the Advanced tab
- 3.Click your username in the upper right and select Settings
- 4.Browse, search for and select the groups to restrict
- 5.Find Restrict sharing for groups and click the edit button
The setting lives on the Advanced tab of workspace Settings. You edit the Restrict sharing for groups entry, select the groups and save.
“Find Restrict sharing for groups.”Source: docs.databricks.com
Checkpoint 6 of 6· Check yourself
A workspace admin wants to stop risky sharing. Which group can be added to the restrict-sharing list?
System groups can never be added to the list. Ordinary groups used as roles, which are the intended targets, can be added.
“System groups, such as all account users, admins, users, and account admins, can't be added to the restrict sharing list.”Source: docs.databricks.com
Sources4
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A workspace admin can grant privileges on any Unity Catalog object in the workspace.Why is that wrong?
Workspace admins can create objects, but they can't make grants on, or change ownership of, existing objects they don't own. That needs a metastore admin.
Covered in Account, workspace and metastore admin roles
2.Can Manage permission on a notebook always lets you share it.Why is that wrong?
A user acting as a group on the restrict-sharing list can't share assets owned by that group, even with Can Manage.
Covered in Workspace asset sharing controls for roles
3.A user with MANAGE on a schema can read its tables without any usage privileges.Why is that wrong?
The reduced usage requirement covers only management and metadata actions. Reading or writing data still needs USE CATALOG and USE SCHEMA.
Covered in Ownership, MANAGE and who can grant
Practise it for real
Grant a group table-creation rights on a schema, confirm the grants, then revoke one of them
1.In a notebook or the SQL query editor, run: GRANT USE CATALOG ON CATALOG main TO
finance-team; then GRANT USE SCHEMA ON SCHEMA main.default TOfinance-team; then GRANT CREATE TABLE ON SCHEMA main.default TOfinance-team;Why: CREATE TABLE is useless without the usage privileges on the parent catalog and schema.
You should see: Each statement completes without error, provided you are a metastore admin, own the objects or hold MANAGE on them.
2.Run SHOW GRANTS ON SCHEMA main.default;
Why: This confirms what the schema grants. The USE CATALOG grant sits on the catalog, so it does not appear here.
You should see: Rows show finance-team with CREATE TABLE and USE SCHEMA on the SCHEMA main.default.
3.Run REVOKE CREATE TABLE ON SCHEMA main.default FROM
finance-team; then run the SHOW GRANTS command again.Why: This shows that revoking one privilege leaves the others in place.
You should see: Only the USE SCHEMA row for finance-team remains on main.default.
4.Run the same REVOKE statement a second time.
Why: REVOKE only guarantees that the privilege is absent. It doesn't need the privilege to exist first.
You should see: The statement succeeds even though the privilege is no longer granted.
Stuck? Get a nudge
If SHOW GRANTS returns only your own grants, you lack the permissions needed to see all grants 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.”
↩︎ Ownership, MANAGE and who can grant“Initially, users have no access to data in a metastore.”
↩︎ Ownership, MANAGE and who can grant“The owner of the catalog or schema that contains the object.”
↩︎ Prediction - 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, even if you don't own those children directly.”
↩︎ Ownership, MANAGE and who can grant“If MANAGE is granted on a container object, the user also gets MANAGE on all child objects.”
↩︎ Ownership, MANAGE and who can grant“Data-access privileges such as SELECT and MODIFY still require USE CATALOG and USE SCHEMA, even for users with MANAGE.”
↩︎ Exam trap 3“Data-access privileges such as SELECT and MODIFY still require USE CATALOG and USE SCHEMA, even for users with MANAGE.”
↩︎ Checkpoint - 3.https://docs.databricks.com/aws/en/data-governance/unity-catalog/manage-privileges/admin-privilegesOfficial docs
“All workspace users receive the USE CATALOG privilege on the workspace catalog.”
↩︎ Account, workspace and metastore admin roles“Databricks recommends nominating a group as the metastore admin.”
↩︎ Account, workspace and metastore admin roles“Account admins can restrict workspace admin privileges using the RestrictWorkspaceAdmins setting.”
↩︎ Account, workspace and metastore admin roles“Workspace admins can create objects but cannot make grants on or change ownership of existing objects they do not own.”
↩︎ Exam trap 1“Workspace admins operate within a single workspace.”
↩︎ Checkpoint - 4.
“can build a dashboard on that data and share it with users who lack access”
↩︎ Workspace asset sharing controls for roles“You must be a workspace administrator to configure workspace asset sharing controls.”
↩︎ Workspace asset sharing controls for roles“The share option is unavailable for assets owned by restricted roles.”
↩︎ Workspace asset sharing controls for roles“A user acting as a listed group cannot share workspace assets owned by that group, even with Can Manage permission on the asset.”
↩︎ Exam trap 2“When acting as their user identity, users and service principals can still share workspace assets they own or can manage”
↩︎ Prediction“Find Restrict sharing for groups.”
↩︎ Checkpoint“System groups, such as all account users, admins, users, and account admins, can't be added to the restrict sharing list.”
↩︎ Checkpoint