ARA-C01 Question 433
Single answerAlerts and notifications (for example, errors, email)A data platform team wants to be notified whenever a nightly ETL task graph fails in Snowflake. The solution must send an email to the on-call distribution list automatically, without requiring external orchestration tools. The architect also wants to minimize noise by notifying only when a failure condition is detected, not on every successful run. Which approach should the architect implement?
- A
Create an ALERT that queries TASK_HISTORY for recent failed task runs and, when the condition is met, executes a notification action that sends an email through a configured email notification integration.
- B
Create a TASK that runs after every ETL task and uses COPY INTO to write failure messages to an internal stage; Snowflake automatically emails stage contents to the distribution list.
- C
Create a RESOURCE MONITOR on the ETL warehouse and configure it to send an email whenever any task in the graph fails.
- D
Create a STREAM on the task graph and trigger an ALERT directly from the stream whenever a task error row appears.
Show answer and explanation
Correct answer: A
Explanation
The best design is to use a Snowflake ALERT together with an email notification integration. Alerts are intended for conditional monitoring patterns: they run a SQL condition on a schedule and perform an action only when the condition evaluates to TRUE. In an architecture scenario like this, the alert can inspect task execution metadata to identify failed runs in the nightly ETL window and then send an email to the on-call list. This satisfies the requirements of remaining inside Snowflake, minimizing alert noise, and targeting failure events specifically. By contrast, RESOURCE MONITOR is for warehouse credit usage, not task failure detection. STREAM objects are for data change tracking, not task error events. Best practice is to scope the alert query carefully to recent runs and relevant task names or root task identifiers to avoid duplicate or stale notifications. Snowflake documentation on ALERT objects, TASK metadata via TASK_HISTORY, and notification integrations for email supports this pattern.
- A. Correct.
Correct. Snowflake ALERT objects are designed to evaluate a condition on a schedule and execute an action when that condition evaluates to TRUE. For this scenario, the alert can query metadata such as TASK_HISTORY (typically via the Information Schema table function or Account Usage view, depending on design) to detect failed task runs within the relevant time window. The action can call the built-in email notification mechanism through a properly configured notification integration. This matches the requirement to notify only on failure and avoids external tools.
- B. Incorrect.
Incorrect. A TASK can automate SQL execution, but COPY INTO writing text to a stage does not cause Snowflake to automatically email the contents of that stage. Internal stages are storage locations, not notification channels. This distractor reflects a common misconception that persisting output somewhere in Snowflake can inherently trigger email delivery.
- C. Incorrect.
Incorrect. RESOURCE MONITOR objects are for monitoring and controlling credit consumption on warehouses and, optionally, sending notifications about usage thresholds. They do not monitor task execution status or task graph failures. Choosing this option confuses compute consumption alerts with operational workflow failure alerts.
- D. Incorrect.
Incorrect. STREAM objects track change data capture for tables, views, and certain externally managed data scenarios; they do not natively capture task graph failure events. You cannot create a stream directly on a task graph to surface task errors for alerting. This option is plausible because streams are often used in event-driven patterns, but not for task execution metadata.