SnowPro Advanced: Security Engineer Question 341
Single answerMonitor Snowflake logsA security engineer needs to investigate whether any users attempted to access sensitive objects outside their normal working hours during the past 7 days. The company wants a solution that can be queried directly in SQL, retains enough detail to identify the user, client IP address, and statement text, and supports near-real-time monitoring without building a custom log export pipeline first. Which Snowflake source should the engineer use?
- A
Query the ACCOUNT_USAGE.LOGIN_HISTORY view because it contains all SQL statements executed by users along with IP addresses and object names
- B
Query the ACCOUNT_USAGE.ACCESS_HISTORY view because it records object access details and can be correlated with QUERY_HISTORY to identify the executed statements and users
- C
Query the INFORMATION_SCHEMA.TABLES view because it shows which users most recently accessed each sensitive table
- D
Enable object event notifications on the sensitive tables and use those notifications as the primary built-in source for historical SQL access analysis
Show answer and explanation
Correct answer: B
Explanation
For monitoring Snowflake logs related to data access, ACCOUNT_USAGE.ACCESS_HISTORY is the most appropriate built-in source because it records object-level access for queries, which is essential when investigating who accessed sensitive data and when. To obtain full investigative context, security engineers often correlate ACCESS_HISTORY with ACCOUNT_USAGE.QUERY_HISTORY for statement text and execution details, and with LOGIN_HISTORY for authentication and client IP context. LOGIN_HISTORY alone is focused on authentication events, not object-level SQL access. INFORMATION_SCHEMA views are metadata-oriented, not audit logs. This aligns with Snowflake best practices for security monitoring and audit investigation using the SNOWFLAKE.ACCOUNT_USAGE schema and related views.
- A. Incorrect.
Incorrect. LOGIN_HISTORY is useful for monitoring authentication activity such as successful and failed logins, client IP addresses, and connection context. However, it does not contain all SQL statements executed by users or the accessed object details needed to investigate table access patterns. A candidate might choose this because the scenario mentions after-hours activity and IP addresses, but LOGIN_HISTORY alone is insufficient for object-level SQL access analysis.
- B. Correct.
Correct. ACCESS_HISTORY is the appropriate built-in source for analyzing which objects were accessed by queries, including columns and base objects referenced, and it can be joined with QUERY_HISTORY to retrieve the SQL text and user context. This is the best fit when investigating access to sensitive objects over a recent period using SQL. It supports practical security investigations without requiring an external export pipeline. Engineers commonly use ACCOUNT_USAGE.ACCESS_HISTORY together with QUERY_HISTORY and sometimes LOGIN_HISTORY for fuller context.
- C. Incorrect.
Incorrect. INFORMATION_SCHEMA.TABLES contains metadata about tables, such as names, schemas, and properties. It does not provide an audit trail of who accessed those tables or when. This distractor targets the misconception that metadata views double as activity logs.
- D. Incorrect.
Incorrect. Snowflake does support event tables and logging/telemetry capabilities for certain observability use cases, but there is no built-in feature where you enable per-table object event notifications to serve as the primary historical SQL access audit source described here. For auditing object access, ACCESS_HISTORY is the relevant source. Someone might pick this if they are thinking generally about event-driven monitoring rather than Snowflake's actual account usage views.