SnowPro Advanced: Security Engineer Question 114
Single answerManage the masking policy lifecycle:A security engineer manages a masking policy named PII_MASK that is currently attached to the CUSTOMERS.EMAIL column in a production table. The business wants to change the masking logic so that members of the SUPPORT role can view partially masked email addresses, while all other non-privileged roles continue to see fully masked values. The engineer must implement the change with minimal operational risk and without exposing unmasked data during the update. What is the best approach?
- A
Use ALTER MASKING POLICY to update the policy body, because changes to the policy are automatically reflected everywhere the policy is currently assigned.
- B
Unset the masking policy from CUSTOMERS.EMAIL, recreate the policy with the new logic, and then set the policy again so the new version takes effect cleanly.
- C
Create a new masking policy with the updated logic, replace the policy assignment on CUSTOMERS.EMAIL in a controlled change, and validate access behavior for each relevant role.
- D
Clone the production schema, modify the masking policy in the clone, and expect the changed policy logic to propagate back to the source schema after validation.
Show answer and explanation
Correct answer: C
Explanation
The best answer is to create a new masking policy and then replace the policy assignment on the target column in a controlled deployment. This is the most practical way to manage the masking policy lifecycle when the masking logic itself must change. A key point is that changing policy logic is not handled by simply altering the existing policy body in place. Also, temporarily removing a masking policy is risky because it can expose sensitive data during the transition. Snowflake security best practices emphasize maintaining continuous protection of sensitive columns, validating effective behavior by role, and carefully managing policy assignments during change control. Relevant Snowflake documentation areas include Dynamic Data Masking, CREATE MASKING POLICY, and applying or unsetting masking policies on columns.
- A. Incorrect.
Incorrect. In Snowflake, you cannot use ALTER MASKING POLICY to change the masking expression itself in the policy definition. Lifecycle management of masking policies often requires creating a new policy definition and then reapplying or replacing assignments as needed. Assuming the body can simply be altered is a common misconception based on how some other object types are managed.
- B. Incorrect.
Incorrect. This approach introduces unnecessary risk because unsetting the masking policy creates a window in which the sensitive column is unprotected. Even a brief period without the policy could expose raw data to users who otherwise should not see it. This does not meet the requirement to avoid exposing unmasked data during the update.
- C. Correct.
Correct. Creating a new masking policy with the revised logic and then replacing the assignment on the column is the safest lifecycle approach. It avoids a gap where the column is left unprotected, supports controlled rollout, and aligns with Snowflake best practices for evolving masking policy logic. After reassignment, the engineer should validate results using the relevant roles to confirm the conditional masking behaves as expected.
- D. Incorrect.
Incorrect. Cloning is useful for testing and validation, but changes made in a clone do not propagate back to the source objects. A clone is independent after creation. This option may seem attractive for safe testing, but it does not solve the production lifecycle change itself.