SnowPro Advanced: Security Engineer Question 252
Single answerUse Snowflake Trail observability featuresA security engineering team is piloting Snowflake Trail to improve observability of potentially risky user activity. They need to investigate whether a contractor account viewed sensitive data from outside normal working hours and then exported query results. The team wants the fastest way to correlate these actions within Snowflake-native observability capabilities, without building a separate log pipeline first. Which approach should the security engineer take?
- A
Use Snowflake Trail event data to review the relevant access and activity records, then correlate the user, time window, and related actions such as query execution and result export within Snowflake.
- B
Query only LOGIN_HISTORY because it contains complete information about all data reads, query text, and result exports associated with the user session.
- C
Rely on ACCESS_HISTORY alone because it captures every security-relevant action in Snowflake, including authentication events and all result export activity.
- D
Enable network policies in report-only mode because Snowflake Trail automatically reconstructs historical user activity only after network policy evaluation is turned on.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake Trail's observability features to investigate and correlate the suspicious sequence of actions directly in Snowflake. For a Security Engineer, the practical goal is not just to identify that a user logged in, but to connect identity, timing, access behavior, and follow-on actions relevant to potential data exfiltration. Snowflake provides multiple telemetry and history surfaces for different purposes; the key is understanding that no single legacy history view such as LOGIN_HISTORY or ACCESS_HISTORY alone fully answers a broad incident-investigation question. Snowflake Trail is designed to centralize and improve this observability workflow for security investigations. As a best practice, security teams should use Snowflake-native event and history data for rapid triage, then enrich or export to downstream monitoring systems if needed. This aligns with Snowflake guidance around using account usage, event/telemetry surfaces, and native observability features for security monitoring and investigations.
- A. Correct.
Correct. Snowflake Trail is intended to improve observability by providing security-relevant event data that can be used to investigate suspicious activity in Snowflake. For this scenario, the right approach is to use Snowflake Trail data to correlate the actor, timeframe, and sequence of events, such as access behavior and subsequent actions, directly in Snowflake without first standing up an external SIEM or custom log pipeline. This matches the requirement for rapid, Snowflake-native investigation.
- B. Incorrect.
Incorrect. LOGIN_HISTORY is useful for authentication and session analysis, but it does not by itself provide a complete picture of data reads, query text, and result export actions. A common misconception is that login telemetry alone is sufficient for security investigations. In practice, login records help establish who connected and from where, but additional observability data is required to determine what the user did after authenticating.
- C. Incorrect.
Incorrect. ACCESS_HISTORY is valuable for understanding object access lineage and which base objects were touched by queries, but it is not a complete source for every security-relevant event. It does not replace broader observability capabilities for authentication-related events or all export-style activity. This option reflects the common mistake of treating access lineage as a full audit trail for all security investigations.
- D. Incorrect.
Incorrect. Network policies are preventive controls used to restrict connectivity based on network rules; they are not a prerequisite for Snowflake Trail observability and do not cause Snowflake Trail to reconstruct historical activity. The misconception here is confusing enforcement controls with observability features. Report-only behavior and retrospective activity reconstruction are not how network policies work in this context.