Secure Unity Catalog Objects — DP-750 Study Guide

The grant model: who, what, and where

A data analyst has been granted SELECT on the orders table, runs SELECT * FROM sales.finance.orders, and still gets a permission error. The fix reveals the whole model: reading a table in Unity Catalog needs three grants working together, not one. One boundary before the model itself: this page owns who may reach and administer an object, while its sibling Govern Unity Catalog Objects owns describing, recording, retaining, and sharing it. Row filters, column masks, and ABAC appear on both pages. Here they arrive as the fine-grained access-control layers stacked on top of the object grant — peers rather than rungs on a single scale of fineness; Govern goes deep on configuring and choosing among them.

Unity Catalog authorizes access by granting privileges on securable objects to principals. A securable is any object in the three-level namespace — a catalog, a schema, or a table, view, volume, or function inside a schema. A principal is a user, an account group, or a service principal (an identity for jobs and tools rather than a person, covered under machine identity below). The statement reads GRANT <privilege> ON <securable> TO <principal>, and REVOKE takes it away; the everyday privileges are SELECT (read a table or view), MODIFY (write), and CREATE TABLE (Manage privileges in Unity Catalog^[1]). Prefer granting to a group over naming individuals: the principal is not limited to a single user, and group membership is far easier to keep correct as people join and leave.

The three grants the analyst actually needs are SELECT on the table, USE CATALOG on its parent catalog, and USE SCHEMA on its parent schema. USE CATALOG and USE SCHEMA are usage privileges: they grant traversal of the namespace so you can reach an object, but they expose no data by themselves. All three are required, and holding only SELECT is not enough — which is exactly why the query above failed (Unity Catalog permissions model^[2]). This is deliberate: because only catalog and schema owners, or a user with MANAGE, can grant the USE privileges, a table owner cannot hand out access to their table beyond the boundary an administrator has drawn. The figure below stacks the three levels and shows the grant each one needs before a query can read the table.

Privileges inherit downward. A privilege granted on a container object — a catalog or a schema — automatically applies to all of its current and future children. Grant SELECT on a catalog and the grantee can read every table in every schema it contains, present and future, still subject to the USE privileges (Unity Catalog permissions model^[2]). One catalog-level grant can thus replace hundreds of table-level ones, which is why you set broad read access high in the hierarchy and reserve table-level grants for exceptions. Metastore-level grants are the exception that does not inherit: they control operations such as CREATE CATALOG, not access to data.

Reading a table needs USE CATALOG, USE SCHEMA, and SELECT; a grant on a parent object is inherited by its children. Source: Azure Databricks Unity Catalog docs.

Who may grant: ownership and MANAGE

Being able to read an object and being able to control who else reads it are different powers, and Unity Catalog keeps them strictly apart. The rule in one line: only an object's owner, or a user with MANAGE, can grant on it; a plain SELECT holder cannot.

Every securable has exactly one owner, and the owner can be a user, a group, or a service principal (Unity Catalog permissions model^[2]). The owner implicitly holds all privileges on the object, without any privilege being explicitly listed, and is the principal who can GRANT and REVOKE, ALTER, transfer ownership, and DROP it. Ownership moves with a single statement.

Reassign a table's owner to a group

ALTER TABLE mycatalog.myschema.orders OWNER TO `data-eng`;

Transferring to a group is the recommended pattern for shared objects: any group member can then administer the object, while data access still follows the group's own grants (Manage privileges in Unity Catalog^[1]).

When a non-owner must administer an object without becoming the owner, grant the MANAGE privilege. MANAGE lets a principal grant and revoke privileges, drop the object, and even transfer its ownership, and on a container it cascades to child objects — it is close to ownership, not a lesser grant-only role. Two things still keep it short of ownership: a MANAGE holder is not automatically given the object's data privileges such as SELECT — they must grant those to themselves, which is the whole point of keeping the roles distinct — and, unlike an owner, they must hold USE CATALOG and USE SCHEMA on the parents to exercise MANAGE at all (Unity Catalog permissions model^[2]). The line to remember is between a plain SELECT holder — who can read but neither grant nor drop — and a MANAGE holder or owner, who can administer the object.

