ADA-C01 Question 370
Single answerSet levels for logs, metrics and tracingA Snowflake administrator is helping a development team troubleshoot a Python stored procedure that intermittently fails in production. The team wants to capture enough telemetry to diagnose the issue, but they also want to avoid unnecessary telemetry volume for other objects in the same schema. What is the BEST approach to increase observability only for this stored procedure while troubleshooting?
- A
Set the log level, metric level, and trace level on the specific stored procedure so telemetry is collected at the object level only during investigation.
- B
Set the account-wide telemetry level to the most verbose setting so all handlers in the account produce comparable diagnostic data.
- C
Enable QUERY_TAG for sessions that call the stored procedure, because QUERY_TAG controls the verbosity of logs, metrics, and traces emitted by handler code.
- D
Increase the warehouse size for the workload, because larger warehouses automatically capture more detailed logs, metrics, and traces for stored procedures.
Show answer and explanation
Correct answer: A
Explanation
The best practice is to set telemetry levels at the lowest scope that satisfies the troubleshooting need. For handler-based observability in Snowflake, administrators can configure levels for logs, metrics, and tracing so that telemetry collection is more targeted. In a production troubleshooting scenario, object-level configuration on the specific stored procedure is preferable to account-level changes because it reduces noise, cost, and operational risk. This reflects Snowflake guidance around event table-based telemetry for handler code: use configurable log, metric, and trace levels and scope them appropriately to the affected object, session, user, or broader level only when necessary.
- A. Correct.
Correct. Snowflake allows telemetry levels for logs, metrics, and tracing to be configured with object-level granularity for supported handler-based objects such as stored procedures and UDFs. In this scenario, setting the levels on the specific stored procedure is the best choice because it limits extra telemetry to the object being investigated rather than affecting unrelated workloads. This aligns with the practical goal of targeted troubleshooting while controlling telemetry volume.
- B. Incorrect.
Incorrect. Raising telemetry levels account-wide is overly broad for this use case. Although broader scopes can be used, doing so would increase telemetry generation for many workloads unrelated to the failing procedure, which conflicts with the requirement to minimize unnecessary telemetry volume. This is a common operational mistake when administrators choose the widest scope instead of the narrowest effective scope.
- C. Incorrect.
Incorrect. QUERY_TAG is useful for labeling and later identifying queries, but it does not set the verbosity levels for logs, metrics, or traces generated by handler code. Someone might choose this option because QUERY_TAG helps correlate activity, but correlation metadata is different from telemetry level configuration.
- D. Incorrect.
Incorrect. Warehouse size affects compute capacity and performance characteristics, not the configured telemetry verbosity for logs, metrics, or tracing. A larger warehouse might help with resource-related performance issues, but it does not automatically increase diagnostic detail emitted by stored procedures.