ADA-C01 Question 369
Single answerConfigure event tablesA Snowflake administrator needs to centralize observability data for a production environment. The company wants Snowflake-generated telemetry such as logs, trace events, and metrics from supported handlers to be stored in a dedicated table in an ADMIN database instead of using the default event table. The solution must ensure newly emitted events are written to the centralized location with minimal ongoing maintenance. Which action should the administrator take?
- A
Create an event table in ADMIN.OBSERVABILITY and set it as the active event table at the account level.
- B
Create a regular table in ADMIN.OBSERVABILITY and grant INSERT on it to the SNOWFLAKE system service.
- C
Create an event table in ADMIN.OBSERVABILITY and configure each warehouse to use that event table for telemetry output.
- D
Create a stream on the default event table and use a task to copy all new rows into a standard table in ADMIN.OBSERVABILITY.
Show answer and explanation
Correct answer: A
Explanation
The best solution is to create a Snowflake event table and designate it as the active event table at the account level so that new telemetry is written there automatically. Event tables are a specific Snowflake object type used for observability data, including logs, traces, and metrics generated by supported Snowflake components and handlers. A common misconception is that any table can store this data if permissions are granted, but Snowflake requires an actual event table. Another common mistake is assuming telemetry routing is configured at the warehouse level; it is not. Using streams and tasks to copy from the default event table can support downstream ETL or retention workflows, but it does not replace proper event table configuration. This aligns with Snowflake documentation and best practices for configuring and centralizing observability data using active event tables.
- A. Correct.
Correct. Snowflake event tables are special table objects designed to store telemetry data collected by Snowflake Observability features. To centralize future telemetry, the administrator should create an event table in the desired database/schema and set it as the active event table for the account. Once configured, newly emitted logs, trace events, and metrics supported by Snowflake Observability are written to that active event table.
- B. Incorrect.
Incorrect. A regular table cannot function as an event table. Snowflake telemetry requires an event table object, not a standard relational table, and there is no supported pattern where administrators grant a system service INSERT privileges to a normal table to receive observability events.
- C. Incorrect.
Incorrect. Event tables are not configured per warehouse for telemetry routing. Warehouses are compute resources and do not independently define the destination event table for Snowflake Observability data. The active event table is configured at a broader scope, such as the account, to collect emitted events centrally.
- D. Incorrect.
Incorrect. While a stream and task could be used as a downstream processing pattern, this does not change where telemetry is initially written. The requirement is to have newly emitted events stored directly in a dedicated centralized event table instead of relying on the default event table. Copying from the default table adds ongoing maintenance and does not satisfy the direct-write requirement.