Centralizing row and column access rules with Unity Catalog ABAC policies

Unity Catalog Attribute-Based Access Control (ABAC) policies let admins centrally define row filters and column masks using tags and conditions instead of hand-writing per-table SQL functions. Policies are attached at the catalog, schema, or table level and apply automatically to any matching object, reducing per-object governance overhead. This replaces manual row filter and column mask functions with a scalable, tag-driven approach.

Must-know

• ABAC policies use governed tags (on columns, tables, or attributes) as conditions to decide when a row filter or column mask applies, so tagging data correctly is essential for policies to take effect.
• Policies can be defined once at a catalog or schema level and automatically inherited by all matching tables/columns, avoiding the need to write a separate masking function for every table.
• Column masking policies can redact, hash, or partially obscure sensitive column values based on the querying user's group membership or attributes, without altering the underlying stored data.
• Row filter policies restrict which rows a user sees based on attribute matches (e.g., region or department tags), enforced transparently at query time regardless of how the data is accessed.
• ABAC policies are managed via SQL (CREATE POLICY / governance UI) and require appropriate metastore-level privileges to create or attach; policy changes take effect without needing to rewrite views or tables.
• Because enforcement happens centrally in Unity Catalog, ABAC policies apply consistently across all compute (SQL warehouses, clusters, notebooks) and access paths, unlike ad hoc view-based filtering.

Coverage checked against the published exam guide on Jul 26, 2026.

These are independent practice questions, written against this certification's published exam guide. They are not the certification vendor's own questions, and not the real exam.