SnowPro Advanced: Security Engineer Question 130
Single answerManage the row access policy lifecycle:A security engineer manages a row access policy named RAP_CUSTOMER_REGION that is currently attached to the SALES.CUSTOMERS table on the REGION column. The business has approved a new policy condition, but production access cannot be interrupted and the table must remain protected throughout the change. The engineer also wants the ability to validate the new logic before making it effective. Which approach should the engineer take?
- A
Use ALTER ROW ACCESS POLICY RAP_CUSTOMER_REGION SET BODY -> ... to update the policy logic in place, then test the outcome with policy context functions before and after the change.
- B
Drop the row access policy, recreate it with the new logic, and then reattach it to SALES.CUSTOMERS once validation is complete.
- C
Clone the SALES.CUSTOMERS table, replace the policy on the clone, and Snowflake will automatically propagate the updated policy body back to the original table after testing.
- D
Create a masking policy with the new condition and attach it to REGION temporarily, because masking policies can be used to simulate row filtering during row access policy maintenance.
Show answer and explanation
Correct answer: A
Explanation
The best practice for managing the row access policy lifecycle in Snowflake is to modify the existing row access policy in place when the protected object must remain continuously governed. Row access policies are schema-level objects that can be attached to tables or views, and updating the policy body avoids unnecessary detach/reattach operations and reduces risk. For pre-change and post-change validation, Snowflake supports policy context simulation functions so security engineers can test how a policy evaluates for specific users or roles. By contrast, dropping and recreating the policy introduces operational risk, cloning does not push changes back to the original object, and masking policies are not interchangeable with row access policies. This aligns with Snowflake guidance on row access policy administration, ALTER ROW ACCESS POLICY usage, and policy context testing best practices.
- A. Correct.
Correct. Snowflake supports updating an existing row access policy definition in place by altering the policy body, which allows the policy to remain attached to the protected object during the change. This is the safest lifecycle approach when continuous enforcement is required. For validation, Snowflake provides policy context simulation functions that let engineers evaluate behavior under different role or user contexts without detaching the policy from production objects.
- B. Incorrect.
Incorrect. Dropping a row access policy that is attached to a table is not the right lifecycle approach for a no-downtime change. Even if detachment were performed first, this would create a window where the table is either unprotected or operationally disrupted. It also increases deployment risk compared with altering the existing policy definition.
- C. Incorrect.
Incorrect. Cloning can be useful for testing, but replacing a policy on a cloned table does not automatically synchronize or propagate policy changes back to the source object. Snowflake clones are independent objects after creation, so this does not solve the production lifecycle requirement.
- D. Incorrect.
Incorrect. Masking policies and row access policies serve different purposes. A masking policy controls how column values are exposed, while a row access policy determines which rows are visible. A masking policy cannot be used as a temporary substitute to enforce row-level filtering logic.