ARA-C01 Question 427
Single answerMonitoring and alertingA retail company runs critical hourly ELT pipelines in Snowflake using TASKs. The architecture team needs a solution to detect task failures quickly and notify the on-call team without requiring engineers to continuously check query history. The solution must be native to Snowflake and should support near-real-time monitoring of task execution state changes. Which approach should the architect recommend?
- A
Create an ALERT object that evaluates TASK_HISTORY for recent failed task runs and invokes a notification integration or email notification when a failure is detected
- B
Enable AUTO_SUSPEND = FALSE on the warehouse used by the tasks so failed runs remain visible for external monitoring tools
- C
Query ACCOUNT_USAGE.QUERY_HISTORY every 24 hours and manually review failed statements associated with the tasks
- D
Use a materialized view on top of INFORMATION_SCHEMA.TASK_HISTORY and configure it to push notifications automatically when rows change
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use a Snowflake ALERT to evaluate task execution history and send a notification when a failure condition is detected. This aligns with Snowflake-native monitoring and alerting capabilities and avoids relying on manual checks or non-native tooling. In practice, architects commonly combine TASKs, TASK_HISTORY, and ALERT objects to monitor orchestration health. ACCOUNT_USAGE and QUERY_HISTORY are useful for analysis and reporting, but they are less suitable as the primary mechanism for timely operational alerting. Warehouse settings such as AUTO_SUSPEND affect compute consumption, not observability. Snowflake documentation on Alerts, Tasks, and monitoring metadata views/functions supports this pattern as a best practice for proactive pipeline monitoring.
- A. Correct.
Correct. Snowflake provides ALERT objects for server-side conditional monitoring and response. An alert can run on a schedule, evaluate task execution metadata such as TASK_HISTORY, and trigger an action when a condition is met. This is a native Snowflake approach and is appropriate for near-real-time monitoring of task failures without requiring continuous manual review.
- B. Incorrect.
Incorrect. AUTO_SUSPEND controls warehouse runtime behavior and cost optimization, not alerting or failure notification. Keeping a warehouse running does not create a monitoring or notification mechanism for task failures.
- C. Incorrect.
Incorrect. Reviewing ACCOUNT_USAGE.QUERY_HISTORY every 24 hours is neither near-real-time nor operationally efficient for critical hourly pipelines. Although query history can help with investigation, this approach does not satisfy the requirement for timely automated notification.
- D. Incorrect.
Incorrect. Materialized views cannot be used to automatically push notifications when underlying rows change, and they are not the mechanism for event-driven alerting in Snowflake. Also, TASK_HISTORY is intended for monitoring and troubleshooting, but automatic notifications should be implemented with ALERT objects rather than materialized views.