SnowPro Advanced: Security Engineer Question 381
Single answerCorrelate Snowflake data with logs from other systems (for example, identity provider, network devices) to build an incident timelineA security engineer is investigating a suspected account takeover of a Snowflake user who normally signs in through the company's SAML identity provider (IdP). The SOC has three data sources: Snowflake ACCOUNT_USAGE.LOGIN_HISTORY, the IdP's authentication logs, and VPN gateway logs. The goal is to build the most accurate timeline showing whether the user first authenticated through the IdP, from which client IP the Snowflake session originated, and which SQL activity occurred after login. Which approach should the engineer take?
- A
Join Snowflake LOGIN_HISTORY to the IdP logs by user and closely matching event timestamps, use the client IP reported in LOGIN_HISTORY to compare against the VPN logs, and then link the successful login to QUERY_HISTORY by Snowflake session identifiers and time sequence.
- B
Use only QUERY_HISTORY because every query record includes the external IdP authentication method, the originating network device identifier, and the complete MFA challenge result needed to reconstruct the login flow.
- C
Rely on ACCESS_HISTORY as the primary source for sign-in events because it records each authentication attempt, the SAML assertion details, and the remote IP address for both successful and failed logins.
- D
Correlate the IdP logs to Snowflake by matching the IdP-issued SAML assertion ID directly to QUERY_HISTORY, then use WAREHOUSE_METERING_HISTORY to determine which client IP executed the statements after authentication.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use each source for the part of the incident it actually records: the IdP logs for the federated authentication event, Snowflake ACCOUNT_USAGE.LOGIN_HISTORY for Snowflake-side login success/failure and client connection metadata, VPN/network logs for validating source network path and IP usage, and QUERY_HISTORY for post-authentication SQL activity. In practice, investigators usually correlate on username plus timestamp proximity, then validate IP addresses and sequence of events rather than expecting a single universal correlation key across all systems. Snowflake documentation identifies LOGIN_HISTORY as the key source for login attempts and outcomes, while QUERY_HISTORY captures executed statements and ACCESS_HISTORY captures object access caused by queries. This separation of responsibilities is central to building a defensible incident timeline.
- A. Correct.
Correct. For incident timeline reconstruction, the practical approach is to correlate successful Snowflake logins from ACCOUNT_USAGE.LOGIN_HISTORY with the IdP's authentication events using shared attributes such as username and timestamp proximity. LOGIN_HISTORY provides connection details such as client IP and authentication result information that can be compared with VPN or network-device logs. After identifying the relevant login, the engineer can correlate subsequent activity using Snowflake session-level context and time ordering with QUERY_HISTORY to see what SQL was run after the session was established. This mirrors how Snowflake account usage views are typically used in investigations.
- B. Incorrect.
Incorrect. QUERY_HISTORY is useful for determining what SQL ran after a session was established, but it is not the authoritative source for the full authentication flow. It does not provide all IdP-side details such as MFA challenge outcomes or network device identifiers from external systems. Choosing this option reflects the misconception that query telemetry alone can reconstruct login events end to end.
- C. Incorrect.
Incorrect. ACCESS_HISTORY is designed to show data access lineage and object access patterns for executed queries, not to serve as the primary authentication log. It does not record every login attempt or provide complete SAML assertion and remote IP details for successful and failed sign-ins in the way LOGIN_HISTORY does. This option confuses data-access auditing with authentication auditing.
- D. Incorrect.
Incorrect. QUERY_HISTORY does not expose an IdP SAML assertion ID for direct correlation, and WAREHOUSE_METERING_HISTORY tracks warehouse credit consumption over time, not client IP addresses or per-statement connection origins. This distractor combines unrelated Snowflake views and assumes an unsupported direct identifier exists between IdP SAML artifacts and query records.