SnowPro Advanced: Security Engineer Question 357
Single answerIdentify the root cause of the incidentA security engineer is investigating an incident in Snowflake after a partner reported that files downloaded from a secure data share contained rows that should have been hidden by a masking policy. The shared objects are exposed through a secure view in a provider account. The engineer confirms that the base table has a masking policy on the PII column, but consumers querying the secure view from the share can still see unmasked values. Which issue is the most likely root cause of the incident?
- A
The masking policy was defined using CURRENT_ROLE(), which evaluates differently for data sharing consumers and can prevent the intended role-based masking behavior in shared access scenarios.
- B
The secure view was not created with CHANGE_TRACKING = TRUE, so Snowflake could not enforce the masking policy during consumer queries.
- C
The share was created without SECURE OBJECTS ONLY enabled, which allows masking policies to be bypassed by consumer accounts.
- D
The provider account did not enable Tri-Secret Secure, so masking policy logic was not applied when data was queried through the share.
Show answer and explanation
Correct answer: A
Explanation
The most likely root cause is that the masking policy was written with role-context logic that does not behave as expected in a data sharing scenario. In Snowflake, dynamic data masking policies can use context functions, but shared data access has important limitations and differences in how policy conditions are evaluated. A common design mistake is to implement a masking policy using CURRENT_ROLE() or similar role-based checks and then assume the same logic will hold when data is accessed through a share. For secure data sharing, Snowflake documentation and best practices emphasize validating policy behavior specifically for shared access patterns and using supported context such as account-based logic where appropriate. The secure view itself does not fix an incorrectly designed masking policy condition, and unrelated features such as change tracking or encryption key models do not determine whether masking is applied.
- A. Correct.
Correct. In Snowflake, data sharing has specific behavior for policy evaluation. When a masking policy relies on context functions such as CURRENT_ROLE(), the expected role context from the consumer side is not available in the same way as in normal provider-side queries. This can result in policy conditions not behaving as intended for shared data. Snowflake guidance for shares commonly recommends using functions and logic that are supported for shared data scenarios, such as account-aware conditions, rather than assuming provider or consumer role context will map cleanly.
- B. Incorrect.
Incorrect. CHANGE_TRACKING supports features such as streams and change metadata use cases; it is not required for masking policy enforcement. A secure view can enforce masking policies without CHANGE_TRACKING being enabled. Choosing this option reflects confusion between object change metadata and dynamic policy enforcement.
- C. Incorrect.
Incorrect. There is no share setting called SECURE OBJECTS ONLY that controls masking policy enforcement in this way. While secure views are important for protecting underlying logic and for sharing governed data safely, masking policy bypass is not caused by a missing share parameter of this name.
- D. Incorrect.
Incorrect. Tri-Secret Secure is related to encryption key management and data protection at rest, not to whether masking policies are evaluated during query execution. This option is a plausible security-sounding distractor, but it addresses encryption architecture rather than access-control or policy-context behavior.