nerdexam
Snowflake

SOL-C01 · Question #145

A Snowflake virtual warehouse named 'TRANSFORM WH' is configured with the following parameters: 'WAREHOUSE SIZE = XSMALL', 'AUTO SUSPEND = , and 'AUTO RESUME = TRUE. During peak hours, this…

The correct answer is C. Enable Multi-Cluster Warehouse with 'MIN CLUSTER COUNT = 1' and `MAX CLUSTER COUNT. Enabling a Multi-Cluster Warehouse (option C) is correct because the core problem is concurrency, not compute size - during peak hours, multiple transformation jobs queue up, causing the warehouse to suspend while idle between bursts and then resume repeatedly, creating delays…

Virtual Warehouses

Question

A Snowflake virtual warehouse named 'TRANSFORM WH' is configured with the following parameters:

'WAREHOUSE SIZE = XSMALL', 'AUTO SUSPEND = , and 'AUTO RESUME = TRUE. During peak hours, this warehouse processes a large volume of data transformations. However, users report frequent delays as the warehouse repeatedly suspends and resumes. Which of the following changes would BEST address these performance delays while optimizing cost?

Options

  • AIncrease the 'AUTO_SUSPEND parameter to a larger value (e.g., 3600 seconds) to prevent
  • BIncrease the to MEDIUM. A larger warehouse has more compute power and will finish tasks faster.
  • CEnable Multi-Cluster Warehouse with 'MIN CLUSTER COUNT = 1' and `MAX CLUSTER COUNT
  • DSet 'AUTO SUSPEND = NULLS. This will prevent the warehouse from ever suspending, ensuring
  • EDecrease the 'AUTO_SUSPEND' parameter to a smaller value (e.g., 60 seconds) to force more

How the community answered

(28 responses)
  • A
    4% (1)
  • B
    7% (2)
  • C
    68% (19)
  • D
    4% (1)
  • E
    18% (5)

Explanation

Enabling a Multi-Cluster Warehouse (option C) is correct because the core problem is concurrency, not compute size - during peak hours, multiple transformation jobs queue up, causing the warehouse to suspend while idle between bursts and then resume repeatedly, creating delays. Multi-cluster warehouses automatically spin up additional clusters to handle concurrent workloads and scale back down when demand drops, directly solving the suspend/resume thrashing while keeping costs proportional to actual usage.

Why the distractors fail:

  • A (larger AUTO_SUSPEND): Keeps the warehouse alive longer when idle, increasing cost - but does nothing for peak-hour queuing.
  • B (increase to MEDIUM): Scales up compute per query but doesn't help when the problem is many concurrent jobs queuing - a bigger single warehouse still processes one queue.
  • D (AUTO_SUSPEND = NULL): Eliminates suspension entirely, guaranteeing runaway costs during off-peak hours.
  • E (smaller AUTO_SUSPEND): Makes the problem worse - more frequent suspensions mean more cold-start latency for users.

Memory tip: Think of it as the difference between a wider road (multi-cluster = more lanes for concurrent traffic) vs. a faster car (larger size = faster per trip). Frequent suspend/resume during peak hours signals a traffic jam, not a speed problem - so you need more lanes, not a faster car.

Topics

#Auto Suspend/Resume#Multi-Cluster Warehouse#Warehouse Scaling#Performance Tuning

Community Discussion

No community discussion yet for this question.

Full SOL-C01 Practice