ADA-C01 Question 379
Single answerUse log trace data to optimize performanceA Snowflake administrator is investigating intermittent latency in a business-critical dashboard. The dashboard issues the same parameterized SQL statement hundreds of times per hour from a custom application. Query History shows that elapsed time varies widely even when the warehouse size, data volume, and query plan are unchanged. The engineering team has recently instrumented the application with Snowflake log and trace telemetry. Which action should the administrator take to use trace data most effectively to identify and reduce the performance issue?
- A
Correlate the application trace spans with Snowflake query IDs to determine whether the delay is occurring before query submission, during query execution, or after results are returned, then optimize the slow segment that the trace identifies.
- B
Increase the statement timeout so the dashboard queries have more time to complete, because trace data is primarily useful for identifying queries that are canceled before they finish.
- C
Disable result caching for the dashboard workload so every execution produces a fresh trace, making latency measurements more accurate for root-cause analysis.
- D
Resize the virtual warehouse to the next larger size, because trace data cannot distinguish client-side latency from server-side execution time.
- E
Use only QUERY_HISTORY execution metrics and ignore trace telemetry, because Snowflake traces do not provide value once the SQL text and execution plan are known.
Show answer and explanation
Correct answer: A
Explanation
For performance troubleshooting, Snowflake query metadata such as QUERY_HISTORY helps explain what happened inside Snowflake, while log and trace telemetry helps explain the end-to-end path around the query. In real-world systems, user-perceived latency can come from connection acquisition, application retries, network delays, result deserialization, or downstream processing even when SQL execution itself is stable. The best practice is to correlate telemetry across layers using identifiers such as query IDs and trace spans, then optimize the component where time is actually being spent. This approach aligns with Snowflake observability guidance: use logs, metrics, and traces together rather than relying only on SQL text or warehouse sizing. Trace data is most useful when it helps isolate whether the bottleneck is in query execution or in surrounding application behavior.
- A. Correct.
Correct. The key value of trace telemetry in this scenario is end-to-end visibility across application steps and database calls. By correlating trace spans with Snowflake query IDs, an administrator can separate client-side delays such as connection management, retries, serialization, or result processing from actual Snowflake execution time. If the trace shows the SQL execution span is stable but total request latency is high, the issue may be outside the warehouse. If the trace shows the execution span itself is the bottleneck, the administrator can then focus on warehouse behavior, queuing, pruning, or SQL tuning. This is the most effective performance-optimization use of trace data.
- B. Incorrect.
Incorrect. Increasing statement timeout does not diagnose the source of intermittent latency and is not the primary purpose of trace telemetry. In the scenario, queries are completing, but total response time varies. A higher timeout may hide symptoms without addressing the root cause.
- C. Incorrect.
Incorrect. Disabling result caching is not the right first step and may worsen performance. Trace data can still be used to compare stages of request processing regardless of whether cached results are returned. If caching is relevant, traces and query metadata can help identify that naturally; turning cache off globally for diagnosis is not a best practice for a production dashboard unless there is a specific test need.
- D. Incorrect.
Incorrect. Resizing the warehouse may help only if the delay is caused by compute pressure or queuing, but the scenario states that warehouse size, data volume, and query plan are unchanged while latency is intermittent. Trace data is specifically valuable because it can help distinguish where time is spent across the full request path, including client and application processing.
- E. Incorrect.
Incorrect. QUERY_HISTORY is important, but it shows database-side query metrics, not the complete request lifecycle in the application. When elapsed time seen by users differs from database execution time, trace telemetry provides the missing context. Ignoring traces would miss the central diagnostic tool described in the scenario.