ADA-C01 Question 535
Select 3Policies (masking and row access) and tagsA financial services company stores customer data in a shared Snowflake database. The CUSTOMERS table contains columns CUSTOMER_ID, REGION, EMAIL, SSN, and ACCOUNT_BALANCE. The security team has already classified SSN and EMAIL with tags and wants to enforce the following requirements with minimal ongoing administration:
- Analysts in the US_ANALYST role should only see rows where REGION = 'US'.
- Analysts in the EU_ANALYST role should only see rows where REGION = 'EU'.
- SSN must be masked for all analyst roles, but visible to the PRIVACY_ADMIN role.
- EMAIL should be masked based on its sensitivity tag so that future tagged columns automatically inherit the masking behavior.
Which combination of actions should the Snowflake administrator take to meet these requirements?
- A
Create a row access policy on the CUSTOMERS table that evaluates CURRENT_ROLE() and REGION, returning TRUE only for rows allowed for US_ANALYST and EU_ANALYST; then attach the policy to the table.
- B
Create a masking policy directly on the SSN column that reveals values only to PRIVACY_ADMIN and masks them for other roles; apply the policy to the SSN column.
- C
Assign the existing sensitivity tag to the CUSTOMERS table and rely on tag inheritance so both SSN and EMAIL will automatically be masked by the same policy.
- D
Associate a masking policy with the sensitivity tag and ensure the EMAIL column has that tag applied, so any future columns with the same tag can automatically use the masking behavior.
- E
Create a row access policy on the REGION column and a masking policy on the CUSTOMER_ID column, because row access policies must be attached to a column and masking policies control row visibility.
Show answer and explanation
Correct answers: A, B, D
Explanation
The best solution combines row-level filtering with column-level masking and tag-based masking where it reduces future administration.
A row access policy should be used to restrict visible rows by REGION for specific roles. This is the correct mechanism for requirement 1 and 2 because row access policies evaluate a boolean expression at query time to determine whether a row is visible.
A direct masking policy on SSN is appropriate for requirement 3 because the rule is explicit: SSN is visible to PRIVACY_ADMIN and masked for analyst roles. This is a classic use case for a masking policy that branches based on the current role or authorization context.
For requirement 4, tag-based masking is the most scalable design. By associating a masking policy with a tag and applying that tag to EMAIL, future columns with the same tag can inherit the masking behavior without individually assigning masking policies. This aligns with Snowflake best practices for centralized governance using tags and policy-based controls.
Key concepts reflected here are:
- Row access policies are for row visibility, not value masking.
- Masking policies are for column-value protection.
- Tag-based masking helps automate protection for similarly classified data elements.
- Tags classify objects, but classification alone does not substitute for policy association and correct application scope.
These behaviors are consistent with Snowflake documentation for row access policies, dynamic data masking, and tag-based masking.
- A. Correct.
Correct. A row access policy is designed to filter which rows are visible at query time based on context such as the active role. In this scenario, evaluating CURRENT_ROLE() (or another context function/lookup table design) against the REGION value is an appropriate way to restrict US_ANALYST to US rows and EU_ANALYST to EU rows. Row access policies are associated with a table or view and reference one or more columns used in the policy signature.
- B. Correct.
Correct. A masking policy is the right control for column-level value obfuscation. Applying a masking policy directly to SSN allows the administrator to return the real value for PRIVACY_ADMIN and a masked value for analyst roles. This is appropriate because the requirement is specific to the SSN column rather than driven by future tag-based propagation.
- C. Incorrect.
Incorrect. Tag inheritance does not mean a masking policy automatically applies from a table tag to all child columns in the way described here. Tags can classify objects, and masking policies can be associated with tags for automatic protection of tagged columns, but simply tagging the table does not automatically ensure both SSN and EMAIL are masked with the same policy. Column-level tagging and policy association behavior must be configured correctly.
- D. Correct.
Correct. Snowflake supports tag-based masking, where a masking policy is associated with a tag so that columns using that tag can have masking enforced automatically. This fits the requirement for EMAIL and future tagged columns, reducing administrative overhead. The key is that the EMAIL column must carry the relevant tag, and the tag must have an associated masking policy.
- E. Incorrect.
Incorrect. This option reverses the purposes of the policy types. Row access policies control row visibility, while masking policies control how column values are displayed. Although row access policy signatures reference columns, the policy is used to govern row-level filtering on a table or view, not to mask CUSTOMER_ID. Likewise, masking policies do not control which rows are returned.