SnowPro Advanced: Security Engineer Question 378
Single answerExamine login history (login_history) to trace the source IP, client application, and authentication methods usedA security engineer is investigating a suspected credential-sharing incident in Snowflake. An analyst reports that the service user ETL_APP appeared to log in from an unfamiliar public IP address during the last 24 hours. The engineer needs to identify which login attempts used that user, determine the source IP address, see which client application was used, and confirm the authentication method recorded for each attempt. Which approach should the engineer use?
- A
Query the ACCOUNT_USAGE.LOGIN_HISTORY view for the ETL_APP user and review columns such as EVENT_TIMESTAMP, CLIENT_IP, REPORTED_CLIENT_TYPE, and FIRST_AUTHENTICATION_FACTOR.
- B
Query the ACCOUNT_USAGE.QUERY_HISTORY view for the ETL_APP user and review columns such as QUERY_TEXT, ROLE_NAME, and WAREHOUSE_NAME to infer the login source and authentication type.
- C
Run SHOW USERS LIKE 'ETL_APP' and use the returned properties to identify the user's most recent source IP, client application, and authentication method.
- D
Query the INFORMATION_SCHEMA.SESSIONS view to retrieve historical session data for the last 24 hours, including the exact login IP and authentication factors used.
Show answer and explanation
Correct answer: A
Explanation
For investigating suspicious access, Snowflake's login history data is the correct source because it records authentication events rather than SQL execution activity. Security engineers commonly query login history to trace when a user attempted to sign in, from which IP address, with which client/application, and using which authentication method or factor. In practice, ACCOUNT_USAGE.LOGIN_HISTORY is commonly used for account-level historical analysis, while related table functions can also support login event review depending on the use case and required latency. Best practice is to filter by the specific user and time range, then inspect columns related to event time, client IP, client type, and authentication factor details to validate whether the login pattern is expected. This aligns with Snowflake documentation for monitoring login activity and auditing authentication events.
- A. Correct.
Correct. LOGIN_HISTORY is the appropriate Snowflake source for examining login attempts and authentication events. It is designed for security investigations and includes fields that help trace logins, including timestamp, source IP (CLIENT_IP), client/application details (such as REPORTED_CLIENT_TYPE), and authentication factor information such as FIRST_AUTHENTICATION_FACTOR. This directly supports the requirement to investigate where the login came from, what client was used, and how the user authenticated.
- B. Incorrect.
Incorrect. QUERY_HISTORY is useful for analyzing executed SQL statements after authentication has already succeeded, but it is not the authoritative source for login event details. It does not provide the necessary login-event-centric fields to reliably determine source IP or authentication method for each login attempt. This is a common mistake because candidates often look at query activity when they actually need authentication telemetry.
- C. Incorrect.
Incorrect. SHOW USERS returns user metadata and configuration details, not a historical audit trail of login attempts. It cannot be used to determine the source IP addresses, client application types, or authentication factors used in prior login events. Someone might choose this because user properties can help with account review, but it is not suitable for tracing specific login activity.
- D. Incorrect.
Incorrect. INFORMATION_SCHEMA views are scoped differently and do not provide the same account-level historical login audit data needed here. In particular, historical login details such as exact source IP and authentication factor information are obtained from login history functions/views rather than a generic SESSIONS view for this purpose. This option reflects a plausible but incorrect assumption that session metadata is equivalent to authentication audit history.