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

Question

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

• A
  4% (1)
• B
  18% (5)
• C
  4% (1)
• D
  7% (2)
• E
  68% (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_WH is unnecessary, and the ECONOMY scaling policy deliberately delays adding clusters to maximize utilization - the opposite of what you want for responsive reporting.
• C - Auto-suspend on REPORTING_WH introduces cold-start delays, making performance worse. Upsizing TRANSFORM_WH doesn'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.

No community discussion yet for this question.