Unity Catalog explained: grants and storage

Unity Catalog is the governance layer built into Azure Databricks: it controls who can use which tables, files and AI assets, records lineage and audit logs, and tracks every asset under one three-level name, catalog.schema.object. The decision rule for exams: privileges are granted at a level and inherited downward, and reading a table needs three things (USE CATALOG, USE SCHEMA, SELECT), while files are governed through volumes, not through raw storage paths. Most Unity Catalog questions are a variation on one of those two sentences.

The address: metastore, catalog, schema, object

Everything starts at the metastore, the top-level container for metadata and permissions. Microsoft’s best-practice guidance states that you can have only one metastore per region and that all workspaces in that region share it (Unity Catalog best practices). Below it sit three levels:

A table is therefore always addressed as sales_prod.orders.invoices. Some objects are not inside a catalog at all: storage credentials, external locations, connections and shares sit directly under the metastore. Every object is a securable object, which means you can grant permissions on it to users, groups or service principals. Unity Catalog is enabled by default for workspaces created after 9 November 2023, according to the same documentation.

Granting access: one worked example

An analyst group finance-analysts must read sales_prod.orders.invoices and nothing else in the catalog. The grants:

GRANT USE CATALOG ON CATALOG sales_prod TO `finance-analysts`;
GRANT USE SCHEMA  ON SCHEMA  sales_prod.orders TO `finance-analysts`;
GRANT SELECT      ON TABLE   sales_prod.orders.invoices TO `finance-analysts`;

All three are required. The documentation says USE CATALOG and USE SCHEMA alone do not give SELECT on the objects inside, but they are a prerequisite for it; a user holding only SELECT on the table still fails. That is the single most tested fact in this topic.

Now the inheritance shortcut. Granting SELECT on the schema gives SELECT on every current and future table and view in it, and granting it on the catalog reaches every schema below. The reference page for privileges spells this out per privilege (for example MODIFY and READ VOLUME). Inheritance only flows downward and cannot be switched off for a single child, so broad grants are convenient and risky at the same time. The least-privilege answer on an exam is usually the lowest level that satisfies the requirement, granted to a group rather than to individuals; the best-practice page recommends groups for grants and for object ownership, and service principals for running production jobs (see managed identities versus service principals).

Three more privilege facts that show up:

• BROWSE lets a user see metadata (names, lineage, search results) without access to the data, so people can discover a table and request access.
• ALL PRIVILEGES covers the privileges of the object and its children but not MANAGE, READ METADATA, EXTERNAL USE SCHEMA or EXTERNAL USE LOCATION; the owner of an object holds all privileges on it and can grant them.
• Only metastore admins, owners and holders of MANAGE can grant privileges on an object. Owners of a parent catalog or schema can also grant on everything inside.

Managed or external: where the files live

Tables and volumes come in two kinds. With a managed table, Unity Catalog governs access and also manages the data files, including their lifecycle; managed tables are always Delta or Apache Iceberg. With an external table, Unity Catalog governs access only, while the files stay where you put them and are managed in your cloud. Databricks recommends managed tables for new tables; external tables fit migrations from Hive metastore, non-Delta formats such as Parquet or ORC, or cases where outside tools must read and write the same files. Dropping an external table leaves its data in storage, which is a classic question. For the table format itself see Delta Lake explained.

Volumes versus external locations

These two are confused constantly.

On Azure, an external location needs a storage credential, which is an Azure managed identity reached through an access connector for Azure Databricks, with a role such as Storage Blob Data Contributor on the storage account. Databricks guidance says to give users volumes or tables rather than READ FILES on the location, and never to create an external table or volume at the root of an external location, because that blocks further objects at that location. Files in a volume cannot be registered as tables; volumes are for path-based access only.

Which exams test this

How exam questions are built around Unity Catalog

Stems describe a person who “can see the schema but gets a permission error” or “needs to read files in cloud storage”. Look for these decisions:

• Missing prerequisite. Table SELECT granted, still denied: the missing piece is USE CATALOG or USE SCHEMA.
• Scope. “All current and future tables in a schema” points to a schema-level grant. “Only this one table” points to a table-level grant.
• Files or tables? “Non-tabular, images, PDFs, libraries” means a volume. “Query in place without copying” means an external table. “Copy into Delta” means ingest into a managed table.
• Least privilege. Reject ALL PRIVILEGES, ownership transfer and metastore admin when a single privilege works. Reject READ FILES on an external location when a volume would do.
• Who runs the job. A service principal with only the grants the pipeline needs, not a person.

Row filters and column masks are part of the same access-control area; see row-level security. Where governed tables fit in a bronze-silver-gold design is covered in medallion architecture.

Practice questions

Go deeper

• What is Unity Catalog? (Microsoft Learn)
• Unity Catalog best practices (Microsoft Learn)
• Unity Catalog volumes (Microsoft Learn)
• Connect to an ADLS Gen2 external location (Microsoft Learn)
• Related on this site: Delta Lake explained, lakehouse versus warehouse, how to study for certification exams