Where principals come from: account-level identity

Every grant names a principal, so the last question in the permission model is where those principals come from. Users, groups, and service principals in Unity Catalog are account-level identities, provisioned from Microsoft Entra ID — historically through SCIM provisioning, and now, by default for newer accounts, through automatic identity management with Entra ID as the source of record (Manage users, service principals, and groups^[3]). Groups are managed once at the account level, never per workspace, and an account group must be assigned to a workspace through identity federation before it can be granted anything there. A grant therefore always targets an account-level principal federated into the workspace, not a group that lives only inside one workspace.

Column and row security beyond object grants

You have a sales_raw table with an email column and a total column. Analysts should see every row but never the raw email, auditors should see the email, and each regional manager should see only their own region's rows. A SELECT grant cannot express any of that, because a grant is all-or-nothing: it covers the entire table and every column. Trying to grant SELECT on only the non-sensitive columns is not a Unity Catalog capability; it would break SELECT * with a permission error rather than hide values. Fine-grained control is added as a layer on top of the base grant, and Unity Catalog offers four. The four are the dynamic view, the column mask, the row filter, and an ABAC policy, and they differ in where the rule lives. A dynamic view holds the rule in its own SQL, so it protects only the callers routed through that view. A column mask and a row filter bind to the table itself, so the rule travels with it to every query. An ABAC policy sits at the catalog or schema level and applies masks and filters to any table carrying a governed tag. Read the four in that order, and pick by how many tables the rule has to cover.

A dynamic view wraps a base table in a view whose SQL redacts or filters per caller. For column-level redaction, a CASE expression calls is_account_group_member(), returning the real value to members of an authorized group and a placeholder to everyone else.

Column redaction in a dynamic view

CREATE VIEW sales_redacted AS
SELECT
  user_id,
  CASE WHEN is_account_group_member('auditors') THEN email
       ELSE 'REDACTED' END AS email,
  region,
  total
FROM sales_raw;

is_account_group_member() returns TRUE when the current user belongs to a named account-level group; Databricks recommends it over is_member(), which only checks workspace-local groups and should be avoided against Unity Catalog data (Create a dynamic view^[4]). For row-level security, a WHERE predicate built from the caller's identity keeps only the rows that principal may see — is_account_group_member('managers') to lift a limit, or current_user() (equivalently session_user()) to match rows to the person running the query. When entitlements change often, move them into data: join the base table to a mapping table that records which principal or group may see which key values, so you adjust access by editing rows rather than rewriting the view (Row filters and column masks^[5]). For any of this to hold, grant SELECT on the view and do not grant the base table, forcing every principal through the view.

The other two layers attach to the table itself instead of wrapping it in a view. A column mask is a SQL user-defined function (UDF) bound to a column with ALTER TABLE ... ALTER COLUMN ... SET MASK; it takes the column value and returns the original or a masked version (Row filters and column masks^[5]). A row filter is a boolean SQL UDF bound to the table with ALTER TABLE ... SET ROW FILTER; rows for which it returns FALSE are dropped from results. Masks and filters travel with the table, so they hold no matter which query or downstream view reaches it — the advantage over a dynamic view, which only protects data accessed through that one view.

When the same rule must hold across many tables, reach for attribute-based access control (ABAC). An ABAC policy attaches at the catalog or schema level and applies a row filter or column mask automatically to any table or column carrying a governed tag, so newly tagged tables are covered with no per-table configuration (Attribute-based access control in Unity Catalog^[6]). Databricks now recommends ABAC over per-table masks and filters when you need consistent, centrally-authored rules at scale.

The figure shows how one query is routed to different results by the caller's group membership. The choice reduces to reach: one view, one table, or every tagged table under a catalog.

Group membership routes a query through the enforcement layer to either real values and all rows, or redacted, filtered results. Source: Azure Databricks docs.

