SnowPro Advanced: Security Engineer Question 251
Single answerMonitor the ACCOUNT_USAGE views for information on alert thresholds, correlating events, and incident responses:A security engineer is building an incident monitoring workflow in Snowflake. The team wants to review historical alert activity, determine whether an alert exceeded its threshold conditions, and correlate the resulting alert executions with broader account activity during the same time window for incident response. Which approach best meets this requirement using ACCOUNT_USAGE data?
- A
Query SNOWFLAKE.ACCOUNT_USAGE.SERVERLESS_ALERT_HISTORY to review alert executions and timestamps, then correlate those records with other ACCOUNT_USAGE views such as QUERY_HISTORY or LOGIN_HISTORY for the same timeframe.
- B
Query SNOWFLAKE.ACCOUNT_USAGE.ALERT_HISTORY to retrieve threshold values and incident response details because it stores the full alert definition and downstream remediation actions.
- C
Query INFORMATION_SCHEMA.ALERTS because it provides long-term historical execution details and cross-account event correlation needed for security investigations.
- D
Query SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY because it directly records alert threshold evaluations, alert state transitions, and the incident response steps taken by Snowflake.
Show answer and explanation
Correct answer: A
Explanation
For monitoring alert activity in Snowflake using ACCOUNT_USAGE, the practical pattern is to start with the relevant alert history view and then correlate by timestamp, user, role, query, or session with other ACCOUNT_USAGE telemetry such as QUERY_HISTORY, LOGIN_HISTORY, and sometimes ACCESS_HISTORY. For serverless alerts, SNOWFLAKE.ACCOUNT_USAGE.SERVERLESS_ALERT_HISTORY is the key historical source. This aligns with Snowflake best practices for investigations: use ACCOUNT_USAGE for retained account-level operational and security history, and correlate multiple views rather than expecting one view to contain full incident context. Candidates should recognize that INFORMATION_SCHEMA is not the primary source for long-term historical investigation and that views like ACCESS_HISTORY are complementary, not substitutes for alert execution history.
- A. Correct.
Correct. SERVERLESS_ALERT_HISTORY in SNOWFLAKE.ACCOUNT_USAGE is the appropriate historical source for alert execution activity for alerts that run on serverless compute. It can be used to review execution status and timing, then correlated with other ACCOUNT_USAGE views such as QUERY_HISTORY, LOGIN_HISTORY, or ACCESS_HISTORY depending on the investigation. This is the practical approach for reconstructing what happened around an alert firing and supports incident response workflows.
- B. Incorrect.
Incorrect. There is no ACCOUNT_USAGE view named ALERT_HISTORY that provides the full alert definition, threshold values, and remediation actions in the way described. This option reflects a common misconception that Snowflake exposes a single comprehensive alert audit view with all threshold and response metadata. In practice, engineers use the available ACCOUNT_USAGE alert history view and correlate it with other telemetry sources.
- C. Incorrect.
Incorrect. INFORMATION_SCHEMA is generally intended for current metadata and object introspection within a database or schema context, not long-term account-level security investigation history. It does not provide the kind of historical alert execution trail and cross-event correlation described in the scenario.
- D. Incorrect.
Incorrect. ACCESS_HISTORY is useful for understanding object access lineage and query-related data access patterns, but it does not directly store alert threshold evaluations, alert state transitions, or incident response actions. Someone might choose this because it is a strong security-audit source, but it is not the primary source for alert execution history.