SnowPro Advanced: Security Engineer Question 258
Single answerIntegrate external monitoring and observability tools with SnowflakeA security engineering team must send Snowflake security and access events to an external SIEM for near-real-time monitoring. The team wants a solution that minimizes custom polling code, preserves event context for downstream analysis, and follows Snowflake-supported integration patterns. Which approach should the team implement?
- A
Create an ALERT object that directly sends every LOGIN_HISTORY record to the SIEM over HTTPS whenever a user signs in.
- B
Use Snowflake event tables to collect security-relevant telemetry, then configure a supported export/integration path so the external observability platform can consume those events.
- C
Configure Network Policies to stream all session and query events directly to the external SIEM because network rules natively provide outbound event forwarding.
- D
Grant the SIEM service account ACCOUNTADMIN and have it query ACCOUNT_USAGE views continuously every few seconds for new security events.
Show answer and explanation
Correct answer: B
Explanation
For integrating Snowflake with external monitoring and observability tools, the strongest supported approach is to use Snowflake telemetry capabilities centered on event tables and then connect those outputs to downstream monitoring platforms through supported export or ingestion patterns. This avoids brittle, high-frequency custom polling against ACCOUNT_USAGE or INFORMATION_SCHEMA and better preserves structured event context. From a Security Engineer perspective, the solution should also follow least-privilege principles and avoid unnecessary use of powerful roles such as ACCOUNTADMIN. Snowflake documentation on observability and event tables emphasizes using native telemetry collection for logs, metrics, traces, and related operational/security monitoring use cases.
- A. Incorrect.
Incorrect. Snowflake ALERT objects are designed to evaluate conditions and execute SQL or call actions on a schedule, but they are not a general-purpose, direct per-event HTTPS streaming mechanism for every LOGIN_HISTORY row. This option also implies event-driven behavior on each sign-in, which is not how ALERT scheduling works. A candidate might choose this because ALERTS sound operationally convenient, but they do not replace supported observability/event export patterns.
- B. Correct.
Correct. Snowflake supports using event tables for observability data collection, including security-relevant telemetry that can be consumed by downstream tools through supported integration/export patterns. This aligns with the requirement to reduce custom polling and preserve rich event context. For external monitoring and observability, Snowflake-native telemetry collection through event tables is the supported design direction rather than building ad hoc polling against metadata views.
- C. Incorrect.
Incorrect. Network Policies restrict allowed network locations for connecting to Snowflake; they do not act as an outbound event streaming or SIEM forwarding mechanism. This distractor reflects a common misconception that network security controls also provide monitoring export capabilities.
- D. Incorrect.
Incorrect. Continuously polling ACCOUNT_USAGE views with a highly privileged ACCOUNTADMIN service account is not a best-practice observability integration pattern. ACCOUNT_USAGE is useful for analysis and reporting, but it is not the preferred near-real-time, low-maintenance mechanism described in the scenario. Using ACCOUNTADMIN also violates least-privilege principles and increases security risk.