ADA-C01 Question 367
Single answerConsider the use of default system event tables compared to custom tablesA Snowflake administrator is enabling observability for several production applications that use Snowflake event ingestion. Security requires the event data to remain in Snowflake-managed system structures when possible, while the platform team wants the least administrative overhead for collecting standard telemetry. However, one application team also wants to store additional business-specific diagnostic fields that are not part of Snowflake's standard event schema. Which approach best satisfies these requirements?
- A
Use the default system event table for standard telemetry collection, and create a separate custom table for any application-specific diagnostic data that does not fit the standard event schema.
- B
Replace the default system event table with a custom event table so both standard telemetry and application-specific fields can be stored together in one table.
- C
Use only custom tables because default system event tables cannot store telemetry from production applications.
- D
Use the default system event table and add extra custom columns to it for the application-specific diagnostic fields.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use the default system event table for standard telemetry and a separate custom table for additional non-standard diagnostic data. This reflects Snowflake best practice: use the managed default event table when you want low-overhead ingestion and storage of standard event data, and use custom tables only when you have specialized requirements that the standard event schema does not address. Administrators should distinguish between managed system structures that simplify observability operations and user-managed custom tables that provide schema flexibility at the cost of additional administration. This question tests whether the candidate can choose the right storage design based on operational overhead, governance, and schema requirements.
- A. Correct.
Correct. The default system event table is intended to simplify collection of standard telemetry with minimal administration, which aligns with the requirement to keep data in Snowflake-managed system structures where possible. When an application needs to capture additional business-specific diagnostic attributes that are outside the standard event format, a separate custom table is the appropriate design. This preserves the managed benefits of the default event table while allowing flexible storage for non-standard data.
- B. Incorrect.
Incorrect. A common misconception is that a custom table can simply replace the default system event table for all observability use cases. In practice, the default system event table exists specifically to support standard telemetry collection with reduced setup and administration. Moving everything into a custom table increases management overhead and loses the advantage of using the managed default structure. It also does not match the stated security preference to use Snowflake-managed system structures when possible.
- C. Incorrect.
Incorrect. This overstates the limitation of default system event tables. They are specifically designed for Snowflake event data and standard telemetry scenarios, including production use cases. Choosing only custom tables would add unnecessary operational burden and would not satisfy the requirement for least administrative overhead.
- D. Incorrect.
Incorrect. The default system event table is not intended to be altered by adding arbitrary custom business columns for non-standard application fields. Another common mistake is to assume it behaves like a user-managed table that can be extended for any schema need. If teams need to capture additional application-specific fields beyond the standard event schema, they should use a separate custom table rather than modifying the default system event table.