ADA-C01 Question 225
Single answerMonitor multi-cluster warehousesA data engineering team uses a multi-cluster virtual warehouse named ETL_WH to support highly concurrent ELT jobs. The warehouse is configured with MIN_CLUSTER_COUNT = 1, MAX_CLUSTER_COUNT = 4, and AUTO_SUSPEND = 300. Over the past week, developers reported intermittent queueing during peak hours, but the Snowflake account administrator also wants to avoid unnecessary warehouse cost. Which approach would best help the administrator monitor whether ETL_WH is scaling out as expected and whether query queuing is still occurring during busy periods?
- A
Review WAREHOUSE_LOAD_HISTORY for ETL_WH to analyze queued load over time, and compare it with SHOW WAREHOUSES or warehouse metadata to confirm the warehouse is configured for multi-cluster scaling.
- B
Query QUERY_HISTORY only for completed statements and use execution time as the sole indicator of whether additional clusters were started.
- C
Use DATABASE_STORAGE_USAGE_HISTORY to determine when ETL_WH added clusters, because storage growth correlates directly with multi-cluster warehouse expansion.
- D
Inspect LOGIN_HISTORY during peak periods to verify the number of users logged in, because concurrent logins determine whether Snowflake starts new clusters.
Show answer and explanation
Correct answer: A
Explanation
To monitor a multi-cluster warehouse effectively, an administrator should use warehouse-centric monitoring data rather than infer scaling from unrelated metrics. In Snowflake, WAREHOUSE_LOAD_HISTORY is designed to help assess warehouse load and queuing patterns over time, which is especially important when validating whether a multi-cluster warehouse is reducing concurrency bottlenecks. SHOW WAREHOUSES and related warehouse metadata provide the configured properties, such as cluster counts and scaling settings, so the administrator can confirm the warehouse is eligible to scale out. QUERY_HISTORY can be useful as a supplemental source for investigating individual queries and queue times, but it is not the best primary source for evaluating whether the warehouse is scaling as expected. Best practice is to correlate warehouse configuration with warehouse load history to determine if queueing persists and whether tuning MAX_CLUSTER_COUNT, scaling policy, or workload design is necessary.
- A. Correct.
Correct. WAREHOUSE_LOAD_HISTORY is the key Account Usage view for monitoring warehouse load characteristics over time, including queued load metrics that help identify whether concurrency pressure still exists. An administrator can use it to see periods of queuing and overall load behavior for ETL_WH. To complement that, SHOW WAREHOUSES or warehouse metadata confirms the warehouse's multi-cluster configuration, such as minimum and maximum cluster counts and scaling policy. Together, these let the administrator validate both configuration and observed runtime behavior.
- B. Incorrect.
Incorrect. QUERY_HISTORY can help investigate individual query performance and queue-related timings, but using only completed statements and relying solely on execution time is not sufficient to determine whether the warehouse scaled out properly. Long execution time may be caused by query complexity, data volume, or inefficient SQL rather than cluster availability. Monitoring multi-cluster warehouse behavior is better done with warehouse-focused usage views such as WAREHOUSE_LOAD_HISTORY.
- C. Incorrect.
Incorrect. DATABASE_STORAGE_USAGE_HISTORY tracks storage consumption at the database level, not virtual warehouse cluster activity. Storage growth has no direct relationship to whether a multi-cluster warehouse added clusters in response to concurrency. This is a common misconception that mixes compute monitoring with storage monitoring.
- D. Incorrect.
Incorrect. LOGIN_HISTORY provides authentication and session-entry information, which is useful for security and access analysis, not for observing warehouse scaling behavior. The number of user logins does not directly determine cluster startup. Snowflake scales multi-cluster warehouses based on query workload and concurrency conditions, not simply on how many users logged in.