Restricting what a user group can see with column masking and row-level security

Unity Catalog supports fine-grained access control through column masks and row filters, which use SQL functions to dynamically restrict what data users see based on their identity or group membership. These are applied at the table level via ALTER TABLE and enforced automatically for every query against that table, regardless of the tool used to access it.

Must-know

• Row filters are SQL functions that return a BOOLEAN, applied to a table with ALTER TABLE ... SET ROW FILTER, and Databricks evaluates the function per row, hiding rows where it returns false.
• Column masks are SQL functions applied with ALTER TABLE ... ALTER COLUMN ... SET MASK, and they transform or redact the column value (e.g., show NULL or a hashed value) rather than hiding the row.
• Both mechanisms commonly use is_account_group_member() or similar group-membership checks inside the masking/filtering function to conditionally reveal or obscure data.
• Masks and filters are enforced consistently across all access paths (SQL warehouses, notebooks, JDBC/ODBC, Delta Sharing where applicable) since enforcement happens at the table/query layer in Unity Catalog, not in a specific client.
• A single column can only have one mask, and a single table can only have one row filter at a time, though the underlying function can encode multiple conditions.
• Users must have appropriate privileges to create or alter these functions and apply them; regular table consumers are unaware the masking/filtering exists and simply see restricted results.

Coverage checked against the published exam guide on Jul 27, 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.