ADA-C01 Question 310
Single answerArticulate the execution pathA Snowflake administrator is investigating a query that is intermittently slow in production. The same SQL text is submitted through a BI tool by many users, and the administrator needs to explain the query's execution path to determine whether the slowdown is caused by data scanning, expensive joins, or result materialization. Which Snowflake interface should the administrator use first to inspect the operator-level execution path for an individual query run?
- A
Open the query in Query Profile from the query history and review the execution graph and operator statistics
- B
Run DESCRIBE WAREHOUSE on the virtual warehouse used by the query to view each execution step
- C
Query the ACCOUNT_USAGE.QUERY_HISTORY view because it contains the full physical execution plan for every operator
- D
Review the Access History for the query because it shows the join order, pruning effectiveness, and spill metrics
Show answer and explanation
Correct answer: A
Explanation
To articulate the execution path of a Snowflake query, the administrator should begin with Query Profile in Snowsight or the classic query history interface. Query Profile is specifically intended to visualize how a query was executed, including operator nodes and timing, and is the standard tool for identifying bottlenecks such as large scans, expensive joins, repartitioning, spilling, or result processing. In contrast, QUERY_HISTORY and related ACCOUNT_USAGE views are valuable for historical and aggregate performance monitoring but do not replace Query Profile for operator-level diagnostics. Access History serves governance and lineage use cases, not detailed execution analysis. This aligns with Snowflake documentation and best practices for query troubleshooting, where Query Profile is the recommended mechanism for understanding execution details for an individual query.
- A. Correct.
Correct. Query Profile is the primary Snowflake interface for understanding a specific query's execution path. It exposes the execution graph and operator-level details such as scans, joins, aggregations, exchanges, spillage, and timing distribution. This is the right first step when the goal is to articulate where time was spent and whether the bottleneck came from scanning, join processing, or result construction.
- B. Incorrect.
Incorrect. DESCRIBE WAREHOUSE returns metadata and configuration details about the virtual warehouse, such as size and state, but it does not show the execution path of an individual query. A common misconception is that warehouse-level metadata includes per-query execution steps; in Snowflake, operator-level query analysis is done through Query Profile.
- C. Incorrect.
Incorrect. ACCOUNT_USAGE.QUERY_HISTORY is useful for high-level query metadata such as execution status, elapsed time, bytes scanned, rows produced, and warehouse used. However, it does not provide the full operator-by-operator physical execution graph needed to articulate the detailed execution path. Candidates may choose this because QUERY_HISTORY is often used for performance analysis, but it is not the best tool for operator-level plan inspection.
- D. Incorrect.
Incorrect. Access History is designed primarily for governance, lineage, and auditing of object access. It can help identify which objects were touched by a query, but it does not provide the detailed execution path, join order visualization, pruning metrics, or spill analysis required for execution troubleshooting. This option reflects a confusion between governance metadata and performance diagnostics.