What you will be able to do
- Explain why production objects should be owned by groups and not by the person who created them
- Tell object ownership apart from the MANAGE privilege, and decide when to delegate each one
- Use catalog and schema usage privileges as guardrails against over-sharing by table owners
- Pick managed storage and table types that keep data inside Unity Catalog governance
Key concept
Object ownership — Every Unity Catalog object has one owner. The owner holds every privilege on it and decides who else gets access. Securing data mostly comes down to deciding who that owner should be and how far their grants can reach.
1.Who should own a table
Ownership is the most powerful thing you can hold on a Unity Catalog object. The owner has every privilege on it, can grant privileges to others, and can transfer ownership itself. Ownership also starts out personal: whoever creates an object becomes its first owner. If nobody changes that, a production table stays tied to one person's account. That person's access, availability and mistakes then decide who can reach the data.
Databricks' first rule follows from this: "Assign object ownership to groups, especially if objects are used in production." It also says production catalogs and schemas should always be owned by groups, not individual users. With group ownership, a team holds administrative control together, and changes in membership are handled in the group, not by reassigning objects one at a time.
If you want to share administrative power without giving away ownership, use the MANAGE privilege. Owners can grant MANAGE to delegate ownership abilities on an object to other principals. MANAGE lets someone grant and revoke privileges on an object, transfer its ownership, and delete it, all without being the owner. Note that ALL PRIVILEGES is not a substitute: it includes all privileges except MANAGE, EXTERNAL USE LOCATION, and EXTERNAL USE SCHEMA. Ownership also reaches downward: catalog and schema owners can transfer ownership of any object in the catalog or schema. The guidance is to put either ownership or MANAGE with "a group that is responsible for administration of grants on the object", and to be sparing with both.
Checkpoint 1 of 6· Check yourself
A data engineering team wants three senior engineers to be able to grant access to a production table and drop it if needed, while the table's ownership stays with the platform group. What fits best?
MANAGE delegates the owner's abilities (granting, transferring ownership, dropping) without changing the owner. ALL PRIVILEGES does not include MANAGE, and metastore admin is far broader than the task needs.
“Owners can grant the MANAGE privilege to delegate ownership abilities on an object to other principals.”Source: docs.databricks.com
Checkpoint 2 of 6· Exam question
A data analyst created a production sales table under their personal user account. Ahead of a team reorganization, the data platform team wants the table's ownership tied to the analytics group rather than the original creator, so that future privilege grants and audits survive staff turnover. Which SQL statement correctly transfers ownership?
Correct answer: B — Run `ALTER TABLE sales.orders OWNER TO `analytics_team`;` to reassign the table's owner to the group, which then holds every ownership privilege on the object.
- A. Granting every privilege gives the group broad access but leaves the original analyst listed as owner, so ownership-based behaviors like default grant authority and audit attribution still point to the departing individual.
- B. `ALTER TABLE ... OWNER TO` is the Unity Catalog statement that reassigns an object's owner. Once the group is the owner, it holds full ownership privileges, including the ability to grant access and manage the table going forward.
- C. Unity Catalog does not read table properties to determine ownership; `TBLPROPERTIES` is metadata storage, not the ownership mechanism, so this statement would not change who Unity Catalog treats as the owner.
- D. `REASSIGN OWNED BY` is PostgreSQL syntax, not a Unity Catalog SQL statement, so running it against a Databricks SQL warehouse or cluster would fail rather than transfer ownership.
Sources1
2.Limiting what owners and editors can share
Group ownership settles who controls a table. The next risk is that a table owner shares it too widely. Unity Catalog guards against this at the container level. Reading a table needs USE CATALOG on its catalog and USE SCHEMA on its schema, as well as SELECT on the table. Only catalog and schema owners, or users with MANAGE, can grant those usage privileges. So a table owner who grants SELECT to an outsider has not opened the table to them. In Databricks' words, this "prevents table owners from granting access outside approved boundaries."
This gives a simple team layout: create a schema per team and grant USE SCHEMA and CREATE TABLE only to that team, plus USE CATALOG on the parent catalog. Grant usage privileges only to users who should be able to see or query the data inside.
No. Reading a table requires all three: USE CATALOG on the catalog, USE SCHEMA on the schema, and SELECT on the table.
Two more practices close the remaining gaps. First, views: by default only a view's owner can edit its definition, because an editor could otherwise rewrite the view to read data they are not allowed to see. To let several people edit a view safely, transfer its ownership to a group and grant that group access to the source tables. Every member can then edit it, but only within what the group can see. Second, writes: "Reserve direct MODIFY access to production tables for service principals." People read production data, and automated pipelines write it.
Checkpoint 3 of 6· Check yourself
Why does Unity Catalog, by default, let only the owner of a view edit its definition?
The restriction is there to stop privilege escalation. A view runs with access to its source tables, so whoever edits it controls what it exposes.
“This prevents privilege escalation where an editor could modify the view to access unauthorized data.”Source: docs.databricks.com
Checkpoint 4 of 6· Exam question
A data analyst who owns a Unity Catalog view tries to transfer its ownership directly to an external contractor's individual user account, someone who is not a member of any group the analyst belongs to. The `ALTER VIEW ... OWNER TO` statement fails with a permissions error. What explains this restriction?
Correct answer: A — Only metastore admins can move view ownership to any arbitrary principal; other owners may transfer ownership only to themselves or a group they belong to, which blocks privilege escalation.
- A. Unity Catalog restricts who can hand off ownership of views, functions, and models to arbitrary users specifically to prevent an owner from escalating a stranger's access; only a metastore admin can complete that kind of arbitrary transfer.
- B. View ownership can be transferred with `ALTER VIEW ... OWNER TO`, so claiming it is permanently fixed is incorrect, and dropping and recreating the view is not the actual mechanism or requirement here.
- C. The failure is not about a missing catalog-level privilege on the contractor's account; it is about who the transferring principal is allowed to name as the new owner, which this option does not address.
- D. Ownership transfer for a view does not depend on holding `MODIFY` on its underlying tables; the restriction that actually applies here is about the identity of the recipient, not privileges on source data.
3.Keeping storage inside Unity Catalog's control
Privileges only protect data if every access goes through Unity Catalog. Managed tables and volumes live in a managed storage location, which can be set at the metastore, catalog or schema level. Data lands in the lowest location available in that hierarchy. Catalogs are the main unit of data isolation, so Databricks says to give preference to catalog-level storage. Metastore-level storage was needed in early Unity Catalog environments but no longer is. If you do create one, use a dedicated bucket.
The key storage rule is about bypass: "Do not use a bucket that can be accessed from outside of Unity Catalog." If an external service or principal reads the files directly, access control and auditability on managed tables and volumes are compromised. On the same grounds, do not reuse a bucket that is or was used for your DBFS root file system.
Checkpoint 5 of 6· Check yourself
A team suggests pointing a catalog's managed storage at an existing bucket that an external reporting service already reads directly. What is the security problem?
Any principal that reads managed storage directly is outside Unity Catalog's grants and audit trail. That is why the bucket must not be reachable from outside Unity Catalog.
“access control and auditability on managed tables and volumes are compromised”Source: docs.databricks.com
Sources1
4.Choosing managed tables for governance
Unity Catalog governs every table you register in it. With a managed table, it also controls where the files are stored and how long they exist: dropping the table permanently deletes the files after an 8-day retention period. With an external table, you choose the location, and the files stay in place when the table is dropped. Databricks recommends managed tables for most use cases and for all new tables, because they let you use Unity Catalog's governance capabilities in full.
External tables still have valid uses, for example during a Hive metastore upgrade or for non-Delta or non-Iceberg formats. The security concern is letting outside readers and writers reach their files directly, because doing so "bypasses Unity Catalog access control, auditing, and lineage." If external access cannot be avoided, limit it to reads and send all writes through Databricks and Unity Catalog. Databricks also recommends one external location per schema.
| Term | Meaning | Applies to |
|---|---|---|
| "Managed by Unity Catalog" | Unity Catalog governs access, auditing, and lineage for the object | All registered objects, including external tables and volumes |
| Managed table or managed volume | Unity Catalog also controls the storage location and data lifecycle in your cloud account | Tables and volumes only |
| MANAGE privilege | Lets a user assign or revoke privileges on, transfer ownership of, and delete an object without being the owner | All Unity Catalog securable objects |
Checkpoint 6 of 6· Match them up
Match each term to what it actually means
Tap a term, then the definition that fits it.
The same word covers governance (all objects), storage lifecycle (managed tables and volumes) and a delegable privilege. Exam questions often depend on keeping these three apart.
“When people say that an object is managed by Unity Catalog, they typically mean that Unity Catalog governs access to it.”Source: docs.databricks.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.It's fine for the engineer who created a production table to stay its owner, since they understand it best.Why is that wrong?
The creator becomes the first owner only by default. Best practice is to reassign ownership of production objects to a group so control doesn't depend on one person.
Covered in Who should own a table
2.A table owner can give anyone access to their table just by granting SELECT.Why is that wrong?
Readers also need USE CATALOG and USE SCHEMA on the parents. Only catalog and schema owners or MANAGE holders can grant those, so the table owner can't share past those boundaries.
Covered in Limiting what owners and editors can share
3.An external table is not governed by Unity Catalog, while a managed table is.Why is that wrong?
Unity Catalog governs access to every registered object, external tables included. "Managed" only refers to who controls the file location and lifecycle.
Covered in Choosing managed tables for governance
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Assign object ownership to groups, especially if objects are used in production.”
↩︎ Who should own a table“Always assign ownership of production catalogs and schemas to groups, not individual users.”
↩︎ Who should own a table“Catalog and schema owners can transfer ownership of any object in the catalog or schema.”
↩︎ Who should own a table“configure ownership or grant the MANAGE privilege on all objects to a group that is responsible for administration of grants on the object”
↩︎ Who should own a table“Be sparing in your assignment of ownership and the MANAGE privilege.”
↩︎ Who should own a table“which includes all privileges except MANAGE, EXTERNAL USE LOCATION, and EXTERNAL USE SCHEMA”
↩︎ Who should own a table“It is typical to create a schema per team and grant USE SCHEMA and CREATE TABLE only to that team”
↩︎ Limiting what owners and editors can share“Reserve direct MODIFY access to production tables for service principals.”
↩︎ Limiting what owners and editors can share“Do not use a bucket that can be accessed from outside of Unity Catalog.”
↩︎ Keeping storage inside Unity Catalog's control“Give preference to catalog-level storage as your primary unit of data isolation.”
↩︎ Keeping storage inside Unity Catalog's control“Do not reuse a bucket that is or was used for your DBFS root file system.”
↩︎ Keeping storage inside Unity Catalog's control“Doing so bypasses Unity Catalog access control, auditing, and lineage.”
↩︎ Choosing managed tables for governance“If you must allow external access to external tables, limit it to reads, with all writes happening through Databricks and Unity Catalog.”
↩︎ Choosing managed tables for governance“An object's owner has all privileges on the object, such as SELECT and MODIFY on a table,”
↩︎ Key concept“Assign object ownership to groups, especially if objects are used in production.”
↩︎ Exam trap 1“The creator of any object is its first owner. Creators should reassign ownership to appropriate groups.”
↩︎ Prediction“Owners can grant the MANAGE privilege to delegate ownership abilities on an object to other principals.”
↩︎ Checkpoint“This prevents privilege escalation where an editor could modify the view to access unauthorized data.”
↩︎ Checkpoint“access control and auditability on managed tables and volumes are compromised”
↩︎ Checkpoint - 2.https://docs.databricks.com/aws/en/data-governance/unity-catalog/access-control/permissions-conceptsOfficial docs
“this prevents table owners from granting access outside approved boundaries”
↩︎ Limiting what owners and editors can share“All three are required.”
↩︎ Limiting what owners and editors can share“this prevents table owners from granting access outside approved boundaries”
↩︎ Exam trap 2 - 3.https://docs.databricks.com/aws/en/data-governance/unity-catalog/managed-versus-externalOfficial docs
“Data files are permanently deleted after an 8-day retention period”
↩︎ Choosing managed tables for governance“When people say that an object is managed by Unity Catalog, they typically mean that Unity Catalog governs access to it.”
↩︎ Exam trap 3“When people say that an object is managed by Unity Catalog, they typically mean that Unity Catalog governs access to it.”
↩︎ Checkpoint