ADA-C01 Question 377
Single answerUse log trace data to perform root cause analysesA Snowflake administrator is investigating an intermittent failure in a Python stored procedure used by a finance application. Users report that the procedure sometimes fails with a generic execution error, but the SQL text and warehouse size appear unchanged. The administrator enabled object-level event table logging for the procedure and now needs to perform root cause analysis using the captured telemetry. Which approach will BEST identify the underlying cause of the failure?
- A
Query the event table for log and trace records generated by the stored procedure execution, correlate entries by time and execution context, and inspect stack traces or exception messages emitted by the handler code.
- B
Review only QUERY_HISTORY for the failed CALL statements, because query history contains the complete application stack trace for Python stored procedures and is sufficient for code-level root cause analysis.
- C
Resize the virtual warehouse and rerun the stored procedure, because intermittent execution errors in Python handlers are most commonly caused by insufficient warehouse memory and do not require telemetry analysis.
- D
Use ACCESS_HISTORY to inspect which tables were referenced by the stored procedure and infer the failure cause from object access patterns, since event tables do not capture handler-level diagnostics.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use the event table telemetry produced by the stored procedure and analyze the log and trace data for the failing execution. In Snowflake, event tables are designed to store observability data, including logs and traces, for supported objects. For root cause analysis, administrators commonly start with QUERY_HISTORY to identify when the failure occurred and then pivot to the event table to inspect more detailed diagnostics such as exception messages, stack traces, and trace spans. This approach aligns with Snowflake observability best practices: use event tables for telemetry-driven troubleshooting rather than relying solely on query metadata or object access history. Relevant Snowflake documentation includes guidance on event tables, logging, tracing, and monitoring Snowflake applications and handlers.
- A. Correct.
Correct. Snowflake event tables are the primary telemetry store for logs, traces, and metrics emitted by supported Snowflake objects such as stored procedures and UDF handlers. For root cause analysis, the administrator should query the event table and correlate telemetry for the failing execution using timestamps and available execution context fields, then inspect exception text, trace spans, and handler-generated log entries. This is the most direct way to diagnose intermittent code-path issues, dependency problems, or data-specific failures that are not obvious from SQL text alone.
- B. Incorrect.
Incorrect. QUERY_HISTORY is useful for identifying the failed CALL statement, execution time, error code, and high-level error message, but it does not replace event-table telemetry for code-level diagnostics. A common misconception is that query history alone provides the same depth as handler logs and traces. In practice, it is often insufficient when the goal is to inspect application exceptions or execution flow inside the Python procedure.
- C. Incorrect.
Incorrect. Increasing warehouse size might help some resource-related performance problems, but it is not the best next step for root cause analysis when telemetry has already been enabled. This option reflects a common operational mistake: attempting remediation before determining the cause. Intermittent failures in Python stored procedures can result from unhandled exceptions, package/import issues, input-dependent logic, or external function behavior, none of which are reliably diagnosed by resizing compute alone.
- D. Incorrect.
Incorrect. ACCESS_HISTORY helps analyze data access and governance-related questions, such as which objects were touched, but it is not intended to expose handler-level stack traces or application logs. This distractor is plausible because administrators often use account usage views during investigations, but object access patterns do not provide the detailed runtime diagnostics needed to isolate a stored procedure's internal exception path.