SnowPro Advanced: Security Engineer Question 269
Single answerConfigure email or external integrations for security alerts using tasks and streamsA security engineering team wants Snowflake to notify the on-call distribution list whenever a row is inserted into an AUDIT_FINDINGS table with SEVERITY = 'CRITICAL'. They want the process to avoid duplicate notifications, use native Snowflake objects where possible, and run on a schedule without relying on an external orchestrator. Which design best meets these requirements?
- A
Create a stream on AUDIT_FINDINGS, create a scheduled task that reads only new rows from the stream where SEVERITY = 'CRITICAL', and call SYSTEM$SEND_EMAIL using a configured notification integration.
- B
Create a scheduled task that queries AUDIT_FINDINGS directly every minute for rows where SEVERITY = 'CRITICAL' and calls SYSTEM$SEND_EMAIL for all matching rows.
- C
Create an alert on AUDIT_FINDINGS and configure it to send email directly without a notification integration because alerts can natively deliver email messages.
- D
Create an external function that polls AUDIT_FINDINGS for critical rows and invokes it from a task; this is required because tasks cannot use streams when sending email.
Show answer and explanation
Correct answer: A
Explanation
The best design is to combine a stream, a task, and an email notification integration. Streams are the native mechanism for tracking table changes and are well-suited for preventing duplicate processing because the task can consume only new change records since the last offset. Tasks provide native scheduling inside Snowflake, eliminating the need for an external orchestrator. For email delivery, Snowflake supports SYSTEM$SEND_EMAIL, which requires a notification integration configured for email. This pattern is practical for security alerting workflows where new findings or events must trigger notifications. By contrast, repeatedly querying the base table without CDC typically leads to duplicate alerts unless custom state tracking is added. Best-practice Snowflake documentation for tasks, streams, and notification integrations supports this design approach.
- A. Correct.
Correct. A stream tracks change data capture (CDC) for the source table, allowing the task to process only newly inserted or changed rows instead of rescanning the full table. A scheduled task provides the native Snowflake orchestration. To send email from Snowflake, you use SYSTEM$SEND_EMAIL with a notification integration configured for email delivery. This combination meets the requirements for native scheduling, deduplication of processed changes, and email notification.
- B. Incorrect.
Incorrect. Querying the base table directly on a schedule can repeatedly find the same CRITICAL rows unless additional state-management logic is built. That approach does not inherently avoid duplicate notifications. While a task can run on a schedule and call SYSTEM$SEND_EMAIL, the absence of a stream or another reliable change-tracking mechanism makes this design weaker for the stated requirement.
- C. Incorrect.
Incorrect. This reflects a common misconception. Snowflake alerts are used to evaluate a condition and perform an action, but email delivery still relies on a notification integration and the appropriate email-sending mechanism. The statement that email can be sent directly without a notification integration is not correct.
- D. Incorrect.
Incorrect. External functions are not required for this use case. Tasks can work with streams, and Snowflake provides native email support through SYSTEM$SEND_EMAIL with a notification integration. Adding an external polling service increases complexity and does not satisfy the preference to use native Snowflake objects where possible.