ADA-C01 Question 373
Single answerUse log data to monitor user activity, threat detection, and access controlA Snowflake administrator is asked to investigate a possible insider threat after a contractor account was suspected of reading sensitive customer data outside normal business hours. The security team wants a solution that can answer all of the following with the least manual effort: which queries the user ran, whether any role changes affected access, and whether future suspicious access patterns can be monitored centrally over time. Which approach should the administrator implement?
- A
Query ACCOUNT_USAGE views such as QUERY_HISTORY, ACCESS_HISTORY, and GRANTS_TO_USERS/GRANTS_TO_ROLES to reconstruct activity and privilege changes, then load relevant log data into a governed monitoring schema for ongoing analysis and alerting.
- B
Use only SHOW GRANTS ON DATABASE and SHOW USERS to determine whether the contractor accessed sensitive data, because current object grants fully describe historical access behavior.
- C
Review only the LOGIN_HISTORY view to identify suspicious behavior, because login metadata is sufficient to prove which tables were queried and whether privileges changed.
- D
Enable a larger virtual warehouse and query INFORMATION_SCHEMA.TABLES periodically, because warehouse scaling and table metadata provide the most reliable way to detect misuse of sensitive data.
Show answer and explanation
Correct answer: A
Explanation
For investigations involving user activity, threat detection, and access control, Snowflake administrators should rely on audit and telemetry sources designed for historical analysis. ACCOUNT_USAGE views are central to this. QUERY_HISTORY provides executed SQL and execution context; ACCESS_HISTORY helps identify the base objects touched by queries; LOGIN_HISTORY supports authentication event analysis; and grant-related ACCOUNT_USAGE views help determine whether privilege or role changes contributed to the incident. In a real-world security operations workflow, these records are often centralized into a monitoring schema or downstream SIEM process for retention, correlation, and alerting. This approach is more effective than relying on current-state SHOW commands or general metadata views, which do not provide sufficient historical evidence. This matches Snowflake guidance around using Account Usage and access history data for auditing, governance, and security monitoring.
- A. Correct.
Correct. This is the most complete and operationally sound approach. QUERY_HISTORY can identify the SQL statements the contractor executed, including timing and client details. ACCESS_HISTORY is specifically useful for understanding which underlying objects were accessed by queries, helping determine whether sensitive tables or views were read. GRANTS_TO_USERS and GRANTS_TO_ROLES in ACCOUNT_USAGE help investigate whether role grants or privilege changes may have altered the user's effective access. Persisting and analyzing these logs in a dedicated monitoring schema supports ongoing threat detection, trend analysis, and integration with alerting workflows. This aligns with Snowflake best practices for auditing user activity and access control through usage views rather than ad hoc manual inspection.
- B. Incorrect.
Incorrect. SHOW GRANTS and SHOW USERS are useful for current-state inspection, but they do not provide a reliable historical record of what queries were executed or which data objects were actually accessed at a point in time. A common misconception is that current grants alone explain past behavior. In reality, an investigator needs execution and access logs, not just present privileges.
- C. Incorrect.
Incorrect. LOGIN_HISTORY is valuable for reviewing authentication events such as successful and failed logins, client IPs, and timing, and it can help identify suspicious sign-in behavior. However, it does not show which SQL statements were executed or which tables and views were accessed, and it does not by itself provide a full picture of role or privilege changes. It is only one part of a broader monitoring strategy.
- D. Incorrect.
Incorrect. Warehouse size and INFORMATION_SCHEMA.TABLES metadata are unrelated to proving misuse in this scenario. Scaling a warehouse affects performance, not audit fidelity. INFORMATION_SCHEMA.TABLES describes metadata about tables, but it does not provide user-level evidence of query execution, access to sensitive objects, or historical grant changes. This option reflects a misunderstanding of operational metadata versus security audit data.