Secure and govern Unity Catalog objects

Every requirement in this domain acts on the same thing, a securable object in Unity Catalog, a catalog, a schema, or a table, view, or volume inside one, and it asks one of two questions about that object. Securing it decides who may reach it and who may administer it: you authorize access with GRANT <privilege> ON <securable> TO <principal>, remove it with REVOKE, and reading a table takes three grants at once, SELECT on the table plus USE CATALOG and USE SCHEMA on its parents. Governing it decides how the object is described, what a permitted reader sees inside it, and how access is recorded, retained, and shared. Unity Catalog does both in place, on the live object, so a decision takes effect on the next query against it with nothing copied. The trap this model dodges is treating reading and administering as one power: a plain SELECT holder can read but cannot grant, drop, or transfer, whereas an owner or a MANAGE holder can, and MANAGE even lets a non-owner drop, rename, and transfer ownership, so it sits close to ownership rather than being a grant-only role.

Read this page as a map, then follow the two subtopics in order. Secure Unity Catalog Objects builds the access chain, grants and downward inheritance where a grant on a catalog or schema reaches its current and future children, ownership versus MANAGE, and the finer access-control layers stacked on top of the object grant, a dynamic view, a column mask, a row filter, or an ABAC (attribute-based access control) policy. It then covers the non-human side: a service principal a Lakeflow Job runs as authenticating with OAuth machine-to-machine (M2M) tokens, an Access Connector managed identity that reaches ADLS Gen2 storage without stored keys, and Key Vault-backed secret scopes for credentials code genuinely needs. Govern Unity Catalog Objects then works the object's lifecycle: describe it with comments and governed tags, protect what a reader sees inside it with row filters and column masks scaled by ABAC, record it through automatic column-level lineage and the system.access.audit table, retain it under the delta.logRetentionDuration and delta.deletedFileRetentionDuration windows that VACUUM can close for good, and share it with OpenSharing (previously Delta Sharing). One overlap is worth pinning down now so you do not hunt for it twice: row filters, column masks, and ABAC appear on both pages. Secure introduces them as the finest rungs of one access-control ladder, object grant, then view, then mask, then filter, then ABAC, while Govern goes deep on configuring and choosing among them. Same controls, two lenses.

Across both subtopics the exam rewards the same instinct: choose the control that grants the least and travels with the object. In practice that means granting to a group rather than an individual and high in the hierarchy so inheritance carries it down, masking a sensitive column rather than revoking access so the query still runs, and reaching for a governed tag with an ABAC policy when one rule must hold across many tables, present and future, instead of repeating ALTER TABLE ... SET MASK on each. The same instinct settles the identity choices: a service principal with OAuth M2M tokens over a long-lived personal access token, a managed identity over stored storage keys or SAS tokens, and the token-free Databricks-to-Databricks share over a bearer token when the recipient is on Unity Catalog. Govern in place, keep privilege narrow, and let the control scale. When a distractor is more permissive, coarser, or needs a credential you would then have to rotate, it is usually the wrong answer.