ARA-C01 Question 432
Single answerAlerts and notifications (for example, errors, email)A data platform team wants to be notified whenever a nightly data quality check finds rows in a landing table with invalid values. The team wants Snowflake to evaluate the condition on a schedule and send an email notification to a shared operations mailbox only when the condition is met. Which solution should an architect recommend?
- A
Create a Snowflake ALERT that runs on a schedule, checks for invalid rows, and calls SYSTEM$SEND_EMAIL when the condition evaluates to TRUE.
- B
Create a TASK that sends an email on every run, and configure the task to stop automatically when no invalid rows are found.
- C
Create a RESOURCE MONITOR with an email notification so that it emails the operations mailbox whenever the data quality query returns invalid rows.
- D
Create a STREAM on the landing table and configure the stream itself to send an email when invalid rows are inserted.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use a Snowflake ALERT with a scheduled condition and an action that sends an email via SYSTEM$SEND_EMAIL. Alerts are intended for event-style monitoring patterns where Snowflake periodically evaluates a SQL condition and executes an action only when needed. This makes them well suited for operational checks such as data quality failures, late-arriving data, or threshold breaches.
By contrast, TASKS are orchestration mechanisms for scheduled execution, but they do not by themselves provide the purpose-built conditional model of alerts. Although a task could be engineered to query a condition and call a notification function, ALERTS are the more direct and maintainable architectural choice for this requirement.
RESOURCE MONITORS are specifically for monitoring credit consumption on warehouses and accounts, not data validation outcomes. STREAMS record table change data and are often paired with tasks, but they do not send notifications themselves.
Relevant Snowflake documentation and best practices include Snowflake ALERTS for scheduled condition evaluation and actions, and notification integrations / SYSTEM$SEND_EMAIL for sending email notifications from Snowflake-supported workflows.
- A. Correct.
Correct. A Snowflake ALERT is designed to evaluate a condition on a schedule and execute an action only when the condition is TRUE. In this scenario, the alert can query the landing table for invalid rows and, if any are found, execute an action such as calling SYSTEM$SEND_EMAIL to notify the shared mailbox. This matches the requirement for conditional, scheduled evaluation and notification.
- B. Incorrect.
Incorrect. A TASK can run SQL or stored procedures on a schedule, but it is not the best fit for conditionally firing only when a query result indicates an issue unless additional custom logic is built into the task body. Also, tasks do not natively 'stop automatically when no invalid rows are found' as described here. This option describes behavior that does not reflect how tasks are typically used for conditional notification scenarios.
- C. Incorrect.
Incorrect. RESOURCE MONITOR email notifications are used for warehouse credit usage thresholds and quota events, not for arbitrary query-based data quality conditions. This distractor reflects a common misconception that any Snowflake notification can be repurposed for application-level monitoring.
- D. Incorrect.
Incorrect. STREAMS capture change data for tables and views; they do not have built-in notification capabilities and cannot independently send emails. A stream could be part of a broader design for detecting changes, but another object such as a task, procedure, or alert would still be required to evaluate logic and trigger notifications.