SnowPro Advanced: Security Engineer Question 343
Single answerInvestigate alerts from security toolsA Snowflake security engineer receives an alert from a cloud security monitoring tool indicating that a service account executed an unusually large number of failed login attempts against a production Snowflake account during the last hour. The monitoring tool only provides the Snowflake username and an approximate time window. The engineer must quickly verify whether the activity was caused by an automated process with an expired credential or by a broader compromise attempt, using native Snowflake capabilities first. Which action should the engineer take FIRST to investigate this alert?
- A
Query the ACCOUNT_USAGE.LOGIN_HISTORY view for the service account and the relevant time window to review client IPs, connection clients, authentication method, and failure reasons
- B
Immediately rotate all account passwords and revoke every active session in the account before gathering any evidence
- C
Query the ACCOUNT_USAGE.ACCESS_HISTORY view to determine which tables were modified by the service account during the failed login window
- D
Use DESCRIBE USER on the service account to identify all historical failed login attempts and client IP addresses
- E
Query the ACCOUNT_USAGE.QUERY_HISTORY view to identify the exact SQL statements that failed during authentication
Show answer and explanation
Correct answer: A
Explanation
When investigating an alert from a security tool about failed Snowflake logins, the engineer should begin with the Snowflake audit source that directly records authentication events: LOGIN_HISTORY. This allows the engineer to validate the alert, identify patterns such as repeated failures from the same IP or client, and determine whether the behavior aligns with a legitimate automation issue such as an expired password, key, or changed connection configuration. If the failures are followed by successful logins from unusual locations or clients, the engineer can then expand the investigation into SESSION, QUERY, and object-access views as needed. Snowflake best practice is to use the relevant ACCOUNT_USAGE views for evidence-driven investigation before taking disruptive remediation steps unless there is already clear evidence of active compromise. In Snowflake documentation, LOGIN_HISTORY is the primary source for reviewing login events, while QUERY_HISTORY and ACCESS_HISTORY are used for post-authentication activity analysis.
- A. Correct.
Correct. LOGIN_HISTORY is the most appropriate native Snowflake source to investigate authentication alerts. It provides login event details such as event timestamps, client IP address, client type, authentication-related attributes, and whether the login succeeded or failed. Reviewing these records first helps determine whether the failed attempts came from a known automation host, a changed client, or a suspicious set of source IPs. This is the fastest evidence-based first step when the alert is specifically about failed logins.
- B. Incorrect.
Incorrect. Rotating all passwords and revoking all sessions may be appropriate later in an incident response workflow if compromise is suspected, but it is not the best FIRST step here. The question asks for initial investigation using native Snowflake capabilities. Immediate broad remediation without first validating the scope and source of the alert can disrupt production and remove useful forensic context.
- C. Incorrect.
Incorrect. ACCESS_HISTORY is used to analyze object access and data lineage-related activity after successful query execution, not failed authentication attempts. Because the alert concerns failed logins, ACCESS_HISTORY would not be the primary source for determining why authentication failed or where the requests originated.
- D. Incorrect.
Incorrect. DESCRIBE USER returns current user metadata and properties, but it does not provide a historical audit trail of failed login attempts or source IP details. A candidate might choose this option thinking user metadata includes recent login diagnostics, but Snowflake login investigation is done through usage/audit views such as LOGIN_HISTORY.
- E. Incorrect.
Incorrect. QUERY_HISTORY contains executed query metadata. Failed authentication attempts occur before a session is established and therefore do not generate SQL statements in QUERY_HISTORY. This is a common misconception when investigating security events: not all account activity is represented as query activity.