DAA-C01 Question 62
Single answerUse logging and monitoring solutionsA data analyst team owns several dashboards that query Snowflake throughout the day. Business users report that one dashboard intermittently becomes slow between 9:00 AM and 10:00 AM, but only on weekdays. The team wants to identify whether the slowdown is caused by warehouse queuing, long-running queries, or changes in workload patterns, and they want a solution that can be used repeatedly without manually inspecting the UI each day. Which approach would BEST meet this requirement?
- A
Create a monitoring query against ACCOUNT_USAGE.QUERY_HISTORY and ACCOUNT_USAGE.WAREHOUSE_LOAD_HISTORY for the affected time window, then use Snowsight dashboards or alerts on top of those results to track queueing and query-duration trends over time.
- B
Query INFORMATION_SCHEMA.COLUMNS for the dashboard tables every morning and compare the number of columns returned to detect whether schema changes are causing warehouse contention.
- C
Use SYSTEM$CLUSTERING_INFORMATION on the largest dashboard table during the slowdown window, because clustering depth directly reports warehouse queue time and concurrent query pressure.
- D
Review only the warehouse size setting and increase it permanently, because Snowflake does not provide historical views for queueing or query execution patterns.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake's historical usage and monitoring metadata to build a repeatable diagnostic process. For this scenario, ACCOUNT_USAGE.QUERY_HISTORY is appropriate for understanding query-level behavior, including execution duration, timing, and patterns across users and applications. ACCOUNT_USAGE.WAREHOUSE_LOAD_HISTORY is appropriate for identifying queued load and warehouse pressure during the reported time window. Together, these views let the team determine whether the issue is caused by queuing, expensive queries, or a recurring surge in concurrent workload. This approach aligns with Snowflake best practices for operational monitoring: use historical account usage views for trend analysis, and surface the findings through Snowsight dashboards or alerting so the investigation is repeatable and not dependent on manual UI review. Relevant Snowflake documentation includes the ACCOUNT_USAGE views, particularly QUERY_HISTORY and WAREHOUSE_LOAD_HISTORY, along with Snowsight monitoring capabilities for warehouses and query activity.
- A. Correct.
Correct. ACCOUNT_USAGE views such as QUERY_HISTORY and WAREHOUSE_LOAD_HISTORY are designed for historical monitoring and trend analysis. QUERY_HISTORY helps identify long-running queries, execution times, and users/workloads involved. WAREHOUSE_LOAD_HISTORY helps analyze warehouse load, including queued load and concurrency behavior over time. Using these views as the basis for a repeatable monitoring query, then surfacing the results in Snowsight dashboards or through alerting, is the most practical way to distinguish queuing from inefficient queries and recurring workload spikes.
- B. Incorrect.
Incorrect. INFORMATION_SCHEMA.COLUMNS returns metadata about table columns, not operational telemetry about query latency, warehouse queuing, or workload behavior. A candidate might choose this if they suspect schema drift, but schema metadata does not help diagnose intermittent performance issues tied to a specific time window.
- C. Incorrect.
Incorrect. SYSTEM$CLUSTERING_INFORMATION is used to evaluate clustering characteristics of a table, such as clustering depth and partition overlap. It does not report warehouse queue time, concurrency, or workload pressure. This distractor reflects the misconception that all performance problems are best diagnosed through table design rather than usage and load history.
- D. Incorrect.
Incorrect. Increasing warehouse size can be a valid remediation in some cases, but it should come after analysis, not instead of monitoring. Snowflake does provide historical monitoring data through ACCOUNT_USAGE and other usage views, as well as monitoring capabilities in Snowsight. This option is wrong because it ignores the requirement for repeatable root-cause analysis and incorrectly claims the historical data does not exist.