Secrets: keep credentials out of code

A pipeline that connects to an external database needs a password, and the wrong move is to type it into the notebook. Databricks secrets store that value outside your code and hand it back only at runtime, redacted from output.

A secret scope is a named collection of secrets, and a secret is a key-value pair inside a scope. There are two scope types, and the distinction matters on Azure. An Azure Key Vault-backed scope maps a Databricks scope onto an Azure Key Vault, so the secrets actually live in Key Vault; it is a read-only interface from Databricks, meaning you create, update, and rotate the values in Azure Key Vault, never from Databricks (Secret management^[7]). A Databricks-backed scope stores its secrets in an encrypted store that Databricks manages, and you write to it with the Databricks CLI or SDK. So if a question says the secret must be created and rotated in Azure, the answer is a Key Vault-backed scope, and remember you cannot write to it from Databricks.

Code reads a secret with the secrets utility rather than hardcoding it.

Read a secret in a notebook

password = dbutils.secrets.get(scope='sales-prod', key='db-password')

dbutils.secrets.get(scope, key) returns the value, and Databricks redacts it: any attempt to print the value, in a notebook cell or through a Spark configuration property, is replaced with the literal [REDACTED] so the secret cannot leak into output or logs (Secret management^[7]). Redaction covers literal values only — it cannot stop a deliberate transformation of the secret — so treat it as a safety net, not the access control.

The access control is the scope ACL. Each secret scope carries per-principal permissions at three levels: READ, WRITE, and MANAGE. READ permits reading the secret values and listing the keys in the scope; WRITE adds creating and deleting secrets; MANAGE adds managing the scope's own permissions (Secret management^[7]). A principal needs at least READ on the scope before dbutils.secrets.get returns anything. Because ACLs are set at the scope level, align a scope to a role or application and grant READ to the group that runs that workload.

Machine identity and Azure storage access

Two different non-human identities appear when a pipeline runs, and confusing them is a classic exam trap: the identity the job runs as is not the identity that reaches the storage account.

The job runs as a service principal — an identity created for tools, jobs, and CI/CD rather than a person. A service principal is granted Unity Catalog privileges exactly like a user, so an automated pipeline can authenticate and read data without depending on any individual's account (Service principals^[8]). Configuring a Lakeflow Job to run as a service principal decouples it from its author: the job keeps working when that person leaves or loses access, and it can touch only the data the service principal itself has been granted. Service principals authenticate non-interactively with OAuth machine-to-machine (M2M) tokens — the principal presents its client ID (its application ID) and an OAuth secret and receives a short-lived access token, valid for one hour, that tools use on its behalf (OAuth machine-to-machine authorization^[9]). Databricks recommends OAuth M2M over long-lived personal access tokens for automation.

