SnowPro Advanced: Security Engineer Question 356
Single answerIdentify the root cause of the incidentA Snowflake security engineer is investigating an incident in which a finance analyst was able to query raw cardholder data from the FIN_DB.PAYMENTS schema, even though the analyst's role should have had access only to a masked view. The analyst authenticated normally through the corporate IdP, and no role grants were changed during the incident window. The security team confirms that a masking policy exists on the CARD_NUMBER column in the base table. Which finding most likely identifies the root cause of the incident?
- A
The analyst's active role had the APPLY MASKING POLICY privilege on the schema, which allowed the role to bypass masking during SELECT queries.
- B
The masking policy body evaluated the CURRENT_ROLE() and returned unmasked data because the analyst was using a secondary role that was included in the policy's allowed-role logic.
- C
The analyst connected from a trusted network policy location, so Snowflake automatically bypassed column-level security controls for that session.
- D
The finance database was configured with Time Travel retention greater than 1 day, which allowed the analyst to query an unmasked historical version of the table.
Show answer and explanation
Correct answer: B
Explanation
The most likely root cause is faulty masking policy logic that used role context too broadly. In Snowflake, masking policies are enforced at query time and commonly rely on context functions such as CURRENT_ROLE(), CURRENT_AVAILABLE_ROLES(), or IS_ROLE_IN_SESSION() to determine whether to return masked or unmasked values. If a policy permits access when a privileged role is active or present as a secondary role, a user may legitimately authenticate and still see sensitive data even though no grants changed and the policy remained attached. This aligns with incident investigation best practices: verify the effective session context, inspect the policy definition with DESCRIBE MASKING POLICY or GET_DDL, and confirm whether secondary roles were enabled. Snowflake documentation on dynamic data masking and context functions is directly relevant here, especially guidance around carefully designing conditional logic so that only intended roles receive unmasked results.
- A. Incorrect.
Incorrect. The APPLY MASKING POLICY privilege allows a role to create or apply masking policies to objects; it does not let a querying role bypass an already attached masking policy during SELECT operations. A common misconception is that administrative privileges over policy assignment imply runtime exemption from policy enforcement, but Snowflake enforces masking based on the policy expression at query time.
- B. Correct.
Correct. In Snowflake, masking policies are often written to conditionally reveal data based on context functions such as CURRENT_ROLE() or IS_ROLE_IN_SESSION(). If the policy logic allowed unmasking when a privileged role was active or present as a secondary role, the analyst could see raw data without any role grant changes during the incident window. This is a realistic root cause when a policy was written too broadly or evaluated session role context in an unexpected way.
- C. Incorrect.
Incorrect. Network policies control whether a connection is allowed based on IP rules; they do not disable masking policies, row access policies, or other data access controls after login. Someone might choose this option because network trust is part of Snowflake security posture, but it is unrelated to bypassing column masking.
- D. Incorrect.
Incorrect. Time Travel supports querying historical data states, but it does not inherently remove masking policies from protected columns. If a masking policy is attached to the column, policy enforcement still applies to queries unless the policy logic itself permits unmasking. The retention period is not the most likely explanation for seeing raw protected values.