What you will be able to do
- Explain what Trust Center scanner packages check, which run by default, and how findings trigger email notifications
- Build a security alert from a condition and an action that sends a notification or runs a task
- Avoid duplicate alert evaluations by using schedule-based timestamps
- Collect telemetry in an event table and route it to external observability tools
1.Trust Center: scanners, findings and notifications
Querying audit views manually tells you what already happened. Trust Center works the other way: it scans your account on a schedule and reports configuration risks as findings. Scanners are grouped into scanner packages, including CIS Benchmarks, Threat Intelligence and AI Security. Each package has its own schedule, and enabled scanners can cost money to run.
Security Essentials checks the controls most closely tied to the login attacks covered in LOGIN_HISTORY. It checks that an authentication policy requires human users who sign in with passwords to enroll in MFA, and that those users have actually enrolled. It also checks for an account-level network policy that allows only trusted IP addresses. It only scans human users, meaning user objects with TYPE PERSON or NULL, so service users are out of its scope. On Business Critical Edition or VPS accounts with a capacity contract, Snowflake can enable the AI Security package automatically.
You set up notifications for findings in the Trust Center interface in Snowsight. They can cover a whole scanner package or individual scanners, and you can limit them by severity. Emails go to users with verified email addresses. If you choose admin users as recipients, Snowflake sends to the organization-level security notification contact first, then the account-level contact, and only then to ACCOUNTADMIN users.
Checkpoint 1 of 5· Check yourself
A security lead wants an email only when Trust Center reports serious findings, not every low-risk one. What do they configure?
Trust Center notification settings include a severity threshold for each package or scanner.
“You can also specify the severity of the findings for which email notifications are sent.”Source: docs.snowflake.com
2.Custom security alerts and notifications
Trust Center checks configuration. When you need a specific threshold of your own, such as a number of failed logins or reads of a sensitive table, you write a Snowflake alert. An alert pairs a condition with an action. The condition, IF( EXISTS( condition )), can be a SELECT, SHOW or CALL statement. If it returns one or more rows, the THEN action runs. To send a message, the action calls the SYSTEM$SEND_EMAIL or SYSTEM$SEND_SNOWFLAKE_NOTIFICATION stored procedure. Alerts that reference a notification integration fail validation if that integration does not exist or is the wrong type.
Notifications can go to email, cloud provider queues, Slack, PagerDuty and Microsoft Teams. The queue and webhook options are how an alert reaches an external SIEM or chat tool. Sending a message is not the only option: an alert action can also run a task or log a new row to a table. That lets one detection both notify people and record an incident or start a response.
Two practices make security alerts more reliable. First, define the condition's time window with SCHEDULED_TIME and LAST_SUCCESSFUL_SCHEDULED_TIME instead of CURRENT_TIMESTAMP. That way, a delay between the alert's schedule and when it actually runs does not cause the same events to be evaluated twice. Second, put the details in the notification. Retrieve the condition query's ID with GET_CONDITION_QUERY_UUID, then pass it to RESULT_SCAN, so the message can list the offending users or IPs.
The exam guide also mentions streams as an alert trigger, but none of the sources here document how streams combine with tasks for security alerts. Check Snowflake's stream documentation for that pattern.
Checkpoint 2 of 5· Exam question
Which two LOGIN_HISTORY patterns best indicate a password-spraying attack coming from a single source?(Select 2)
Correct answers: A, D — A burst of failures from one CLIENT_IP that is followed by a successful login for one of the targeted users from that same address.; One CLIENT_IP with IS_SUCCESS = 'NO' rows spread across dozens of distinct USER_NAME values inside a short window, all using a password factor.
- A. A success right after a failure burst from the same source suggests one guessed credential and is the highest-priority follow-up.
- B. Expired assertions are a federation or clock-skew problem and do not involve guessing passwords.
- C. That value marks internal Snowflake operations, not external attackers.
- D. Spraying tries few passwords against many accounts, so many users failing from the same IP is the classic signature.
- E. Different client types with MFA succeeding is normal for one user and says nothing about guessing.
Checkpoint 3 of 5· Check yourself
An alert that counts failed logins keeps firing twice for the same burst. Which change does Snowflake recommend?
Using schedule-based timestamps accounts for the latency between when the alert is scheduled and when it runs, so the same events are not evaluated twice.
“specify alert timestamps using SCHEDULED_TIME and LAST_SUCCESSFUL_SCHEDULED_TIME instead of using CURRENT_TIMESTAMP.”Source: docs.snowflake.com
3.Event-table telemetry and external observability tools
Account Usage views cover SQL activity. Code that runs inside Snowflake, such as functions, procedures and Snowpark code, can also produce telemetry: log messages, trace events, and CPU and memory metrics. Snowflake stores this telemetry in an event table, using a structure based on OpenTelemetry. This event-table telemetry is the observability layer the exam guide groups under Snowflake Trail. The sources here describe the event-table mechanics but do not define Snowflake Trail as a separate product.
Checkpoint 4 of 5· Put it in order
Put the high-level steps for capturing and using log and trace data in order
- 1.Query the event table to analyze collected log and trace data
- 2.Begin emitting log or trace data from handler code
- 3.Ensure that you have an active event table
- 4.Set telemetry levels so that data is collected
Telemetry needs somewhere to go and a level that allows it to be collected before any emitted data shows up for querying.
“Snowflake collects telemetry data from your code in the event table.”Source: docs.snowflake.com
Because the event table follows OpenTelemetry, existing monitoring tools can often consume it with little extra work. There are two integration models. If the tool can read from external sources (pull), point it at the event table. If the tool expects data to be sent to it (push), write a stored procedure with external access that regularly reads the event table and sends the records to the tool. Snowflake lists integrations for Datadog, Grafana and Observe. For a batch option, COPY INTO an external stage exports event records to cloud storage, where downstream tools can pick them up.
Use event tables and alerts for different jobs. Telemetry is collected now and analyzed later. Alerts and notifications are for situations that need an immediate response.
Checkpoint 5 of 5· Check yourself
Your SIEM only accepts data pushed to its API, and you want it to receive Snowflake event-table telemetry. Which approach matches Snowflake guidance?
Tools that need data pushed to them are served by a stored procedure with external access. Pointing the tool at the event table only works for tools that pull.
“consider using a stored procedure with external access to regularly read telemetry data from the event table and emit it to your tool.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Filtering an alert condition on CURRENT_TIMESTAMP is the safe way to catch new events.Why is that wrong?
Because of the delay between an alert's schedule and its execution, Snowflake recommends SCHEDULED_TIME and LAST_SUCCESSFUL_SCHEDULED_TIME to avoid evaluating the same events twice.
Covered in Custom security alerts and notifications
2.CIS Benchmarks and Threat Intelligence scanners run automatically on every account.Why is that wrong?
Every scanner package except Security Essentials is off until you enable it.
Covered in Trust Center: scanners, findings and notifications
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“You have an account-level network policy that allows access only from trusted IP addresses.”
↩︎ Trust Center: scanners, findings and notifications“This scanner package only scans human users;”
↩︎ Trust Center: scanners, findings and notifications“Scanner packages are deactivated by default, except for the Security Essentials scanner package.”
↩︎ Exam trap 2“Scanner packages are deactivated by default, except for the Security Essentials scanner package.”
↩︎ Prediction - 2.
“configure the Trust Center to send email notifications when its scanners generate findings.”
↩︎ Trust Center: scanners, findings and notifications“You can also specify the severity of the findings for which email notifications are sent.”
↩︎ Checkpoint - 3.
“If the statement returns one or more rows, the action for the alert is executed.”
↩︎ Custom security alerts and notifications“To send a notification, you can call the SYSTEM$SEND_EMAIL or SYSTEM$SEND_SNOWFLAKE_NOTIFICATION stored procedure.”
↩︎ Custom security alerts and notifications - 4.
“Snowflake supports sending notifications to email, cloud service provider queues, Slack, PagerDuty, and Microsoft Teams.”
↩︎ Custom security alerts and notifications“You can specify that an alert action runs a task or logs a new row to a table whenever an alert condition is met.”
↩︎ Custom security alerts and notifications“Pass the query ID to RESULT_SCAN to obtain the query results.”
↩︎ Custom security alerts and notifications“If your observability tools can read from external sources, point them to the event table.”
↩︎ Event-table telemetry and external observability tools“Unlike telemetry data, which you collect and analyze later, alerts and notifications are useful when you want an immediate response”
↩︎ Event-table telemetry and external observability tools“specify alert timestamps using SCHEDULED_TIME and LAST_SUCCESSFUL_SCHEDULED_TIME instead of using CURRENT_TIMESTAMP.”
↩︎ Exam trap 1“specify alert timestamps using SCHEDULED_TIME and LAST_SUCCESSFUL_SCHEDULED_TIME instead of using CURRENT_TIMESTAMP.”
↩︎ Checkpoint“consider using a stored procedure with external access to regularly read telemetry data from the event table and emit it to your tool.”
↩︎ Checkpoint - 5.
“Snowflake captures observability data in a structure based on the OpenTelemetry standard.”
↩︎ Event-table telemetry and external observability tools“Snowflake collects telemetry data from your code in the event table.”
↩︎ Checkpoint - 6.https://docs.snowflake.com/en/developer-guide/native-apps/native-apps-third-party-observabilityOfficial docs
“Using COPY INTO with an external stage to batch-export event records to cloud storage (S3, Azure Blob, GCS)”
↩︎ Event-table telemetry and external observability tools