ADA-C01 Question 368
Single answerConfigure event tablesA Snowflake administrator is enabling observability for a new production environment that uses stored procedures, tasks, and Snowpark applications. The security team requires that log, trace, and metric data be captured centrally in one object, while application teams must be able to query the telemetry with standard SQL for troubleshooting. The administrator also wants to avoid creating custom ingestion pipelines. Which configuration best meets these requirements?
- A
Create an event table, set it as the active event table for the account, and grant application teams appropriate privileges to query it.
- B
Create a temporary table and configure tasks to copy telemetry from QUERY_HISTORY and TASK_HISTORY into it every 5 minutes.
- C
Create an external table over cloud storage logs and use Snowpipe to continuously ingest trace and metric files generated by Snowpark applications.
- D
Create a stream on ACCOUNT_USAGE views and expose it to developers so they can query all logs, traces, and metrics directly from the stream.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to configure an event table and make it the active event table for the account. Event tables are specifically intended for Snowflake observability data, including logs, traces, and metrics, and they are queryable with SQL. This directly satisfies the requirements for centralized capture, SQL-based troubleshooting, and no custom ingestion pipeline. In practice, administrators create the event table, activate it at the appropriate scope, and then grant access so operations or application teams can query it securely. By contrast, ACCOUNT_USAGE views, temporary tables, streams, external tables, and Snowpipe are not the native mechanism for configuring Snowflake telemetry collection into a central observability store. This aligns with Snowflake documentation for event tables and logging, tracing, and metrics collection in Snowflake observability.
- A. Correct.
Correct. Event tables are the Snowflake object designed to store telemetry data generated by Snowflake components and instrumented code, including logs, traces, and metrics. An administrator can create an event table and designate it as the active event table so supported telemetry is collected centrally without building a custom ingestion pipeline. Because an event table is a table-like object that can be queried with SQL, application teams can use standard SQL for troubleshooting once they have the necessary privileges.
- B. Incorrect.
Incorrect. QUERY_HISTORY and TASK_HISTORY provide useful operational metadata, but they are not a substitute for centralized telemetry collection in an event table. A temporary table is also session-scoped and unsuitable for production observability retention and shared access. This approach adds unnecessary custom pipeline complexity and still would not capture the full telemetry model of logs, traces, and metrics expected from event tables.
- C. Incorrect.
Incorrect. External tables over cloud storage are used for querying files in staged or external locations, not for natively capturing Snowflake telemetry. Snowpipe can ingest files, but Snowflake event tables are intended to receive telemetry directly from supported Snowflake observability features. This option introduces a custom file-based architecture that the scenario explicitly wants to avoid.
- D. Incorrect.
Incorrect. ACCOUNT_USAGE views expose account metadata and history, but they are not event tables and do not provide a complete, unified storage target for logs, traces, and metrics. A stream on ACCOUNT_USAGE also would not transform those views into a telemetry repository. This distractor reflects the common misconception that historical usage views are interchangeable with observability telemetry storage.