ADA-C01 Question 376
Single answerCreate alertsA Snowflake administrator needs to notify the operations team whenever any task in the PROD_DB.PROD_SCHEMA schema fails. The team wants the solution to run continuously without external orchestration and to avoid sending duplicate notifications for the same failure event. Which approach should the administrator implement?
- A
Create an alert on a schedule that queries ACCOUNT_USAGE.TASK_HISTORY for recent FAILED task runs in PROD_DB.PROD_SCHEMA, and configure the alert action to call SYSTEM$SEND_EMAIL only when the query returns rows that have not already been notified.
- B
Create a stream on TASK_HISTORY and use a triggered alert so the alert fires automatically each time a task fails in PROD_DB.PROD_SCHEMA.
- C
Create a serverless task that directly subscribes to task failure events and sends email notifications by invoking SYSTEM$SEND_EMAIL.
- D
Create an alert that monitors INFORMATION_SCHEMA.TASKS for tasks with the state FAILED, and send an email whenever any row is returned.
Show answer and explanation
Correct answer: A
Explanation
The best solution is to create a Snowflake alert that periodically checks task execution history and sends notifications only for new failures that have not yet been reported. In Snowflake, alerts are designed to evaluate a SQL condition and execute an action when the condition returns one or more rows. For operational monitoring of task failures, administrators commonly query execution history such as ACCOUNT_USAGE.TASK_HISTORY and combine that with state tracking to ensure idempotent notifications.
Key points:
- Alerts are native Snowflake objects intended for SQL-based condition checking and action execution.
- ACCOUNT_USAGE.TASK_HISTORY is the appropriate source for historical task run outcomes such as FAILED.
- INFORMATION_SCHEMA.TASKS describes task objects, not per-run failure events.
- Streams cannot be created on ACCOUNT_USAGE views, so a triggered alert based on a stream over TASK_HISTORY is not supported.
- Avoiding duplicate notifications is a best practice and usually requires persisting identifiers of already-notified failures.
This aligns with Snowflake documentation for CREATE ALERT, alert execution behavior, and the metadata available in TASK_HISTORY and INFORMATION_SCHEMA.
- A. Correct.
Correct. Snowflake alerts evaluate a condition query on a schedule (or can be triggered from a stream in supported scenarios), and if the query returns rows, the alert executes its action. For task failures, a practical pattern is to query task execution history, typically from ACCOUNT_USAGE.TASK_HISTORY, filter for FAILED runs in the target schema, and include logic to avoid duplicate notifications, such as tracking previously notified failures in a table. This satisfies the requirement for an in-platform solution without external orchestration.
- B. Incorrect.
Incorrect. TASK_HISTORY is an account usage view, not a table on which a stream can be created. Streams can be created on tables, external tables, directory tables, dynamic tables, Apache Iceberg tables, and views in supported cases, but not on ACCOUNT_USAGE views. Therefore, a triggered alert based on a stream on TASK_HISTORY is not a valid design.
- C. Incorrect.
Incorrect. Snowflake tasks do not directly subscribe to task failure events in the way event-driven systems like message buses do. A task can run on a schedule or be triggered by stream data, but there is no native task subscription model for task-failure events. Also, the requirement is specifically about using alerts, making this option both functionally and architecturally incorrect.
- D. Incorrect.
Incorrect. INFORMATION_SCHEMA.TASKS contains task definitions and metadata about tasks, not execution history for individual task runs. A task's current definition metadata is not sufficient to reliably detect each failure event, and monitoring it would not meet the requirement to avoid duplicate notifications for each failed run. Execution history views such as TASK_HISTORY are the appropriate source.