SnowPro Advanced: Security Engineer Question 115
Single answerManage the masking policy lifecycle:A security engineer needs to replace an existing masking policy on the PROD_DB.HR.EMPLOYEES.EMAIL column with a new policy that uses different role-based logic. The EMPLOYEES table is referenced by several secure views and downstream reporting workloads, so the change must minimize disruption and preserve object availability. What is the best approach to manage this masking policy change safely in Snowflake?
- A
Use CREATE OR REPLACE MASKING POLICY to overwrite the existing policy definition in place, so all attached columns automatically use the updated logic without unsetting the policy.
- B
Unset the masking policy from PROD_DB.HR.EMPLOYEES.EMAIL, create the new policy, and then set the new policy on the column during a maintenance window to avoid dependency errors.
- C
Create the new masking policy separately, then use ALTER TABLE ... MODIFY COLUMN ... SET MASKING POLICY to swap the column to the new policy after validating the new logic.
- D
Drop the existing masking policy first, because Snowflake does not allow a masking policy to be changed while it is attached to a column.
Show answer and explanation
Correct answer: C
Explanation
For production masking policy lifecycle management, the preferred pattern is to create a new policy version, validate its logic, and then reassign the protected column to the new policy. In Snowflake, masking policies are schema-level objects that can be bound to columns, and columns can be updated to use a different masking policy with ALTER TABLE ... MODIFY COLUMN ... SET MASKING POLICY. This approach minimizes exposure risk because the column remains protected throughout the change. It also supports safer change management, rollback planning, and clearer auditability than unsetting a policy or dropping a bound policy. Snowflake documentation on dynamic data masking and ALTER TABLE behavior supports managing policy associations at the column level and using controlled policy changes as a best practice.
- A. Incorrect.
Incorrect. Replacing a masking policy object in place is not the best lifecycle approach for a controlled rollout when the requirement is to replace the policy with a new one and validate different logic safely. In practice, security teams commonly create a separate new policy version, test it, and then explicitly rebind the column. This reduces operational risk and makes rollback and auditing easier. Blindly overwriting the existing policy can introduce immediate behavioral changes across all bindings without a staged validation process.
- B. Incorrect.
Incorrect. Unsetting the masking policy exposes a gap where sensitive data may become visible according to underlying object privileges, which directly conflicts with the requirement to minimize disruption and preserve protection. Although reassigning is technically possible, removing protection first is not a best practice for managing the masking policy lifecycle in production.
- C. Correct.
Correct. The safest approach is to create and validate a new masking policy independently, then assign it to the target column using ALTER TABLE ... MODIFY COLUMN ... SET MASKING POLICY. This preserves protection on the column until the moment of reassignment, supports staged testing, and aligns with common lifecycle management practices such as versioning policies rather than making uncontrolled in-place changes.
- D. Incorrect.
Incorrect. Dropping the existing policy first is not required and is operationally risky. Snowflake tracks policy bindings, and dropping an attached masking policy is not the appropriate way to update a protected column. The correct lifecycle pattern is to attach a different policy to the column rather than remove protection by dropping the currently used policy.