SnowPro Advanced: Security Engineer Question 250
Single answerMonitor the ACCOUNT_USAGE views for information on alert thresholds, correlating events, and incident responses:A Security Engineer needs to investigate a possible account compromise in Snowflake. The team already sends security alerts when authentication-related thresholds are exceeded, and now they want to use Snowflake metadata to reconstruct what happened after one alert fired. They need to identify the user and client source involved in repeated failed logins, correlate the activity to the eventual successful login, and then determine what SQL actions were taken immediately afterward so incident responders can assess impact. Which approach best uses Snowflake ACCOUNT_USAGE views for this investigation?
- A
Query SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY to identify failed and successful authentication attempts for the user, including client IP and event timing, then correlate the successful login to SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY for SQL statements executed soon after the login.
- B
Query SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_USERS to find the failed login attempts and then join to SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY to identify the client IP address used during authentication.
- C
Query SNOWFLAKE.ACCOUNT_USAGE.USERS to detect lockout thresholds and incident severity, then join to SNOWFLAKE.ACCOUNT_USAGE.SESSIONS to determine which SQL statements were executed after the alert.
- D
Query SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY only, because authentication failures and successful logins are recorded there together with all post-login SQL activity.
Show answer and explanation
Correct answer: A
Explanation
The best practice for investigating a suspicious authentication alert in Snowflake is to use the ACCOUNT_USAGE views that align to each stage of the incident timeline. LOGIN_HISTORY is used to review authentication events, including failed and successful login attempts and related connection context. Once a suspicious successful login is identified, QUERY_HISTORY can be used to determine what commands the user executed afterward, which is essential for impact assessment and incident response. This pattern supports correlation of threshold-based alerting with actual account activity. In Snowflake documentation, LOGIN_HISTORY is the key source for login event auditing, while QUERY_HISTORY is the primary source for analyzing executed SQL. Other views such as GRANTS_TO_USERS and ACCESS_HISTORY are valuable in security investigations, but they do not replace LOGIN_HISTORY for authentication analysis.
- A. Correct.
Correct. LOGIN_HISTORY in ACCOUNT_USAGE is the appropriate source for investigating authentication activity such as failed and successful login attempts, including timestamps and client connection details like IP-related information. QUERY_HISTORY is then the right metadata source to determine what SQL activity occurred after a suspicious successful login. This approach supports event correlation for incident response by linking the authentication event timeline to the user's subsequent actions.
- B. Incorrect.
Incorrect. GRANTS_TO_USERS contains privilege grant metadata, not authentication events. ACCESS_HISTORY is used for object access lineage and auditing of data access patterns, not for identifying failed login events or the client IP involved in authentication. This option reflects a common misconception that any security-related view can be used interchangeably for incident reconstruction.
- C. Incorrect.
Incorrect. USERS contains account user metadata, but it does not expose alert thresholds, lockout investigations, or incident severity details for authentication analysis. Also, SESSIONS is not an ACCOUNT_USAGE view used in the way described here for reconstructing post-login SQL activity. QUERY_HISTORY is the standard ACCOUNT_USAGE source for examining statements executed by a user.
- D. Incorrect.
Incorrect. QUERY_HISTORY records query and statement execution metadata after a session is established, but it does not capture failed authentication attempts. Because failed logins occur before a session exists, they must be investigated with LOGIN_HISTORY rather than QUERY_HISTORY alone.