Study COF-C03 Architecture, Storage, and Compute: key concepts, common traps, and exam decision cues.
SnowPro Core gets much easier once you stop treating Snowflake like one big database server. The exam expects you to separate the layer that stores data, the layer that spends compute, and the control layer that coordinates metadata, authentication, and optimization.
Cloud services: Snowflake control-plane layer for metadata, transactions, authentication, optimization, and service coordination.
| Layer | Owns | Common wrong move |
|---|---|---|
| storage | durable compressed data, micro-partitions, historical recovery foundations | assuming a larger warehouse changes how data is stored |
| compute | query execution, loading, transformations, concurrency behavior | assuming compute is where the data lives |
| cloud services | metadata, authentication, optimization, transactions, coordination | treating it like just another warehouse |
The exam often hides the answer inside the responsibility boundary. If the clue is about stored data layout, historical object state, or pruning behavior, think storage first. If the clue is about how much execution power is available right now, think compute. If the clue is about metadata, sign-in, or service coordination, think cloud services.
| If the stem says… | Better reading |
|---|---|
| “query scans too much data” | think pruning and storage layout before pure compute scaling |
| “same data, bigger warehouse” | more compute may improve execution speed, but it does not change stored micro-partitions |
| “recover older object state” | think Time Travel and storage history, not warehouse resize |
Micro-partitions matter because Snowflake stores data in internal storage units that support pruning and historical storage behavior. You do not need to memorize low-level internals. You do need to remember that data layout and pruning are storage-side concerns, not warehouse-side concerns.
The exam usually rewards responsibility-first reasoning. Many wrong answers sound attractive only because they treat a warehouse like a full database server instead of one compute layer inside a larger platform split.
| Scenario | Better first move |
|---|---|
| filtered query reads too much data | inspect pruning and storage-side behavior |
| same data but more processing power is needed | resize or rethink compute |
| sign-in, metadata, or transaction behavior is central | think cloud services |
| team assumes bigger warehouses change stored layout | reset the storage versus compute split |
| Trap | Better rule |
|---|---|
| warehouse equals database server | warehouse is compute only |
| control-plane behavior equals compute behavior | metadata and authentication live in cloud services |
| every slow query needs more warehouse size | decide whether the real issue is compute or scan volume first |