SnowPro Advanced: Security Engineer Question 336
Single answerConfigure and test security alerting mechanisms within Snowflake and integrated SIEM platformsA security engineer needs to implement and validate alerting for potentially unauthorized access attempts in Snowflake. The company already forwards Snowflake account activity to a SIEM by querying ACCOUNT_USAGE views on a schedule. The requirement is to detect repeated failed login attempts as quickly as possible, generate a Snowflake-native alert, and ensure the SIEM pipeline can be tested end to end without waiting for a real attack. Which approach best meets these requirements?
- A
Create a Snowflake ALERT object that queries the LOGIN_HISTORY table function or ACCOUNT_USAGE.LOGIN_HISTORY for recent failed authentications, configure it to call a notification integration or trigger downstream action, and validate the SIEM path by generating controlled failed login events with a test user.
- B
Create a masking policy on the USERS view to hide service account names, then configure the SIEM to infer failed login attempts from query history anomalies and test by suspending a warehouse.
- C
Use a network policy alone to block unapproved IP addresses; because blocked connections are prevented, Snowflake will automatically send alerts to the SIEM without additional configuration or testing.
- D
Create a resource monitor to detect spikes in authentication failures, then test the integration by running large queries until the monitor threshold is exceeded.
Show answer and explanation
Correct answer: A
Explanation
The best answer is the one that combines timely detection, Snowflake-native alerting, and realistic end-to-end validation. In Snowflake, authentication-related events are available through login history sources, and ALERT objects can be used to evaluate conditions on a schedule and execute actions when a threshold is met, such as repeated failed login attempts within a recent time window. In environments integrated with a SIEM, a best practice is to validate the full path using controlled, non-production test events, for example by using a designated test user to generate intentional failed authentication attempts and confirming the events appear in Snowflake monitoring and the SIEM. This is more reliable than waiting for organic malicious activity. Relevant Snowflake documentation areas include ALERT objects, notification integrations and related action mechanisms, LOGIN_HISTORY/ACCOUNT_USAGE telemetry, and security monitoring best practices.
- A. Correct.
Correct. This approach aligns with Snowflake capabilities and the scenario requirements. Snowflake supports ALERT objects to run SQL on a schedule and take action when conditions are met. Failed login events can be detected from login history sources, and a notification or downstream action can be invoked through supported integrations and procedures. Generating intentional failed logins with a designated test user is an appropriate way to validate both the Snowflake-side detection and the SIEM ingestion pipeline without waiting for a real incident. This is practical because it tests the actual telemetry path rather than assuming delivery.
- B. Incorrect.
Incorrect. Masking policies are for protecting sensitive data at query time, not for detecting authentication failures or generating security alerts. The USERS view is also not the right telemetry source for failed logins. Inferring authentication issues from query history is a misconception because failed logins may never produce query activity. Suspending a warehouse tests compute controls, not authentication alerting.
- C. Incorrect.
Incorrect. Network policies can help restrict access by IP, but they do not by themselves provide a complete alerting workflow or automatically notify an external SIEM. Organizations still need a mechanism to detect relevant events from Snowflake metadata or logs and send them to the SIEM. The idea that blocking access automatically produces SIEM alerts without explicit configuration is the key misconception.
- D. Incorrect.
Incorrect. Resource monitors track credit consumption and can trigger actions related to warehouse spending thresholds. They are unrelated to authentication telemetry such as failed logins. Running large queries would test warehouse consumption behavior, not security alerting for access attempts.