SOL-C01 · Question #96
A Snowflake account uses separate virtual warehouses for different workloads: 'REPORTING WI- 4' for reporting queries and 'TRANSFORM WH' for data transformation jobs. A user, Alice, is responsible for
The correct answer is E. Enable multi-cluster warehouses for 'REPORTING with a scaling policy set to `STANDARD and a. Option E is correct because enabling multi-cluster warehouses on REPORTING_WH with a STANDARD scaling policy lets Snowflake automatically spin up additional compute clusters the moment query queuing is detected - directly solving the concurrency bottleneck caused by transformatio
Question
A Snowflake account uses separate virtual warehouses for different workloads: 'REPORTING WI- 4' for reporting queries and 'TRANSFORM WH' for data transformation jobs. A user, Alice, is responsible for running both types of workloads. Alice is experiencing performance issues with reporting queries when the transformation jobs are running concurrently. Both warehouses are currently configured with the 'STANDARD' size. What are the recommended strategies to improve the performance of reporting queries without significantly impacting the performance of transformation jobs?
Options
- AIncrease the size of 'REPORTING_WH' to 'LARGE and enable auto-suspend on to prevent it from
- BEnable mufti-cluster warehouses for both and and set the scaling policy to 'ECONOMY' for
- CEnable auto-suspend on 'REPORTING_WH' and increase the size of 'TRANSFORM_WH' to
- DEnable Resource Monitors to limit the credit usage of 'TRANSFORM_WH' and increase the size of
- EEnable multi-cluster warehouses for 'REPORTING with a scaling policy set to `STANDARD and a
How the community answered
(28 responses)- A4% (1)
- B18% (5)
- C4% (1)
- D7% (2)
- E68% (19)
Explanation
Option E is correct because enabling multi-cluster warehouses on REPORTING_WH with a STANDARD scaling policy lets Snowflake automatically spin up additional compute clusters the moment query queuing is detected - directly solving the concurrency bottleneck caused by transformation jobs running simultaneously. The STANDARD scaling policy prioritizes availability by adding clusters quickly, whereas leaving TRANSFORM_WH unchanged ensures transformation job performance is unaffected.
Why the distractors fail:
- A - Scaling up (STANDARD → LARGE) improves performance for complex single queries but does nothing for concurrency; multiple queries still queue behind each other on one cluster. Auto-suspend reduces cost, not latency.
- B - Applying multi-cluster to
TRANSFORM_WHis unnecessary, and theECONOMYscaling policy deliberately delays adding clusters to maximize utilization - the opposite of what you want for responsive reporting. - C - Auto-suspend on
REPORTING_WHintroduces cold-start delays, making performance worse. UpsizingTRANSFORM_WHdoesn't help reporting queries at all. - D - Resource Monitors track and cap credit spending; they don't dynamically reallocate compute between workloads. Hitting a credit cap would abruptly suspend
TRANSFORM_WH, not gracefully balance resources.
Memory tip: Use the phrase "scale OUT for crowd, scale UP for complexity." When the problem is many queries competing (concurrency), multi-cluster scales out horizontally. When the problem is one slow query (data volume/joins), size up vertically. This question is a concurrency problem → multi-cluster wins.
Topics
Community Discussion
No community discussion yet for this question.