Reaching the storage account is a separate mechanism. Unity Catalog governs cloud storage through two securables built on an Azure managed identity. First, an Access Connector for Azure Databricks is a first-party Azure resource carrying a system-assigned or user-assigned managed identity; you grant that identity a storage role such as Storage Blob Data Contributor on the ADLS Gen2 account, letting Databricks reach the storage with no keys stored anywhere (Connect to an ADLS Gen2 external location^[10]). Second, you register that managed identity in Unity Catalog as a storage credential, and an external location then references the storage credential to govern reads and writes to a specific container path (an abfss:// URL). The figure traces that storage chain from the managed identity to the container path. Managed identities are recommended over embedding storage account keys or SAS tokens precisely because Azure manages the credential and it never appears in notebook code or cluster configuration.

Now the trap, stated plainly: the managed identity authenticates the workspace to the underlying storage resource, while a service principal is a principal whose Unity Catalog privileges govern who may read the data. They are not interchangeable. A production pipeline usually uses both — it runs as a service principal that has SELECT on a table, and that table's files sit under an external location whose storage credential wraps an Access Connector managed identity.

An Access Connector managed identity, registered as a storage credential, is referenced by an external location to reach ADLS Gen2. Source: Azure Databricks docs.

Exam-pattern recognition

Most questions on securing Unity Catalog objects turn on one distinction. Read the stem for the signal, then pick the answer that honors the stated constraint.

A SELECT grant exists but the query still fails with a permission error: the principal is missing USE CATALOG or USE SCHEMA on the parents. All three grants are required to read a table.
Give one group read access to every table in a catalog, including future ones: grant at the catalog level and let inheritance carry it down, rather than enumerating tables.
A privileged user must not be able to drop or re-grant a table: give them SELECT (or MODIFY), not ownership or MANAGE. A SELECT/MODIFY holder can read or write but cannot DROP or re-grant the table; MANAGE and ownership both can, which is exactly why you withhold them here.
Hide a column from most users but not from auditors: a column mask (reused across tables) or a dynamic view with CASE and is_account_group_member(); never a partial-column grant, which does not exist.
Show each regional manager only their own rows: a row filter, or a dynamic view with a WHERE predicate on the caller's identity; a mapping table when entitlements change often.
Apply the same masking rule automatically across many tables: an ABAC policy driven by a governed tag, not a separate per-table mask on each one.
The secret must be rotated in Azure, not Databricks: an Azure Key Vault-backed secret scope, which is read-only from Databricks.
Keep a scheduled job working after its author leaves: run the Lakeflow Job as a service principal that authenticates with OAuth M2M.
Let Databricks read ADLS Gen2 with no keys in code: an Access Connector managed identity, registered as a storage credential and referenced by an external location.
Managed identity versus service principal: the managed identity authenticates the storage resource; the service principal's Unity Catalog privileges govern data access.

Access-control granularity: the object grant and the four fine-grained layers

Mechanism	What it scopes	How it is enforced	Choose when
Object GRANT (SELECT / MODIFY)	The whole table or view, every column	USE CATALOG + USE SCHEMA + the privilege on the securable	Whole-object access is the right granularity
Dynamic view	Columns and/or rows, per caller	CASE / WHERE calling is_account_group_member() or current_user()	One-off redaction; grant the view, withhold the base table
Column mask	One column's values, via a reusable UDF	A SQL UDF bound with ALTER TABLE ... SET MASK	The same masking logic must apply across many tables
Row filter	Which rows the query returns	A boolean SQL UDF bound with ALTER TABLE ... SET ROW FILTER	Row-level filtering that travels with the table itself
ABAC policy	Columns or rows matched by a governed tag	A policy attached at catalog or schema level, applied by tag	Consistent rules across many tables, applied automatically

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

GRANT assigns a privilege on a securable to a user, group, or service principal

Access to a Unity Catalog securable is granted with GRANT ON TO , where the principal can be a user, an account group, or a service principal, and REVOKE removes it; common privileges include SELECT, MODIFY, and CREATE.

Trap A principal is not limited to individual users; groups and service principals are equally valid grant targets and groups are preferred for manageability.

6 questions test this

Reading a table also requires USE CATALOG and USE SCHEMA on its parents

To query a table a principal needs SELECT on the table plus USE CATALOG on its catalog and USE SCHEMA on its schema; the USE privileges grant traversal of the three-level namespace but do not by themselves expose any data.

Trap SELECT on the table alone is insufficient; without USE CATALOG and USE SCHEMA on the parents the query fails with a permission error.

11 questions test this

A privilege granted on a catalog or schema is inherited by its child objects

Unity Catalog privileges are inherited down the object hierarchy, so a privilege granted on a catalog applies to all of its current and future schemas and tables, and a grant on a schema applies to its tables, views, and volumes.

5 questions test this

Object owners and MANAGE control who can grant on a securable

In Unity Catalog the owner of a securable (a user, group, or service principal) implicitly holds all privileges on it and is the principal who can GRANT/REVOKE, ALTER, and DROP it; granting the MANAGE privilege lets a non-owner administer the object, including granting and revoking privileges and even dropping or transferring it, without being the owner, and ownership can be reassigned with ALTER OWNER TO.

Trap Holding SELECT is not enough to administer an object - only the owner or a MANAGE holder can grant, drop, or transfer it, and MANAGE differs from ownership only in that it is not automatically given the object's data privileges (it must self-grant SELECT).

UC principals are account-level identities federated from Microsoft Entra ID

Users, groups, and service principals in Unity Catalog are account-level identities, typically provisioned from Microsoft Entra ID via SCIM; account groups must be assigned to a workspace through identity federation before they can be granted privileges there.

Trap Groups are managed at the account level, not per-workspace - grants target account-level principals federated to the workspace, not a workspace-local group.

Object-level grants cover every column; column limits need a view, mask, or ABAC

A SELECT grant applies to the entire table securable and cannot be scoped to individual columns, so column-level access control is achieved by layering a view that exposes only permitted columns, a column mask, or an ABAC policy on top of the base grant.

Trap Granting SELECT on only the non-sensitive columns is not a Unity Catalog capability; it would break SELECT * with a permission error rather than hide values.

15 questions test this

A dynamic view redacts columns per group with is_account_group_member in CASE

A dynamic view wraps a base table and uses CASE expressions calling is_account_group_member() so that members of an authorized group receive the real column value while all other callers receive NULL or a redacted literal.

13 questions test this

Grant the secure view and withhold the base table so users query only the view

For view-based access control you grant SELECT on the dynamic or restricted view and do not grant access to the underlying base table, forcing every principal through the view where the column and row rules are enforced.

A dynamic view enforces row-level security with a caller-identity WHERE predicate

Row-level security through a dynamic view adds a WHERE predicate built from current_user() or is_account_group_member(), returning only the rows whose values match the querying principal, such as their own region or business unit.

16 questions test this

Data-driven row-level security joins to an entitlement mapping table

A scalable row-level-security pattern joins the base table to a mapping table that records which principal or group may see which key values, so entitlement changes are made by editing data rather than by rewriting the view definition.

An Azure Key Vault-backed secret scope exposes Key Vault secrets read-only

An Azure Key Vault-backed secret scope maps a Databricks secret scope onto an Azure Key Vault so notebooks can read its secrets; it is a read-only interface, meaning the secret values are created, updated, and rotated in Azure rather than in Databricks.

Trap A Key Vault-backed scope cannot be written from Databricks; secrets must be added and rotated in the Azure Key Vault itself.

9 questions test this

dbutils.secrets.get reads a secret and Databricks redacts it from output

Code retrieves a secret with dbutils.secrets.get(scope, key) instead of hardcoding credentials, and Databricks automatically replaces any printed secret value with [REDACTED] so it cannot leak into notebook cell output or logs.

13 questions test this

Secret access is governed by READ, WRITE, and MANAGE scope ACLs

Secret scope access control assigns per-scope ACLs at the READ, WRITE, and MANAGE levels, and a principal needs at least READ on the scope, which permits reading secret values and listing keys, before dbutils.secrets.get will succeed.

A service principal is a non-human identity for automated data workloads

A service principal is an identity created for tools, jobs, and CI/CD rather than a person, and it is granted Unity Catalog privileges like any principal so automated pipelines can authenticate and access data without depending on an individual user's account.

16 questions test this

Running a job as a service principal decouples it from a user account

Configuring a Lakeflow Job or pipeline to run as a service principal keeps it working when the original author leaves or loses access, and confines the job's data access to exactly the Unity Catalog privileges granted to that service principal.

12 questions test this

Service principals authenticate with OAuth machine-to-machine tokens

A service principal authenticates non-interactively using OAuth machine-to-machine (M2M) tokens minted from its client ID and secret, which are the recommended automation credential in place of long-lived personal access tokens.

An Access Connector managed identity authenticates the workspace to Azure storage

Resource access to ADLS Gen2 uses an Access Connector for Azure Databricks, a first-party Azure resource whose system- or user-assigned managed identity is granted a storage role such as Storage Blob Data Contributor, letting Databricks reach the storage account with no stored keys.

Trap A managed identity authenticates the underlying storage resource; a service principal instead represents a principal whose Unity Catalog privileges govern data access, not the storage connection.

14 questions test this

A storage credential wraps the managed identity for an external location to use

In Unity Catalog the Access Connector's managed identity is registered as a storage credential, and an external location then references that credential to govern reads and writes to a specific ADLS Gen2 container path.

9 questions test this

Managed identities are preferred over storage account keys or SAS tokens

Authenticating storage access through an Access Connector managed identity is recommended over embedding storage account keys or SAS tokens, because the credential is managed by Azure and is never exposed in notebook code or cluster configuration.

A securable has exactly one owner, while MANAGE can be granted to many principals

Unity Catalog allows only one owning principal per securable — a user, service principal, or group — and ALTER ... OWNER TO replaces that owner rather than adding one. MANAGE is an ordinary privilege that can be granted to any number of principals, and it confers the ability to grant and revoke privileges on the object, transfer its ownership, rename it and drop it without being the owner. Making a group the owner, or granting MANAGE to a group, is therefore how several people share administration of one object.

Trap Believing you can add co-owners to a table or catalog so that several administrators own it simultaneously, instead of granting MANAGE or owning it through a group.

2 questions test this

ALL PRIVILEGES deliberately excludes MANAGE, READ METADATA, EXTERNAL USE SCHEMA and EXTERNAL USE LOCATION

ALL PRIVILEGES implies every applicable privilege for the object type without granting each one explicitly, but it never includes MANAGE, READ METADATA, EXTERNAL USE SCHEMA or EXTERNAL USE LOCATION — the exclusions exist to prevent accidental privilege escalation and data exfiltration. Consequently a principal with ALL PRIVILEGES on a table can read and write it yet cannot grant anyone else access, and revoking ALL PRIVILEGES removes the implied privileges but leaves those four untouched if they were granted separately. Because ALL PRIVILEGES is evaluated at permission-check time, it automatically picks up newly released privileges for that securable type.

Trap Reading ALL PRIVILEGES as literally every privilege, so that the grantee can also administer grants, transfer ownership, or hand a path to an external engine.

6 questions test this

MANAGE has reduced usage requirements: MANAGE on a catalog needs no USE CATALOG, but data access still does

To exercise MANAGE you need usage privileges only on the container levels strictly ABOVE where MANAGE is held, never at that level itself: MANAGE on a catalog requires no USE CATALOG or USE SCHEMA at all, MANAGE on a schema requires USE CATALOG on the parent catalog, and MANAGE on a table requires USE CATALOG plus USE SCHEMA. MANAGE granted on a container is also inherited by every child object, so MANAGE on a catalog carries MANAGE on its schemas and tables. The reduction applies only to the metadata capabilities of MANAGE — data privileges such as SELECT and MODIFY that a MANAGE holder grants to itself still require USE CATALOG and USE SCHEMA.

Trap Assuming a principal with MANAGE on a catalog must also be granted USE CATALOG before they can administer grants inside it, by analogy with the SELECT + USE CATALOG + USE SCHEMA rule.

1 question tests this

You have an Azure Databricks workspace that is enabled for Unity Catalog. A platform support group has been granted the MANAGE privilege on a catalog named catalog1 and holds no other privilege anywhe

READ METADATA, not BROWSE, is the read-only delegation of MANAGE that exposes grants, filters, masks and policies

READ METADATA is the child privilege of the composite MANAGE privilege: it gives read-only visibility into the same owner-visible metadata — permissions, row filters, column masks, ABAC policies, and credential names and IDs — without any ability to modify the object or read its data, which is what an auditor or SRE needs. BROWSE is a different, discovery-oriented privilege: it lets a principal see that an object exists and view its name, description and tags without USE CATALOG or USE SCHEMA, and it deliberately does not expose that security-sensitive metadata. The two are granted and revoked independently of MANAGE, so revoking MANAGE does not revoke an explicitly granted READ METADATA.

Trap Granting BROWSE to a security auditor who must review who has access and which masks are applied, on the belief that BROWSE is the read-only view of an object's governance metadata.

1 question tests this

You have an Azure Databricks workspace that is enabled for Unity Catalog and contains a catalog named regulated. An external security auditor must review, for every table in regulated, which principal

Creating an external location requires CREATE EXTERNAL LOCATION on both the metastore and the storage credential it references

CREATE EXTERNAL LOCATION is one of the few privileges that must be held in two places at once: on the Unity Catalog metastore, and on the specific storage credential named in the WITH (STORAGE CREDENTIAL ...) clause. Holding it on the metastore alone is not sufficient, which is what stops any metastore-level creator from wrapping someone else's credential in a new path. Metastore admins and workspace admins have this privilege by default, and creating the storage credential itself is separately gated by CREATE STORAGE CREDENTIAL on the metastore.

Trap Assuming that because an external location is a metastore-level securable, a metastore-level CREATE EXTERNAL LOCATION grant alone lets a principal register a path over any existing storage credential.

CREATE EXTERNAL VOLUME applies only to external locations, so an external volume cannot be created from a bare storage credential

The privileges that apply to a storage credential are ALL PRIVILEGES, CREATE EXTERNAL LOCATION, CREATE EXTERNAL TABLE, MANAGE, READ FILES, READ METADATA and WRITE FILES — CREATE EXTERNAL VOLUME is not among them, because it is defined only for external locations. CREATE EXTERNAL TABLE exists on both securables, and Databricks recommends granting it on the external location rather than the credential precisely because the external location is scoped to a path, giving control over where in the cloud tenant users may create tables. So registering an external volume always starts by creating an external location over the target path.

Trap Believing CREATE EXTERNAL VOLUME can be granted on a storage credential the same way CREATE EXTERNAL TABLE can, since both securables authorize access to cloud storage.

EXTERNAL USE LOCATION is excluded from ALL PRIVILEGES and is not held by external location owners by default

EXTERNAL USE LOCATION is the privilege that lets a principal obtain a temporary credential for an external location so an external processing engine can read the path through the Unity Catalog open APIs. To avoid accidental data exfiltration it is excluded from ALL PRIVILEGES, and external location owners do not have it by default; the documentation states that only users with MANAGE on the external location can grant it. The equivalent carve-out exists one level up in the data hierarchy: schema owners do not hold EXTERNAL USE SCHEMA by default either, and only the catalog owner can grant it.

Trap Assuming that granting ALL PRIVILEGES on an external location, or simply owning it, is enough to let an outside engine obtain temporary credentials for that path.

By default a storage credential or external location is usable from every workspace attached to the metastore until it is workspace-bound

Storage credentials and external locations are metastore-level securables, and by default any privileged user can use them from any workspace attached to that metastore. Restricting them to a subset of workspaces is a separate, explicit step — assigning the object to specific workspaces on its Workspaces tab, also called workspace binding or external location isolation. A second, orthogonal control is the Limit to read-only use option, which can be set on the storage credential (making every external location that uses it read-only) or on an individual external location.

Trap Assuming an external location or storage credential is automatically scoped to the workspace in which it was created, so a principal in another attached workspace cannot use it.

A team that only needs to read or write files under a governed path is granted on the volume, which scopes them to that volume's path instead of the whole storage prefix

READ VOLUME and WRITE VOLUME on a Unity Catalog volume, together with USE CATALOG and USE SCHEMA on its parents, give notebooks, jobs and libraries file access through the volume's /Volumes path, and that is the least-privilege securable for a pure file-access requirement over ADLS Gen2 data. Granting on the external location instead exposes every path beneath it, including data belonging to other teams, and is justified only when the principal must also define new objects on that path.

Trap Reaching for a grant on the external location because the data 'is just files in the storage account', when a grant on the volume already covers reading and writing those files at a much narrower scope.

2 questions test this

Creating external tables, external volumes or managed storage over a cloud path requires a grant on the external location covering that path, which no volume grant can confer

The external location is the securable that governs the storage path itself, so the privileges that let a principal read the raw path or define new objects over it — such as READ FILES, WRITE FILES, CREATE EXTERNAL TABLE and CREATE EXTERNAL VOLUME — are granted on the external location. A volume grant never carries this, because a volume exposes only the files beneath its own path to consumers of that volume. Match the securable to the verb in the requirement: consuming files points at the volume, defining objects on the path points at the external location.

Trap Assuming that because a team can already read the files through a volume they can point an external table at the same path, when the create-time authorization check is made against the external location.

3 questions test this

Granting a principal permissions directly on the ADLS Gen2 account or container bypasses Unity Catalog governance entirely, leaving that access ungoverned and unaudited by the metastore

Unity Catalog privileges, lineage and audit apply only to access that arrives through its securables, so a principal holding storage-level roles on the account, or using a path-based credential, reads the same bytes with none of that oversight and cannot be cut off by revoking a grant. The governed answer is to register the path as an external location or a volume backed by a storage credential and grant on that securable, reserving direct storage permissions for the managed identity Unity Catalog itself authenticates with.

Trap Solving a file-access request by assigning the team a data role on the storage container, on the belief that Unity Catalog will still govern and audit the access because the same path is registered as an external location.

3 questions test this

Compute that cannot enforce a row filter, column mask or dynamic view fails the query rather than returning unprotected rows

Fine-grained access control is fail-closed, so a workload running on compute that does not support it errors out instead of quietly serving unfiltered or unmasked data. That makes the symptom diagnostic: a query that fails only against protected tables while succeeding against unprotected ones points at the compute's access mode, whereas users genuinely seeing values they should not points at the grant, the group membership or the policy definition. Fix the first by moving the workload, never by rewriting a control that is working as designed.

Trap Believing an unsupported cluster silently ignores the filter and leaks the underlying values, so the remedy is to re-apply the mask or re-grant privileges rather than to change the compute.

5 questions test this

Dedicated access mode enforces filters and masks only through serverless data filtering, which requires both a workspace enabled for serverless and support for the specific operation

On dedicated compute the protected read is delegated to a serverless filtering layer, so a supported runtime is only half the prerequisite — the workspace must also be enabled for serverless compute, and upgrading the runtime alone will not make a filtered or masked table readable there. Support is granted per operation as well: reads becoming available on dedicated compute does not mean writes, merges or streaming operations against the same protected table are allowed. A workload that must write to a filtered or masked table therefore belongs on compute that enforces the control natively.

Trap Concluding that a newer runtime is all a dedicated cluster needs, or that because reads of the masked table already succeed there the job's writes to it will succeed too.

5 questions test this

Legacy no-isolation compute cannot reach Unity Catalog data at all, so the remedy is moving the workload to a governed access mode rather than granting more privileges

No-isolation clusters sit outside Unity Catalog's identity model, so no grant, runtime upgrade or policy change lets them query a Unity Catalog table, protected or not. When a job on such a cluster fails against the metastore, the fix is to re-run it on standard access mode, serverless compute or a SQL warehouse. Standard access mode is the default landing place when several users share the compute and fine-grained controls must be enforced natively for each caller's identity.

Trap Reading the failure as a missing privilege and adding SELECT plus USE CATALOG and USE SCHEMA, or bumping the runtime version, expecting the no-isolation cluster to then reach the table.

3 questions test this

Also tested in

DEA-C01 AWS Certified Data Engineer - Associate

The grant model: who, what, and where

Who may grant: ownership and MANAGE

Where principals come from: account-level identity

Column and row security beyond object grants

Secrets: keep credentials out of code

Machine identity and Azure storage access

Exam-pattern recognition

Access-control granularity: the object grant and the four fine-grained layers

Decision tree

Cheat sheet

Also tested in

References