6.1 Secure Data Sharing Architecture

What Secure Data Sharing Is

Secure Data Sharing is Snowflake's native mechanism for sharing selected database objects between Snowflake accounts without copying or moving any data. This is the defining fact tested again and again on the SnowPro Core exam: no actual data is transferred. Sharing is performed entirely through Snowflake's cloud services layer and its metadata store. When a provider shares a table, Snowflake records pointers to the provider's existing micro-partitions; the consumer simply reads those same physical files.

Because nothing is copied, three consequences follow that the exam loves to test:

• No storage cost to the consumer. Shared data does not count toward the consumer's monthly storage charges. Storage stays billed to the provider, who owns the underlying files.
• No latency / always live. The consumer always sees the current data. There is no replication lag within a region because there is only one copy of the data.
• Read-only. Every object a consumer accesses through a share is read-only. The consumer cannot insert, update, delete, or alter shared objects, and cannot add or drop columns.

The Data Collaboration domain is roughly 10% of the COF-C03 blueprint. It rewards understanding who pays for what and what physically happens far more than memorizing syntax.

Provider and Consumer Roles

Two roles structure every sharing scenario:

• A provider is any Snowflake account that creates a share and grants access to objects within it. A single provider can create many shares and add many consumers to each.
• A consumer is any account that has been added to a share and creates a database from it to query the data.

The compute split is a high-yield distinction. A consumer that is a full Snowflake account runs queries on its own virtual warehouse and pays those credits itself. The provider does not pay for the consumer's queries. (The exception is reader accounts, covered in 6.2, where the provider pays compute.)

Billing summary

Memorize this single sentence: the provider always pays storage; a standard consumer pays its own compute. If a question describes a consumer worried about storage cost from a large shared dataset, the correct answer is that shared data incurs no storage charge for the consumer.

What Can Be Shared and Cross-Region Limits

A share is a named, first-class Snowflake object that can include databases, schemas, tables, external tables, secure views, secure materialized views, and secure UDFs. Snowflake requires the secure variants for views and UDFs so the underlying object definitions and base table names are not exposed to the consumer.

Direct Secure Data Sharing is limited to accounts in the same region and on the same cloud platform. Crossing a region or cloud boundary requires database replication first: the provider replicates the database to the target region, then shares from the replica. Snowflake Marketplace listings automate this replication step (see 6.3), which is why listings — not direct shares — are the answer when a scenario spans regions or clouds.

Quick mental model

1. Provider creates a share and grants objects to it.
2. Provider adds consumer account(s) to the share.
3. Consumer creates a database from the share.
4. Consumer queries that database using its own warehouse — reading the provider's live, read-only data.

Keeping this four-step flow straight resolves most architecture questions on test day. The recurring trap is assuming data is duplicated into the consumer account; it is not — only metadata changes hands.

Why the Architecture Matters for the Exam

The whole reason Snowflake can share data with zero copy is its decoupled architecture. Storage, compute, and cloud services are separate layers. Data lives once in cloud storage as immutable micro-partitions; compute is provided by independent virtual warehouses; and the cloud services layer holds the metadata catalog that maps logical tables to those micro-partitions. Sharing simply extends an entry in that catalog so a second account's queries resolve to the provider's partitions. Nothing is duplicated because the architecture already separates the data from the engines that read it.

This design produces several exam-relevant guarantees:

• Instant setup. Because there is no bulk copy, a share is available the moment the grants and account additions complete.
• Always current. Updates the provider makes to the source are visible to all consumers immediately — there is no synchronization job and no staleness within a region.
• Independent compute scaling. Each consumer sizes and pays for its own warehouse, so one consumer's heavy workload never affects the provider or other consumers.
• Provider control. The provider can revoke a share (ALTER SHARE ... REMOVE ACCOUNTS) or drop objects from it at any time, instantly cutting off access without deleting any data.

When an exam stem describes a requirement like "share live data with no copy, no ongoing sync, and no extra storage," every one of those phrases is pointing at Secure Data Sharing. Recognizing that this is a property of the layered architecture — not a feature you toggle — is what separates a confident answer from a guess. Treat the no-copy, read-only, provider-pays-storage trio as non-negotiable invariants you can use to eliminate distractors quickly.