SnowPro Advanced: Security Engineer Question 380
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 compromise of a Snowflake user account. The identity provider (IdP) shows a successful SAML authentication for user ANALYST1 at 09:14:03 UTC from public IP 198.51.100.24. A firewall log shows outbound traffic from the same IP to Snowflake beginning at 09:14:10 UTC. The engineer needs to build an accurate incident timeline inside Snowflake to confirm when the session was established and what activity occurred immediately afterward. Which approach would BEST correlate Snowflake activity with the external logs?
- A
Query SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY for ANALYST1 around 09:14 UTC, match the EVENT_TIMESTAMP and CLIENT_IP to the IdP and firewall logs, then join to QUERY_HISTORY on USER_NAME and session timing to identify subsequent statements.
- B
Query SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY for ANALYST1 and use BASE_OBJECTS_ACCESSED timestamps as proof of the login event, then compare those timestamps with the SAML assertion time from the IdP.
- C
Use SHOW USERS to retrieve the last login timestamp for ANALYST1, and rely on that value as the authoritative source for correlating with the firewall and IdP logs.
- D
Query SNOWFLAKE.ACCOUNT_USAGE.SESSIONS to obtain the exact SAML authentication timestamp and client IP, then join directly to NETWORK_POLICY_HISTORY for all queries executed in that session.
Show answer and explanation
Correct answer: A
Explanation
To correlate Snowflake events with external security logs, the investigator should start with Snowflake's authentication telemetry and then pivot to activity telemetry. In practice, LOGIN_HISTORY in the SNOWFLAKE.ACCOUNT_USAGE schema is the appropriate source to validate a successful login event, including when it occurred and the client IP address involved. That allows comparison with IdP SAML login records and firewall or proxy logs. After confirming the likely login, QUERY_HISTORY can be used to identify statements executed soon after the authentication event and extend the timeline. ACCESS_HISTORY can add valuable context about which objects were accessed, but it does not replace login telemetry for establishing session start. This approach aligns with Snowflake best practices for incident investigation: use Account Usage views such as LOGIN_HISTORY, QUERY_HISTORY, and, when needed, ACCESS_HISTORY together with external identity and network logs to reconstruct the sequence of events.
- A. Correct.
Correct. LOGIN_HISTORY is the primary Snowflake source for correlating authentication events such as successful logins, including timestamp and client IP details that can be compared with IdP and network-device logs. After identifying the relevant login event, QUERY_HISTORY can be used to reconstruct what the user did after authentication by aligning user and time window information. This is the most practical way to build an incident timeline that spans authentication and subsequent activity.
- B. Incorrect.
Incorrect. ACCESS_HISTORY is useful for understanding data access lineage and which objects were touched, but it is not the authoritative source for the login event itself. BASE_OBJECTS_ACCESSED timestamps reflect object access during query execution, not the initial authentication. A candidate might choose this because it helps investigate impact, but it does not best establish when the session started.
- C. Incorrect.
Incorrect. SHOW USERS does not provide the detailed, event-level authentication history needed for incident reconstruction. Even if an administrator can see some user metadata, it is not the authoritative source for precise login correlation with external logs. The misconception is treating static user metadata as equivalent to audit/event history.
- D. Incorrect.
Incorrect. There is no SNOWFLAKE.ACCOUNT_USAGE view named SESSIONS that provides exact SAML authentication timestamps in the manner described, and NETWORK_POLICY_HISTORY is not used to list all queries executed in a session. This option combines plausible-sounding objects but does not reflect actual Snowflake audit views used for timeline analysis.