ADA-C01 Question 417
Single answerUse WAREHOUSE_MONITORING to optimize costsA Snowflake administrator is reviewing warehouse spend after finance reports that a BI warehouse is consuming more credits than expected. The team wants to use Snowsight's WAREHOUSE_MONITORING capabilities to identify practical cost optimizations without changing query logic. The warehouse is configured as MEDIUM, auto-suspend = 10 minutes, auto-resume = true, and max cluster count = 3. In WAREHOUSE_MONITORING, the administrator observes the following over the last 14 days: (1) long periods of warehouse uptime with very low query volume, (2) most queries complete quickly with little queueing, and (3) multi-cluster usage is rare and brief. Which action is the best first recommendation to reduce credits while minimizing performance risk?
- A
Reduce the auto-suspend setting from 10 minutes to 60 seconds and continue monitoring usage patterns
- B
Disable auto-resume so the warehouse only starts when an administrator manually resumes it
- C
Increase the warehouse size to LARGE so queries finish faster and the warehouse can suspend sooner
- D
Keep the warehouse size and suspend settings unchanged, but raise the max cluster count from 3 to 5
Show answer and explanation
Correct answer: A
Explanation
The best first recommendation is to reduce auto-suspend because WAREHOUSE_MONITORING is intended to help administrators evaluate warehouse activity, concurrency behavior, and credit usage patterns to make practical tuning decisions. In this scenario, the key signals are long idle periods, fast query completion, minimal queueing, and infrequent multi-cluster activity. Together, these indicate that the warehouse is likely over-running between bursts of BI usage rather than being undersized. Snowflake best practices for cost optimization generally include enabling auto-suspend, setting an appropriately short suspend interval for intermittent workloads, and using auto-resume to preserve usability. By contrast, increasing warehouse size or cluster count is more appropriate when monitoring shows sustained queueing or throughput constraints. This aligns with Snowflake guidance around warehouse sizing, auto-suspend/auto-resume behavior, and using monitoring views and Snowsight warehouse monitoring to tune compute cost versus performance.
- A. Correct.
Correct. WAREHOUSE_MONITORING is commonly used to identify idle time and underutilization. If the warehouse shows long periods of uptime with very low activity, reducing auto-suspend is typically the lowest-risk and most direct cost optimization. Since most queries already complete quickly and queueing is minimal, shortening idle time is more appropriate than adding compute. A 60-second auto-suspend is a common cost-control setting when workloads are intermittent and auto-resume is enabled.
- B. Incorrect.
Incorrect. Disabling auto-resume can reduce convenience and disrupt users or scheduled workloads, but it is not usually the best first optimization for a BI warehouse. It shifts operational burden to administrators and users rather than addressing the observed inefficiency, which is idle running time. Snowflake best practice is generally to keep auto-resume enabled for interactive workloads and tune auto-suspend appropriately.
- C. Incorrect.
Incorrect. Increasing the warehouse size would likely increase credit consumption per unit of time. While larger warehouses can reduce runtime for some workloads, the scenario states that most queries are already fast and there is little queueing. WAREHOUSE_MONITORING indicates the issue is extended idle uptime, not insufficient compute capacity. This option reflects the common misconception that faster execution automatically lowers overall cost.
- D. Incorrect.
Incorrect. Raising max cluster count would only help if concurrency pressure were causing significant queueing and additional clusters were frequently needed. The monitoring data shows multi-cluster usage is rare and brief, so increasing the cluster limit would not address the main source of spend. In fact, it could enable higher compute consumption during spikes without solving the observed idle-time waste.