Study SnowPro DEA-C02 Pruning and Clustering: key concepts, common traps, and exam decision cues.
Snowflake performance questions usually reward diagnosis that stays close to scan behavior, workload shape, and observability instead of jumping straight to bigger warehouses.
| Symptom | Better first instinct |
|---|---|
| too much data scanned | inspect pruning and filter behavior |
| repeated expensive workloads | inspect workload shape and history before resizing |
| unclear root cause | build the troubleshooting path from observability evidence outward |
| selective query still feels slow | clustering and scan behavior may matter |
| If the symptom is… | Stronger first answer |
|---|---|
| excessive scan volume | pruning and filter behavior |
| selective query still reading too much | clustering or scan behavior |
| repeated costly workload | observability evidence plus workload-shape review |
This is the center of Snowflake performance-first troubleshooting.
| If the stem says… | Strong reading |
|---|---|
| “evaluate performance metrics” | understand what the metrics imply before acting |
| “scan too much data” | pruning or clustering may matter more than warehouse size |
| “performance-first troubleshooting” | the answer should begin with evidence, not intuition |
More compute can make a bad plan run faster, but it does not remove wasted work. DEA-C02 often rewards the fix that reduces the unnecessary scan or improves observability before it rewards the one that simply buys more warehouse power.
| Trap | Better rule |
|---|---|
| solving every slowdown with larger compute | some are scan or layout problems |
| treating observability as optional | Snowflake exposes history and profiles for a reason |
| ignoring filter and access pattern when tuning | pruning depends on how the workload actually reads data |
| Scenario clue | Stronger answer shape |
|---|---|
| “query reads far too much data” | pruning issue first |
| “selective query still feels slow” | clustering and scan behavior |
| “no clear root cause yet” | observability-driven troubleshooting |
| “warehouse resize is the first impulse” | step back and read evidence first |
Troubleshooting questions in this lane usually reward evidence before resizing compute. If the query scans far more data than expected, think pruning and layout first. If pruning is weak, clustering or access-pattern alignment may matter. The weak answer usually resizes the warehouse immediately without confirming that the real problem is wasted scan work.