Snowflake AI Data Cloud architecture Study Guide — COF-C03

Snowflake AI Data Cloud Features and Architecture

This domain is one of the largest topic areas in the SnowPro Core COF-C03 blueprint under the current estimated domain weighting — tied with two other domains rather than standing alone as the largest. It tests your ability to recognize how Snowflake's architecture is structured, how each layer behaves, what objects exist at each level, how editions differ, which tools connect to Snowflake and how, and how the caching system accelerates query execution. Expect scenario-based questions that require you to select the correct architectural tier, warehouse configuration, table type, or cache layer for a given business requirement.

Three-Layer Architecture: Storage, Compute, Cloud Services

Snowflake runs entirely in the cloud on top of AWS, Azure, or GCP. Its architecture is deliberately separated into three independent layers, allowing each to scale independently and be billed independently.

Key behaviors to memorize:

• Storage and compute are fully decoupled. You can have unlimited warehouses reading the same data simultaneously with no contention.
• Cloud Services runs 24/7 and is shared. You are only charged if Cloud Services consumption exceeds 10% of your daily compute credit usage.
• Data at rest is always encrypted (AES-256). Data in transit uses TLS.
• Snowflake owns and manages all storage; customers cannot directly access the underlying object store.

Worked scenario: A customer asks why two departments running queries at the same time see no slowdown. The answer is that each department uses its own virtual warehouse (separate compute clusters) reading from the same shared storage layer — a direct consequence of the decoupled architecture.

Common traps

• Exam distractors suggest that sharing a warehouse between workloads is required — it is not; separate warehouses are the Snowflake-native solution.
• "Cloud Services is free" is partially true — only up to the 10% threshold. Above that, Cloud Services credits are billed.
• Do not confuse the three-tier architectural layers with Snowflake deployment regions.

Virtual Warehouses: Sizes, Multi-Cluster, Scaling Policies

A virtual warehouse is a named compute cluster that executes DML, DQL, and data loading. It does not store data.

Sizes

Each size doubles credits from the previous. Billing is per second, with a 60-second minimum per start.

Auto-Suspend and Auto-Resume

• Auto-suspend default: 10 minutes (600 seconds) of inactivity. Configurable to any value ≥ 60 seconds or disabled entirely.
• Auto-resume: enabled by default; a warehouse resumes automatically when a query is submitted.
• A suspended warehouse accrues zero compute charges but retains its local disk cache metadata state (the cache itself is lost on suspension).

Multi-Cluster Warehouses (MCW)

MCW allows a single warehouse to spin up additional clusters to handle concurrency surges. Available only on Enterprise edition and above.

Scaling Policies:

Auto-scale mode (MIN < MAX): clusters scale up and down automatically. Maximized mode (MIN = MAX): all clusters run continuously; no automatic scaling.

Worked scenario: A BI tool generates 200 simultaneous queries every morning. A single XL warehouse queues most requests. The correct fix is to enable MCW (Enterprise required) with Standard scaling policy so additional clusters start immediately when queuing is detected. Upsizing the warehouse alone only helps with single-query performance, not concurrency.

Common traps

• MCW improves concurrency; upsizing improves individual query performance (larger queries, more data). These are not interchangeable.
• Economy policy waits ~6 minutes before starting a cluster — exam questions frame this as a latency trade-off.
• MCW is not available on Standard edition.
• The 60-second minimum billing applies per cluster start, not per query.