SnowPro Advanced: Security Engineer Question 117
Single answerMonitor the impact of policy changes on data visibilityA security engineer updates a masking policy on the CUSTOMERS.EMAIL column in a production table to tighten visibility for users in the ANALYST role. Shortly after deployment, business users report that some dashboards now show masked values where they previously saw full email addresses. The engineer needs to determine which role changes or policy logic changes caused the visibility impact and validate the effect without directly querying production data as each end user. Which approach provides the MOST effective way to monitor and investigate the impact of the policy change?
- A
Query ACCOUNT_USAGE.POLICY_REFERENCES to confirm where the masking policy is attached, review the policy definition with GET_DDL, and use POLICY_CONTEXT with simulated role conditions to evaluate how the policy will behave for different roles.
- B
Review QUERY_HISTORY for all dashboard queries and compare execution times before and after the change, because a masking policy that changes visibility will also show a measurable performance regression.
- C
Use SHOW PARAMETERS on the database and schema that contain the table, because masking policy behavior changes are recorded as object parameters and will identify which roles lost access.
- D
Clone the production database, detach the masking policy from the cloned table, and compare row counts between the clone and production to determine which users are affected by masking.
Show answer and explanation
Correct answer: A
Explanation
To monitor the impact of policy changes on data visibility in Snowflake, a security engineer should focus on three things: where the policy is applied, what the current policy logic is, and how that logic evaluates under different runtime contexts. POLICY_REFERENCES in Snowflake Account Usage is appropriate for determining attachment scope. GET_DDL is a practical way to inspect the current masking policy definition and compare it against prior versions if change control is in place. POLICY_CONTEXT is the key tool for validating masking or row access policy behavior by simulating context such as role values without having to log in as each user. This aligns with Snowflake best practices for secure testing and troubleshooting of dynamic data protection behavior. By contrast, query history and object parameters may support broader investigation, but they do not directly explain policy-driven visibility changes. Likewise, comparing row counts is not suitable for masking policies because masking affects displayed values rather than row-level inclusion.
- A. Correct.
Correct. This is the best investigative workflow for monitoring the impact of a masking policy change on data visibility. ACCOUNT_USAGE.POLICY_REFERENCES helps identify the objects and columns currently associated with the policy. GET_DDL can be used to inspect the active masking policy definition and verify what logic changed. POLICY_CONTEXT is specifically designed to simulate query conditions such as CURRENT_ROLE and other context values so administrators can evaluate how a masking or row access policy would resolve for different scenarios without impersonating users or exposing production data broadly. This directly addresses both scope and behavioral impact.
- B. Incorrect.
Incorrect. QUERY_HISTORY can help identify which queries accessed the affected objects, but it does not directly explain why masking behavior changed for specific roles. A policy change does not necessarily create a measurable performance difference, and visibility issues are driven by policy logic and execution context rather than query duration. This option focuses on an indirect signal instead of the actual mechanism controlling data visibility.
- C. Incorrect.
Incorrect. SHOW PARAMETERS is used to inspect configurable object/session/account parameters, not to track masking policy logic or role-by-role visibility outcomes. Masking policies are schema objects attached to columns, and their behavior depends on policy expressions and runtime context. Parameters will not identify which roles lost visibility because of a masking policy update.
- D. Incorrect.
Incorrect. Cloning can be useful for testing, but detaching the policy from a cloned object and comparing row counts is not an effective way to understand masking impact. Masking policies generally alter returned values, not row counts. In addition, removing the policy from the clone only shows an unmasked baseline, not how the revised policy behaves across roles. This approach misses the need to simulate policy evaluation conditions and can create unnecessary administrative work.