Data-Engineer-Associate - Governance and Security (15% of the exam) - Section 7.3

Understand column-level masking and row-level security to restrict data visibility based on user groups.

Apply row filters and column masks to a table with SQL functions that check group membership, and choose between them and dynamic views for a visibility requirement.

row filterscolumn masksis_account_group_memberdynamic viewsfine-grained access control

Practice question for this objective

Free sampleGovernance and Securitymedium

A data engineer writes a row filter function whose body tests group membership with is_member('analysts') and attaches it to a Unity Catalog table. In the workspace where the analysts group was originally created, members of that group read the expected rows. In a second workspace attached to the same metastore, members of the identity provider group named analysts receive an empty result from the same table, and no grant is missing. What explains this, and what should the engineer change?

CREATE FUNCTION prod.sales.region_filter(region STRING)
RETURN is_member('analysts') OR region = 'EMEA';

AA row filter is registered against the workspace where the ALTER TABLE statement ran, so it must be attached again from the second workspace before members there are evaluated against it.
BThe group is missing USE CATALOG on the catalogue in the second workspace, which causes the filter to evaluate as false and quietly return no rows to those members.
CMembers of the group need EXECUTE on the filter function in the second workspace, and without it the function returns false for them rather than raising a privilege error.
Dis_member tests membership of a workspace local group, so it evaluates as false in the second workspace. Rewrite the body with is_account_group_member so that the account level group is tested instead. Correct

Use is_account_group_member in row filters and column masks, because is_member resolves only workspace local group membership. Unity Catalog groups can exist at the account level and be shared by every workspace attached to the metastore, whereas a workspace local group exists in one workspace alone. is_member resolves against the workspace local set, so the same filter yields different verdicts in different workspaces, while is_account_group_member resolves against the account and therefore behaves identically wherever the table is read.

Why A is wrong: Tempting because the failure is workspace specific, but a row filter is a property of the Unity Catalog table and is enforced from every workspace that reaches the metastore. Reattaching it would change nothing about the membership test.

Why B is wrong: Tempting because a missing traversal privilege is a common cause of unexpected read failures, but its symptom is a permission error naming the object, not a successful query that returns zero rows.

Why C is wrong: Tempting because functions do carry an EXECUTE privilege, but a row filter function is invoked by the governance layer on behalf of the reader, and a genuine privilege shortfall would surface as an error rather than as silent exclusion.

Why D is correct: The two functions look interchangeable but resolve membership at different levels. Only the account level test is consistent for every workspace sharing the metastore, which is why the recommended form for a filter or mask is is_account_group_member.

See more Data-Engineer-Associate practice questions, answers explained.

Exam traps in Governance and Security

Answers that look right on this material and are not. Each one is a distractor from a different question in the Data-Engineer-Associate bank for this domain.

Attach a column mask to the region column that returns the region for global_reporting and a null value for emea_analysts, so that non EMEA rows lose their region label.
Why it is wrong: Tempting because a mask does test group membership, but masking only changes the value rendered in one column. Every row still reaches emea_analysts, so the rows the policy is meant to withhold remain readable.
Both arrangements attach the logic to the base table, so the only practical difference is that the dynamic view stores its redacted output while the column mask recomputes that output for each query.
Why it is wrong: Tempting because both arrangements end in redacted output, but a dynamic view attaches nothing to the base table and stores no result, so neither half of this comparison holds.
Revoke SELECT on prod.fin.payments from every principal except the table owner, and grant SELECT on the dynamic view to the analysts and to the job's service principal instead.
Why it is wrong: Tempting because routing all readers through the view is the standard way to make a dynamic view effective, but the stem requires the job to keep reading the base table by name, which this revoke would break.

Examworthy is not affiliated with or endorsed by Databricks. Original, blueprint-aligned practice material only.