COF-C03 Question 68
Single answerWarehouse type and configurations based on use casesA retail company uses Snowflake for two different workloads. During business hours, analysts run many short, concurrent dashboard queries with unpredictable spikes in demand. Overnight, the data engineering team runs a small number of long-running ETL jobs that scan large volumes of data. The company wants to improve performance while controlling cost by choosing the most appropriate warehouse configuration for each workload. Which approach best fits these requirements?
- A
Use a multi-cluster warehouse with auto-scale for the daytime dashboard workload, and a separate standard warehouse sized appropriately for the overnight ETL workload
- B
Use one single-cluster X-Small warehouse for both workloads and enable auto-suspend to reduce costs
- C
Use a Snowpark-optimized warehouse for the dashboard workload, and a multi-cluster warehouse for the ETL workload
- D
Use one multi-cluster warehouse for both workloads at all times, because multi-cluster warehouses are the most cost-efficient option for every workload
Show answer and explanation
Correct answer: A
Explanation
The best practice is to align warehouse configuration to workload characteristics. In Snowflake, multi-cluster warehouses are best suited for workloads with many concurrent queries, such as BI dashboards and user-facing analytics, because they can add clusters to reduce queuing. In contrast, ETL workloads often consist of fewer, longer-running statements that benefit from choosing the right warehouse size rather than scaling out for concurrency. Using separate warehouses for different workload patterns improves performance isolation, simplifies tuning, and helps control cost. Snowflake documentation on virtual warehouses, multi-cluster warehouses, and workload isolation supports this approach: use multi-cluster for concurrency-driven workloads and standard warehouses sized appropriately for batch processing.
- A. Correct.
Correct. Multi-cluster warehouses are designed to handle high concurrency by automatically adding clusters when many users submit queries at the same time, which makes them a strong fit for BI/dashboard workloads with unpredictable spikes. A separate standard warehouse is typically appropriate for batch ETL jobs, where the challenge is usually query size and compute capacity rather than concurrent users. Separating warehouses by workload also helps isolate resource consumption and tune size/configuration independently.
- B. Incorrect.
Incorrect. A single-cluster X-Small warehouse is unlikely to perform well for both highly concurrent dashboard traffic and large overnight ETL processing. Auto-suspend helps control cost when a warehouse is idle, but it does not solve concurrency bottlenecks or provide enough compute for large scans. This option reflects the common misconception that one tiny warehouse can economically handle all workloads if suspend/resume is enabled.
- C. Incorrect.
Incorrect. Snowpark-optimized warehouses are intended for workloads that require more memory, such as certain Snowpark operations, rather than standard BI dashboard concurrency. They are not the default recommendation for dashboard queries. Likewise, using a multi-cluster warehouse for ETL is usually unnecessary unless the ETL workload itself has high concurrency; long-running batch jobs generally benefit more from appropriate sizing of a standard warehouse.
- D. Incorrect.
Incorrect. Multi-cluster warehouses are useful for concurrency scaling, but they are not automatically the most cost-efficient choice for every workload. For ETL and other low-concurrency, compute-intensive jobs, a properly sized standard warehouse is often more appropriate. Using one multi-cluster warehouse for everything can increase cost and reduce workload isolation.