ARA-C01 Question 426
Single answerMonitoring and alertingA global analytics team runs business-critical ETL workloads in Snowflake. The architecture team needs a monitoring and alerting design that will notify operators when any task in a task graph fails, while minimizing custom polling code and allowing the notification to include current metadata from Snowflake at the time the failure is detected. Which approach should the architect recommend?
- A
Create a Snowflake ALERT object that periodically queries TASK_HISTORY for failed task runs and, when a failure is found, executes an action that calls a stored procedure to send a notification through a configured notification integration.
- B
Create a materialized view on TASK_HISTORY filtered to FAILED rows and configure external monitoring to subscribe directly to changes in the materialized view.
- C
Enable ACCESS_HISTORY on the database and configure a masking policy to raise an error whenever a task fails, which can then be consumed by an email integration.
- D
Use a RESOURCE MONITOR on the warehouse that runs the task graph and configure the suspend trigger to send an alert whenever any task in the graph fails.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use a Snowflake ALERT that evaluates task execution metadata and triggers an action when a task failure is detected. This aligns with Snowflake best practices for in-platform monitoring and alerting because it reduces the need for external polling services and keeps the detection logic close to the data and metadata being monitored. In this scenario, querying TASK_HISTORY is appropriate because task execution state is captured there, and the alert action can call procedural logic that sends notifications through a supported notification integration. By contrast, resource monitors are for compute credit usage thresholds, ACCESS_HISTORY is for auditing data access, and materialized views are not a native operational event-notification mechanism for task failures. Relevant Snowflake documentation areas include Alerts, Tasks and task graph monitoring, TASK_HISTORY, notification integrations, and Resource Monitors.
- A. Correct.
Correct. Snowflake Alerts are designed for condition-based monitoring inside Snowflake. An ALERT can run on a schedule, query account metadata such as TASK_HISTORY, and execute an action when the condition is met. This is a practical way to detect failed task executions with minimal custom polling infrastructure. The action can invoke a stored procedure or other SQL logic that uses a configured notification integration to send notifications, while including fresh metadata from the failure event.
- B. Incorrect.
Incorrect. TASK_HISTORY is exposed through table functions and Account Usage views, not as a base table intended for materialized views. Snowflake does not support creating a materialized view directly on TASK_HISTORY table function output for event-style subscriptions. Also, Snowflake materialized views are not a native alerting or change-subscription mechanism for operational notifications.
- C. Incorrect.
Incorrect. ACCESS_HISTORY is used for governance, auditing, and lineage-style analysis of object access, not for detecting task execution failures. Masking policies protect data at query time and do not function as an operational alerting mechanism. There is also no pattern where a masking policy raises task-failure notifications through an email integration.
- D. Incorrect.
Incorrect. Resource monitors track credit consumption for warehouses and can trigger actions such as notifications or suspension when usage thresholds are reached. They do not monitor task success or failure states. A warehouse suspension event caused by a resource monitor is unrelated to whether an individual task in a task graph succeeded or failed.