SnowPro Advanced: Security Engineer Question 129
Single answerUnderstand policy precedence and interactionsA Snowflake security engineer is troubleshooting why a contractor can still see unmasked values in a payroll table. The table PAYROLL.PUBLIC.EMPLOYEE_COMP contains a SALARY column. A masking policy named MP_SALARY_REDACT is directly attached to SALARY and returns NULL unless the current role is HR_ADMIN. The table is also protected by a row access policy that filters rows by business unit, but it does not reference SALARY. In addition, the contractor queries the table through a secure view, SECURE_PAYROLL_V, where SALARY is defined as CASE WHEN CURRENT_ROLE() = 'FINANCE_AUDIT' THEN SALARY ELSE 0 END AS SALARY. The contractor has the FINANCE_AUDIT role, but not HR_ADMIN. Which outcome should the engineer expect, and why?
- A
The contractor sees the original SALARY values because the secure view expression overrides the masking policy on the base table column.
- B
The contractor sees 0 for SALARY because the secure view CASE expression is evaluated before the masking policy.
- C
The contractor sees NULL for SALARY because the masking policy on the base table column is enforced before the secure view can expose the underlying value.
- D
The contractor sees rows only for permitted business units, and original SALARY values for those rows, because row access policies take precedence over masking policies.
Show answer and explanation
Correct answer: C
Explanation
In Snowflake, policy interactions are evaluated according to the object and data access path involved. A row access policy determines which rows are visible, while a masking policy determines what value is returned for a protected column. These are complementary controls, not substitutes for one another. When a masking policy is attached to a base-table column, queries through views, including secure views, still honor the masking policy. The view definition cannot be used to bypass masking on the underlying column. In this scenario, the contractor may see only rows allowed by the row access policy, but the SALARY value remains masked as NULL because the contractor lacks the HR_ADMIN role required by the masking policy. This aligns with Snowflake documentation and best practices for dynamic data masking and row-level security: apply row access policies for row filtering and masking policies for sensitive column protection, and do not rely on views to override base-object security controls.
- A. Incorrect.
Incorrect. A secure view does not override a masking policy applied to an underlying base-table column. Dynamic data masking is enforced when the protected column is queried, including through views. The view can only operate on the value available after masking policy enforcement, not bypass it.
- B. Incorrect.
Incorrect. This option reflects a common misconception about evaluation order. The secure view expression does not get access to the unmasked base-column value when a masking policy is attached. If the user is not entitled by the masking policy, the masked result is what flows into downstream expressions.
- C. Correct.
Correct. Because SALARY has a masking policy directly attached, Snowflake enforces that policy when the column is accessed, including through a secure view. Since the contractor does not hold HR_ADMIN, the masking policy returns NULL. The row access policy may still filter which rows are visible, but it does not unmask SALARY. The secure view's CASE expression cannot reveal original data that the masking policy has already protected.
- D. Incorrect.
Incorrect. Row access policies and masking policies protect different dimensions of access: row visibility versus column value exposure. A row access policy can limit which rows are returned, but it does not supersede or disable a masking policy on a column. Even for visible rows, the masking policy still controls whether SALARY is exposed.