SnowPro Advanced: Security Engineer Question 82
Single answerEstablish the order of operations:A security engineer is troubleshooting why an analyst can only see a subset of rows in table SALES.RAW.ORDERS. The table has a row access policy attached that filters rows by REGION based on the current role. The analyst's role also has a secure view, SALES.CURATED.ORDERS_V, built on the same table, and the secure view includes a WHERE clause that limits results to CURRENT_DATE() >= ORDER_DATE. In addition, masking policies are applied to customer email and phone columns in the base table. The analyst queries the secure view and notices that some expected rows are missing before masked values are even considered. Which explanation best describes Snowflake's order of operations in this scenario?
- A
The secure view WHERE clause is evaluated first, then the row access policy filters rows, and finally masking policies are applied to remaining columns.
- B
The row access policy is evaluated before the secure view logic, and masking policies are applied after row filtering on the rows that remain visible.
- C
Masking policies are evaluated first so that protected columns are obscured before any row-level decisions are made by the row access policy or the view.
- D
All policies and the secure view definition are evaluated simultaneously, so there is no deterministic order that explains why rows are missing.
Show answer and explanation
Correct answer: B
Explanation
In Snowflake, understanding policy precedence is critical when multiple protections are layered on the same data object. For a table protected by a row access policy, Snowflake first evaluates row visibility using the policy expression in the current execution context. Only after that row set is determined do downstream query operations, such as a secure view's SELECT and WHERE clause, operate on the visible rows. Column-level protections such as masking policies apply to the values returned from those visible rows. Practically, this means a user may see fewer rows than expected due to the row access policy before the secure view filter or masking behavior is even relevant. This is consistent with Snowflake documentation on row access policies, masking policies, and policy evaluation behavior: row access policies govern row visibility; masking policies govern column exposure. For exam purposes, distinguish clearly between row filtering precedence and column masking precedence when multiple controls are stacked.
- A. Incorrect.
Incorrect. This reverses the relevant precedence. In Snowflake, row access policies are evaluated before other query operations that would expose the row set through the object being queried, including logic in a view built on the protected table. After row visibility is determined, masking policies govern how visible column values are presented. A common misconception is to think of the view's WHERE clause as the first filter simply because it appears in the SQL text the user runs.
- B. Correct.
Correct. Snowflake evaluates the row access policy first to determine which rows the querying context can see. After the allowed row set is established, other query logic such as the secure view definition and its WHERE clause is applied. Masking policies then affect the presentation of protected column values for rows that remain visible. This explains why rows can be missing before the user even considers whether sensitive columns are masked.
- C. Incorrect.
Incorrect. Masking policies do not decide row visibility; they control how column values are returned for rows the user is already permitted to access. Applying masking first would not explain missing rows. This option reflects a frequent confusion between row-level security and column-level security.
- D. Incorrect.
Incorrect. Snowflake does have a deterministic evaluation model for these protections. Row access policies affect which rows are visible, and masking policies affect column values in the visible result set. The secure view definition is also processed in that broader order of operations. Saying the steps are simultaneous ignores documented policy behavior and is not useful for troubleshooting.