SnowPro Advanced: Security Engineer Question 83
Single answerEstablish the order of operations:A Snowflake security engineer is troubleshooting why an analyst can still view rows for the FINANCE department in a secure view, even though a row access policy should restrict the analyst to only their own department. The view is defined on a table that also has a masking policy on the SALARY column. The analyst's role has SELECT on the secure view but no direct privileges on the base table. During testing, the engineer notices that rows are returned first and then the SALARY values are masked where applicable. Which explanation best describes Snowflake's order of operations in this scenario?
- A
Snowflake evaluates the masking policy before the row access policy, so column protection can allow row visibility that would otherwise be filtered out.
- B
Snowflake evaluates the row access policy before the masking policy, so row filtering should occur before any column masking is applied to the remaining rows.
- C
Snowflake evaluates secure view logic after all masking and row access policies, so the secure view can bypass the row access policy if the user lacks base table privileges.
- D
Snowflake evaluates object privileges before all policy logic, and because the analyst has SELECT on the secure view, the row access policy is not enforced.
Show answer and explanation
Correct answer: B
Explanation
The key concept is Snowflake's policy evaluation order: row access policies are applied before masking policies. This means Snowflake first determines which rows are visible to the querying context, and only afterward applies masking to protected columns in those visible rows. In a real troubleshooting scenario, if a user can still see rows they should not, the engineer should investigate the row access policy expression, any mapping table used by the policy, the CURRENT_ROLE or other context functions referenced by the policy, and whether the query is being executed under the expected role. The presence of a secure view and a masking policy does not change this order. Snowflake documentation on policy enforcement and data access governance describes that row-level controls are evaluated prior to column-level masking, which is why masking cannot be relied upon to prevent row visibility.
- A. Incorrect.
Incorrect. This reverses Snowflake's policy evaluation order. A masking policy does not determine whether a row is visible; it only transforms protected column values for rows that are already eligible to be returned. Treating masking as if it controls row-level visibility is a common misconception.
- B. Correct.
Correct. In Snowflake, row access policies are evaluated before masking policies. First, Snowflake determines which rows the querying role is allowed to see. Then, for the rows that remain, masking policies are applied to protected columns such as SALARY. If unauthorized FINANCE rows are still visible, the issue is likely with the row access policy definition, mapping table logic, policy context, or role setup rather than masking behavior.
- C. Incorrect.
Incorrect. Secure views do not bypass row access policies on underlying tables. Snowflake still enforces governance policies on the underlying data objects according to its policy processing rules. A user having access only to the secure view does not change the fact that the row access policy is evaluated on the base table data before masking is applied.
- D. Incorrect.
Incorrect. Object privileges such as SELECT are necessary to query the secure view, but they do not replace policy enforcement. Snowflake applies both access control and data governance controls. Having SELECT on a view does not exempt the query from row access policies or masking policies defined on underlying objects.