ADA-C01 Question 365
Select 2Manage event tablesA Snowflake administrator enabled unhandled exception logging for several stored procedures and now needs a centralized way to retain and query telemetry data for troubleshooting. The security team requires that application developers be able to write telemetry data, while only the platform operations team can query or manage the telemetry store. Which actions should the administrator take to implement this correctly?
- A
Create an event table, set it as the active event table for the account, grant INSERT on the event table to application developer roles, and grant SELECT plus ownership-related management privileges only to the platform operations role.
- B
Create a regular table with the same columns as an event table and configure Snowflake to route telemetry records into it, then grant developers INSERT and operators SELECT.
- C
Use the default active event table if one exists, and rely on role-based access control so that developers can emit telemetry without needing direct read access to the event table.
- D
Create a separate event table in each developer schema because telemetry can only be written to event tables owned by the same schema as the procedure generating the events.
- E
Grant developers SELECT on the event table so their procedures can successfully emit log and trace records, and restrict DELETE and TRUNCATE to the platform operations role.
Show answer and explanation
Correct answers: A, C
Explanation
The key administrative concept is that Snowflake telemetry data is stored in event tables, which are a specialized table type for logs, traces, and metrics-related records. To capture telemetry centrally, an administrator must ensure there is an event table and that it is configured as the active event table at the appropriate scope. If a suitable active event table already exists, it can be reused. Access should then be controlled with RBAC so that developers can generate or write telemetry without being able to read sensitive operational data, while the platform operations team retains query and management privileges. A common misconception is that a normal table can substitute for an event table, or that developers need SELECT on the event table for telemetry generation; neither is true. This aligns with Snowflake best practices for managing event tables and telemetry access separation.
- A. Correct.
Correct. Snowflake telemetry data such as logs, traces, and unhandled exception records is stored in an event table, and an event table must be designated as the active event table at the account, database, or schema scope for telemetry collection. Granting INSERT allows roles to add rows manually if needed, and Snowflake documentation distinguishes between write access and read/management access. Restricting SELECT and ownership-level management to the platform operations role aligns with the requirement that developers can write telemetry while only operations can query or administer the table.
- B. Incorrect.
Incorrect. A regular table cannot act as an event table, and Snowflake does not support configuring telemetry collection to target an arbitrary user-defined table that merely mimics the schema. Event tables are a specific table type designed for Snowflake telemetry data and must be explicitly created and activated.
- C. Correct.
Correct. Snowflake can use an active event table already in place, so creating a new one is not mandatory if an appropriate active event table exists. Telemetry emission does not require developers to have read access to the event table; RBAC can be used so developers generate telemetry while only operations can query it. This matches the security requirement of separating write/emit capability from read/manage capability.
- D. Incorrect.
Incorrect. Telemetry is not limited to an event table in the same schema as the procedure or application object. Snowflake uses the active event table configured at the relevant scope. Creating one event table per developer schema is unnecessary and reflects a misunderstanding of how active event tables are associated and used.
- E. Incorrect.
Incorrect. SELECT is not required for procedures or applications to emit telemetry to an active event table. Granting developers read access would violate the requirement that only the platform operations team can query telemetry data. This option confuses the ability to generate telemetry with the ability to read stored telemetry.