ARA-C01 Question 434
Single answerEvent tables (for example, logging, tracing)A Snowflake architect is designing observability for a business-critical data pipeline implemented with Snowflake Tasks and stored procedures. The operations team wants to capture application logs and trace data generated by handler code, keep the data queryable in Snowflake for troubleshooting, and avoid mixing telemetry with business tables. The team also wants a design that can be centrally governed and retained according to platform policies. Which approach should the architect recommend?
- A
Create a dedicated event table for the environment and configure telemetry collection so logs and trace events are stored there, then grant the operations team access to query it.
- B
Enable QUERY_HISTORY and TASK_HISTORY views only, because they automatically store all application log messages and span-level trace details generated by handler code.
- C
Create a standard relational table with VARIANT columns and insert log and trace records from each procedure manually, because Snowflake does not provide native storage for telemetry data.
- D
Store observability data in a temporary table per session, because event data is intended only for short-lived debugging and cannot be governed centrally.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use a dedicated Snowflake event table. Event tables are the Snowflake-native storage objects for telemetry data, including logging and tracing, and they are intended for observability use cases. This is the most appropriate architectural recommendation when a team needs durable, queryable telemetry separated from core business data and managed with centralized access and retention practices. History views such as QUERY_HISTORY and TASK_HISTORY remain valuable for execution monitoring, but they do not serve as a full replacement for event-table-based telemetry collection. Likewise, building a custom logging table introduces unnecessary implementation complexity and misses the native observability design. Snowflake documentation for event tables and telemetry describes event tables as the storage mechanism for logs, traces, and metrics and positions them as the recommended approach for Snowflake observability.
- A. Correct.
Correct. Snowflake event tables are the native mechanism for storing telemetry data such as logs, trace events, and metrics produced by supported Snowflake features. Using a dedicated event table aligns with the requirement to keep observability data separate from business tables, makes the telemetry queryable in Snowflake, and supports centralized governance and retention controls at the platform level.
- B. Incorrect.
Incorrect. ACCOUNT_USAGE and related history views such as QUERY_HISTORY or TASK_HISTORY are useful for operational monitoring, but they do not replace event tables for application-level telemetry. They do not automatically capture all handler-generated log messages and detailed tracing spans in the same way event tables are designed to store telemetry data.
- C. Incorrect.
Incorrect. While manually writing logs to a custom table is technically possible in some designs, it is not the recommended native approach when the requirement is to capture Snowflake telemetry for logging and tracing. Event tables exist specifically for this purpose and provide a governed, queryable destination without forcing each application component to implement custom persistence logic.
- D. Incorrect.
Incorrect. Temporary tables are session-scoped and unsuitable for centralized observability. They do not meet requirements for shared access, policy-based retention, or durable troubleshooting across sessions and teams. Event tables are intended to provide persistent telemetry storage that can be governed and queried over time.