SnowPro Advanced: Security Engineer Question 259
Single answerIntegrate external monitoring and observability tools with SnowflakeA security engineering team must send Snowflake security-relevant events, such as login history and access-related activity, to an external SIEM platform for centralized monitoring and alerting. The team wants a solution that minimizes custom code, supports near-real-time observability, and follows Snowflake-supported integration patterns. Which approach should the team implement?
- A
Create an EVENT TABLE, configure telemetry/event ingestion in Snowflake, and have the external monitoring tool read from the event data through a supported integration pattern.
- B
Enable OBJECT_TAGGING on all security-sensitive objects so Snowflake automatically streams all access events to the external SIEM without additional configuration.
- C
Use database replication to replicate the ACCOUNT_USAGE schema into the SIEM environment, because replication is the supported mechanism for near-real-time external observability.
- D
Schedule periodic exports from ACCOUNT_USAGE and INFORMATION_SCHEMA views to external storage, then ingest those files into the SIEM.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake's supported telemetry and event collection capabilities, centered on event tables, for integration with external monitoring and observability tools. For a Security Engineer, the key requirement is not just extracting data, but doing so in a way that is supportable, timely, and operationally efficient. ACCOUNT_USAGE and INFORMATION_SCHEMA remain useful for investigations, auditing, and periodic reporting, but they are not the strongest fit when the requirement is near-real-time external monitoring with minimal custom engineering. Database replication and tagging features address entirely different use cases and do not provide SIEM-ready event integration. Candidates should recognize the distinction between governance metadata, replicated database objects, delayed account usage views, and Snowflake observability/event-table capabilities documented in Snowflake guidance for logging, tracing, metrics, and event tables.
- A. Correct.
Correct. Snowflake supports observability and telemetry collection through event tables, which are designed to store telemetry/event data generated in Snowflake. For external monitoring and observability integrations, using Snowflake-supported telemetry/event capabilities is the most appropriate approach when the goal is to minimize custom code and support near-real-time monitoring. This aligns with supported patterns for external observability tooling rather than relying only on delayed account views or custom export pipelines.
- B. Incorrect.
Incorrect. Object tags are useful for classification, governance, and policy-driven controls, but tagging objects does not automatically export login, query, or access events to an external SIEM. This option reflects a common misconception that governance metadata features also provide event streaming capabilities.
- C. Incorrect.
Incorrect. Database replication is intended for replicating Snowflake databases across regions or accounts for availability and disaster recovery use cases. ACCOUNT_USAGE is a shared system schema and is not replicated to external SIEM platforms through database replication. In addition, replication is not the recommended mechanism for external security observability.
- D. Incorrect.
Incorrect. Exporting data from ACCOUNT_USAGE and INFORMATION_SCHEMA can be used for reporting or batch-oriented monitoring, but it generally introduces latency and operational overhead. It does not best satisfy the requirement to minimize custom code and provide near-real-time observability. ACCOUNT_USAGE views also have known latency, making this a less suitable choice for timely alerting.