SnowPro Advanced: Security Engineer Question 131
Single answerManage the row access policy lifecycle:A security engineer needs to update an existing row access policy used on a sensitive SALES table. The current policy filters rows by REGION based on the querying user's role. A new requirement states that users with the AUDIT_REVIEWER role must be able to see all rows, while existing regional restrictions must remain in effect for everyone else. The policy is already attached to the SALES.REGION column and is referenced by multiple reporting views. The engineer must implement the change with minimal disruption and without detaching the policy from the table. Which action should the engineer take?
- A
Use ALTER ROW ACCESS POLICY to modify the policy body so it returns TRUE for users with the AUDIT_REVIEWER role and preserves the existing logic for other roles.
- B
Drop the row access policy and recreate it with the new logic; Snowflake will automatically reattach it to all previously protected columns and views.
- C
Create a second row access policy for the AUDIT_REVIEWER role and attach both policies to the SALES.REGION column so Snowflake evaluates them in order.
- D
Clone the SALES table, apply a new row access policy to the clone for AUDIT_REVIEWER access, and swap the clone with the original table to avoid changing the existing policy.
Show answer and explanation
Correct answer: A
Explanation
Managing the row access policy lifecycle in Snowflake often involves updating policy logic in place rather than detaching or recreating the policy. For an already attached policy, ALTER ROW ACCESS POLICY is the preferred mechanism to change the body while preserving attachments and minimizing impact on dependent objects. This is especially important in production environments where policies are referenced by multiple tables or views. A key best practice is to design policy logic to accommodate exception roles, such as auditors, by checking role context with supported functions like IS_ROLE_IN_SESSION and then falling back to the existing row-filtering conditions. Snowflake supports one row access policy per protected column, so creating multiple concurrent row access policies on the same column is not valid. Dropping and recreating policies or using table clones for routine policy updates is operationally heavier and not aligned with least-disruption lifecycle management.
- A. Correct.
Correct. Snowflake supports updating the logic of an existing row access policy by using ALTER ROW ACCESS POLICY ... SET BODY ->
. This is the appropriate lifecycle operation when the policy is already attached and the goal is to change evaluation behavior without removing and reapplying the policy. Adding a condition such as IS_ROLE_IN_SESSION('AUDIT_REVIEWER') to allow full visibility for that role while retaining the existing regional checks is the least disruptive approach. - B. Incorrect.
Incorrect. Dropping a row access policy that is in use is not the right lifecycle action for a simple logic change. Snowflake does not automatically reattach a dropped-and-recreated policy to all prior objects. In practice, dependencies must be managed explicitly, and dropping an attached policy would create unnecessary operational risk and disruption.
- C. Incorrect.
Incorrect. A column can have only one row access policy associated with it. Snowflake does not support stacking multiple row access policies on the same column and evaluating them sequentially. This option reflects a common misconception based on how layered controls work in some other systems.
- D. Incorrect.
Incorrect. Cloning and swapping a table is unnecessary for modifying row access policy logic and would increase complexity. It also introduces risk around object dependencies, grants, and downstream references. Since the requirement is to keep the existing policy attached and minimize disruption, directly altering the policy body is the best choice.