ADA-C01 Question 366
Single answerConsider the use of default system event tables compared to custom tablesA Snowflake administrator is implementing observability for a new set of Snowpark applications and wants to collect application log, trace, and metric data with the least ongoing administrative effort. The security team also requires that telemetry data remain in Snowflake-managed storage and be available through the standard event table schema used by platform features. Which approach best meets these requirements?
- A
Enable telemetry collection and use the account's default system event table so Snowflake writes supported telemetry data into the standard event table automatically.
- B
Create a custom table with columns for logs, traces, and metrics, then configure Snowpark to insert telemetry records directly into that table for maximum compatibility with system features.
- C
Create an external table over cloud storage files exported from Snowpark runtimes, because event tables are intended only for query history and not application telemetry.
- D
Use a temporary table in each application schema and periodically merge the data into ACCOUNT_USAGE views, since default event tables cannot retain telemetry data long term.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use the default system event table when the goal is to collect supported telemetry with minimal operational overhead and to stay aligned with Snowflake's native observability model. Event tables are specialized objects designed to store observability data, including logs, traces, and metrics, in a standard schema. Compared to building custom tables, the default system event table reduces design and maintenance work and is the appropriate choice when no specialized custom retention, schema, or isolation requirement justifies a separate event table strategy. Snowflake documentation on event tables and telemetry/observability emphasizes that event tables are the native mechanism for collecting this data and that the default system event table provides a built-in destination. Custom user tables are not equivalent substitutes for event tables, and external or temporary table approaches do not satisfy the stated requirements.
- A. Correct.
Correct. Snowflake supports event tables for observability data such as logs, traces, and metrics. Using the default system event table aligns with the requirement for minimal administration because Snowflake can write supported telemetry data into the standard event table schema without the team designing and maintaining a custom ingestion structure. It also satisfies the requirement to keep the data in Snowflake-managed storage and use the native event table format expected by Snowflake observability capabilities.
- B. Incorrect.
Incorrect. A custom table increases administrative effort because the team must define schema, ingestion logic, and operational processes. More importantly, a generic custom table does not provide the same native event table behavior or standard schema expected for Snowflake observability features. This option reflects the common misconception that any user table can substitute for an event table simply by storing similar columns.
- C. Incorrect.
Incorrect. External tables over cloud storage do not meet the requirement for Snowflake-managed storage, and event tables are specifically designed for telemetry such as logs, traces, and metrics. This distractor is based on the misconception that event tables are limited to query metadata or internal history data only.
- D. Incorrect.
Incorrect. Temporary tables are not appropriate for durable observability data because they are session-scoped or transient by design and add operational complexity. In addition, telemetry data is not handled by merging temporary-table contents into ACCOUNT_USAGE views; ACCOUNT_USAGE views expose Snowflake metadata and usage information, not a customer-managed destination for application telemetry.