SnowPro Advanced: Security Engineer Question 337
Single answerConfigure and test security alerting mechanisms within Snowflake and integrated SIEM platformsA security engineering team must generate near-real-time alerts when a Snowflake user is added to a highly privileged role, and the alert must also be visible in the company SIEM. The team wants the design to be testable, use native Snowflake capabilities where possible, and minimize custom polling code. Which approach best meets these requirements?
- A
Create an ALERT in Snowflake that queries ACCOUNT_USAGE.GRANTS_TO_USERS for new grants to the privileged role, and configure the ALERT action to call a notification integration or external function/webhook path that forwards the event to the SIEM. Validate by granting the role to a test user and confirming both the Snowflake alert history and SIEM event.
- B
Create a masking policy on the USERS view to detect role grants, and send the masking policy evaluation result directly to the SIEM whenever the policy is triggered.
- C
Use a network policy to detect when a role grant occurs, because role changes are treated as network events, then forward those events directly to the SIEM.
- D
Configure the SIEM to read QUERY_HISTORY every 24 hours and search only for failed login events, because role grants are included with authentication failures in the same event stream.
Show answer and explanation
Correct answer: A
Explanation
The best answer is the approach that combines Snowflake-native detection and alerting with SIEM integration and a clear test plan. In Snowflake, ALERT objects can run SQL on a schedule and take actions when a condition is met. For security monitoring use cases, teams commonly query metadata sources such as ACCOUNT_USAGE or INFORMATION_SCHEMA where appropriate, then invoke downstream notification or integration mechanisms to send alerts externally. For a privileged-role grant scenario, the engineering team should define the detection logic, trigger an outbound notification path supported by their architecture, and verify the result by generating a known test event and checking both Snowflake alert execution details and SIEM ingestion.
Key best-practice themes relevant to SnowPro Advanced: Security Engineer include:
- Use native Snowflake monitoring and automation capabilities where feasible before building custom pollers.
- Understand the difference between preventive controls like masking and network policies versus detective controls like alerts and audit/metadata analysis.
- Validate end-to-end alerting, including Snowflake-side execution and downstream SIEM visibility.
- Be aware that some account usage views can have latency, so design schedules and expectations accordingly.
Relevant Snowflake documentation areas include ALERTs, notification integrations/external integrations, ACCOUNT_USAGE views for security/audit metadata, and general monitoring/auditing guidance.
- A. Correct.
Correct. A practical pattern is to detect role membership changes from Snowflake metadata/views, then use a native Snowflake ALERT to evaluate on a schedule and trigger downstream notification logic through supported integrations. This aligns with the requirement for native capabilities and reduced custom polling. Testing by performing a controlled role grant and validating alert execution history plus SIEM ingestion is also the right operational approach. While ACCOUNT_USAGE views can have latency and are not strictly event-driven, this is still the closest native alerting pattern in Snowflake for metadata-based detection, especially when paired with a short alert schedule and downstream notification integration.
- B. Incorrect.
Incorrect. Masking policies control data visibility at query time; they do not monitor administrative changes such as role grants and are not an alerting mechanism. A candidate might choose this if they confuse runtime data protection controls with security monitoring controls.
- C. Incorrect.
Incorrect. Network policies restrict client IP access and related network access behavior. They do not detect RBAC changes such as granting a role to a user. This distractor targets the misconception that all security-relevant events are surfaced through network controls.
- D. Incorrect.
Incorrect. QUERY_HISTORY is useful for SQL activity analysis, but checking it only every 24 hours does not meet a near-real-time alerting requirement. In addition, failed login events are not the same as role grants, and role changes are not grouped with authentication failures as described here. This option also violates the requirement to minimize delayed, SIEM-side polling.