Study guide
6.1 Secure Data Sharing Architecture
SnowPro Core Study Guide Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: SnowPro Core Orientation and Exam Strategy
1.1 Current SnowPro Core Exam Facts 1.2 Eligibility, Registration, and Scheduling 1.3 Blueprint Domains and Weighting 1.4 Editions, Question Style, and Score Report Thinking 1.5 Study Calendar and Hands-On Practice Plan
2 Chapter 2: Snowflake AI Data Cloud Features and Architecture
2.1 Snowflake AI Data Cloud Features and Architecture Overview 2.2 Core Workflows and Decision Points 2.3 Scenario Practice for Snowflake AI Data Cloud Features and Architecture 2.4 Common Traps in Snowflake AI Data Cloud Features and Architecture 2.5 Practice Drills and Readiness Markers
3 Chapter 3: Account Management and Data Governance
3.1 Account Management and Data Governance Overview 3.2 Core Workflows and Decision Points 3.3 Scenario Practice for Account Management and Data Governance 3.4 Common Traps in Account Management and Data Governance 3.5 Practice Drills and Readiness Markers
4 Chapter 4: Data Loading, Unloading, and Connectivity
4.1 Data Loading, Unloading, and Connectivity Overview 4.2 Core Workflows and Decision Points 4.3 Snowpipe, External Tables, and Storage Integrations 4.4 Bulk Unloading and Semi-Structured Data 4.5 Connectors, Drivers, and Snowsight Loading
5 Chapter 5: Performance Optimization, Querying, and Transformation
5.1 Performance Optimization, Querying, and Transformation Overview 5.2 Core Workflows and Decision Points 5.3 Micro-Partitions, Pruning, Clustering, and the Query Profile 5.4 Search Optimization, Materialized Views, and Query Best Practices 5.5 Transformations: ELT, Streams & Tasks, and Semi-Structured Data
6 Chapter 6: Data Collaboration
6.1 Secure Data Sharing Architecture 6.2 Creating Shares, Granting Objects, and Reader Accounts 6.3 Snowflake Marketplace, Listings, and Data Exchange 6.4 Secure Views, Cross-Region Sharing, and Governance 6.5 Choosing the Right Sharing Method and Readiness Drills
7 Chapter 7: Final Review and Test Day
7.1 Timed Practice Strategy 7.2 Last-Week Review Map 7.3 Exam-Day Checklist 7.4 After the Exam and Next Steps
6.1 Secure Data Sharing Architecture
Key Takeaways Explain This Topic AI
Secure Data Sharing moves no data: only metadata in the cloud services layer points consumers at the provider's existing micro-partitions.
Storage for shared data is billed only to the provider; consumers pay compute for queries run on their own virtual warehouses.
Shared objects are strictly read-only and reflect live data with no latency, because they are the same physical files.
Data Collaboration is roughly 10% of the SnowPro Core (COF-C03) blueprint and centers on sharing, listings, and reader accounts.
Last updated: October 2026
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.
- Aspect Provider Consumer
- Owns the data Yes No
- Pays for storage Yes No
- Pays for compute Only for its own queries Yes — for queries on shared data
- Can modify shared data Yes (in source) No (read-only)
- Creates the share Yes No
- Creates a database from the share No Yes
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, dynamic tables, external tables, Iceberg tables, regular views, secure views , secure materialized views , and UDFs (secure and non-secure), among other objects. Use the secure variants when the consumer must not see the underlying object definitions and base table names.
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
Provider creates a share and grants objects to it.
Provider adds consumer account(s) to the share.
Consumer creates a database from the share.
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.