What you will be able to do
- Explain why Secure Data Sharing needs no data copy, and who pays for storage and for compute
- Match common data sharing use cases to the right method: direct share, listing, Data Exchange or clean room
- Work out who a share can reach: your own accounts, other organizations' accounts, and the one-database-per-share rule
- Configure a share with the right privileges, grants and consumer accounts
- Apply the security patterns for shares: secure views, consumer simulation, Business Critical guidance and streams on shared objects
Key concept
Zero-copy Secure Data Sharing — A provider grants selected database objects to a named share. Each consumer account then queries those objects in place, read-only, through Snowflake's metadata layer, so no data is copied or moved between accounts.
1.How Secure Data Sharing works, and who pays
Direct shares, Marketplace listings, data exchanges and clean rooms all rest on one mechanism: Secure Data Sharing. A provider account puts selected database objects into a share, which is a named Snowflake object. Each consumer account creates a read-only database from that share. Nothing moves. Snowflake answers the consumer's queries from the provider's data through its services layer and metadata store. There is no pipeline to build and no copy to keep in sync, and the consumer can query the data almost as soon as it is added to the share.
An architect has to design around three consequences. First, everything shared between accounts is read-only. The consumer cannot insert, update or delete in a shared table. Second, costs fall unevenly. Shared data uses no storage in the consumer account, so the consumer pays only for the virtual warehouses it runs queries on. The provider keeps paying to store the data. Third, the provider stays in control. New objects added to a share, and changes to objects already in it, reach every consumer immediately. Access to a share, or to any single object in it, can be revoked at any time.
Checkpoint 1 of 7· Check yourself
A partner account runs queries against a 2 TB table that you share with it. What does the partner pay for?
Shared data uses no storage in the consumer account, so the consumer pays only for the warehouses it queries with. The provider keeps paying for storage.
“The only charges to consumers are for the compute resources (i.e. virtual warehouses) used to query the imported data.”Source: docs.snowflake.com
Checkpoint 2 of 7· Exam question
A retail company runs all analytics workloads in a single Snowflake account. The finance team's schema holds a REVENUE_SUMMARY table, and the marketing team, using a different role in the same account, needs read-only access to that table without any data being duplicated. What is the most appropriate way to grant this access?
Correct answer: A — Grant the marketing role USAGE on the finance database and schema plus SELECT on the table directly through the account's existing role hierarchy.
- A. Correct - within a single account, standard RBAC grants (USAGE/SELECT) already provide direct, real-time access without needing Secure Data Sharing constructs, which exist for cross-account boundaries.
- B. Incorrect - shares exist to expose data across account boundaries; using one inside the same account adds unnecessary indirection when a direct grant already achieves the same read-only access.
- C. Incorrect - reader accounts are provisioned for external consumers who lack their own Snowflake account, not for teams that already operate inside the same account as the data owner.
- D. Incorrect - listings add discovery and marketplace metadata for external or cross-account distribution, which is unneeded overhead for granting access within one account.
The use case decides which sharing method you build on that mechanism. The documentation names four methods. A direct share sends specific database objects to another account in your region. A listing offers a share plus metadata as a data product to one or more accounts, privately or publicly on the Snowflake Marketplace. A Data Exchange is a group of accounts that you set up and manage, and you offer a share to that group. A clean room lets you share data while controlling which queries can be run against it. Typical use cases line up with these methods. A central data account feeding departmental accounts, or a partner in the same region, fits a direct share. Marketing a data product to many consumers, charging for it, or reaching other regions fits a listing. On the Marketplace, consumers look for things like historical data for research, forecasting and machine learning, up-to-date streaming data such as weather and traffic, and identity data for audience targeting. A steady group of business partners, such as internal departments, vendors, suppliers and external partners, fits a Data Exchange. Two parties combining data without either seeing the other's raw rows, for example in audience overlap or reach and frequency analysis, fits a clean room. With listings, direct shares and Data Exchange, the consumer queries the data directly. With a clean room, it gets only the analyses the provider allows. A consumer with no Snowflake account is served through a reader account.
Checkpoint 3 of 7· Check yourself
Two companies want to measure how much their customer audiences overlap. Neither may query the other's raw customer rows. Which sharing method fits this use case?
Shares, listings and Data Exchanges let the consumer query the shared data directly. A clean room lets the provider control which analyses run, so the parties get overlap results without access to each other's raw data.
“With a clean room, the data provider controls which analyses can be run against their data”Source: docs.snowflake.com
2.Who a share can reach: your own accounts and other organizations
Shares go from one account to another. The documentation says data sharing is supported only between Snowflake accounts. Any full account can act as a provider, a consumer, or both. When the provider adds accounts to a share, those can be its own other accounts. So the same mechanism works inside an organization that runs several accounts, such as a central data account sharing to departmental accounts, and between companies. The sources describe sharing between accounts only. They do not describe sharing with yourself inside a single account, so don't assume a share is the tool for that.
Two rules limit the design on each side. A consumer can import as many shares as it likes, but it can create only one database per share. Other teams get access to that one database through ordinary role-based access control. On the provider side, a consumer of a direct share can reshare it only within the consumer's own organization. Region matters too. A direct share works only between accounts in the same region. Reaching another region or another cloud platform needs a listing with cross-cloud auto-fulfillment, or replication.
| Who the consumer is | Approach |
|---|---|
| Another account you own, in the same region | Direct share, adding your own account to the share |
| Another organization's account, in the same region | Direct share, or a listing if you want metadata, usage metrics or the option to charge |
| An account in another region or on another cloud platform | Listing with cross-cloud auto-fulfillment, or replication |
| Someone without a Snowflake account | Reader account, owned and paid for by the provider |
Checkpoint 4 of 7· Check yourself
A consumer has already created database SALES_DB from a provider's share. A sandbox team now wants its own database from the same share. What should the consumer do?
A consumer can create only one database per share. Other teams get access to that imported database through roles.
“You can consume as many shares as you want from data providers, but you can only create one database per share.”Source: docs.snowflake.com
3.Configuring a share: privileges, grants and consumer accounts
Setting up a share uses two levels of privilege. Any role can prepare the objects to be shared. Creating the share and adding consumer accounts to it needs the ACCOUNTADMIN role, or a role that holds the global CREATE SHARE privilege. On the consumer side, when getting data from a Data Exchange listing, only ACCOUNTADMIN or a role with the IMPORT SHARE privilege can get or request data. The sources don't describe any account-level parameter for sharing. The parameters that do matter are set on a session, on a table or on a replication group, and appear in the security patterns and replication material.
A provider adds objects to a share in one of two ways: by granting privileges to a database role that is then granted to the share, or by granting privileges directly to the share. A shared database role doesn't support future grants. The minimal direct-grant setup gives USAGE on the database and schema, and SELECT on the table:
CREATE SHARE test_share;
GRANT USAGE ON DATABASE test_db TO SHARE test_share;
GRANT USAGE ON SCHEMA test_db.test_schema TO SHARE test_share;
GRANT SELECT ON TABLE test_db.test_schema.test_table TO SHARE test_share;Checkpoint 5 of 7· Put it in order
Put the steps of a basic sharing setup in order, from provider to consumer
- 1.Provider grants privileges on the objects to the share, directly or through a database role
- 2.Provider adds one or more consumer accounts to the share
- 3.Provider creates the share
- 4.Consumer creates a database from the share and grants roles access to it
The provider creates the share, fills it with grants, and then adds accounts. Only after that can the consumer create a database from the share and give its roles access.
“Create a share, grant privileges on the objects that you want to share (directly or through a database role), and then add one”Source: docs.snowflake.com
Shares can hold databases, tables, dynamic tables, external tables, Iceberg tables, externally managed Delta Lake tables, views, Cortex Search services, UDFs (secure and non-secure) and certain models. Views need care. The object list on the overview page includes regular views, but the configure-shares page says only secure views are supported and adding a standard view returns an error. Design with secure views. Data changes inside an object already shared reach consumers immediately. A newly created object does not: if you drop and recreate a table, you must grant it to the share again. SHOW GRANTS TO SHARE lists the privileges in a share, and SHOW GRANTS OF SHARE lists the accounts it is shared with.
Checkpoint 6 of 7· Fill the gap
Which keyword completes this statement, which gives a consumer account access to an existing share?
ALTER SHARE share1 ? ACCOUNTS = consumer_org.consumer_account_name;ALTER SHARE … ADD ACCOUNTS adds consumer accounts to a share. The share becomes available to a consumer as soon as its account is added.
Source: docs.snowflake.com4.Security patterns for shared data
Sharing a whole database or whole tables needs almost no preparation. To filter rows by a condition, or to split one share's data across different consumer accounts, you need secure views, secure materialized views or secure UDFs. These control how much detail each consumer sees and hide the base tables and business logic. Two design rules apply. A secure object that uses fully qualified names must point at the database being shared. And a secure object must not use CURRENT_USER or CURRENT_ROLE, because those values mean nothing in the consumer's account and the object will fail when queried. Before sharing, check what a given consumer will actually see by simulating that consumer in your own session:
ALTER SESSION SET SIMULATED_DATA_SHARING_CONSUMER = xy12345;This parameter works with secure views and secure materialized views. It does not work with secure UDFs. Account edition matters as well. A Business Critical account should not share sensitive data with non-Business Critical accounts. One suggested pattern is a separate non-Business Critical account that holds less sensitive data for sharing. With Tri-Secret Secure, Snowflake treats a consumer's access as if it came from your own account. For HIPAA accounts, signing a BAA with each sharing partner is the accounts' own responsibility.
Consumers often want change data. Sharing secure views built on streams is an anti-pattern. Instead, let consumers create their own streams on the tables or secure views you share. For that to work, the provider sets two table parameters. CHANGE_TRACKING = TRUE has to be set because a consumer cannot add tracking columns to someone else's table. DATA_RETENTION_TIME_IN_DAYS should be raised because a consumer's stream does not extend retention the way a stream on a local table does.
Checkpoint 7 of 7· Match them up
Match each parameter to its role when sharing data
Tap a term, then the definition that fits it.
The provider sets the simulation parameter on a session to test filtering. Both table parameters are set on the provider's tables, because a consumer cannot change the source database.
“You set the CHANGE_TRACKING and DATA_RETENTION_TIME_IN_DAYS parameters when creating or altering a table, using CREATE TABLE or ALTER TABLE.”Source: docs.snowflake.com
Sources5
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.If I drop and recreate a table with the same name in a shared database, consumers automatically see the new table.Why is that wrong?
Snowflake treats a recreated object as a new object. It must be granted to the share again with GRANT <privilege> … TO SHARE.
Covered in Configuring a share: privileges, grants and consumer accounts
2.A secure view that filters rows by CURRENT_ROLE() is a good way to limit what each consumer sees.Why is that wrong?
CURRENT_USER and CURRENT_ROLE mean nothing in the consumer's account and make the object fail. Filter by consumer account instead, and check the result with SIMULATED_DATA_SHARING_CONSUMER.
Covered in Security patterns for shared data
3.A consumer's stream on a shared table extends that table's retention to keep the stream from going stale, just as it would for a local table.Why is that wrong?
Streams on shared tables or views do not extend retention. The provider has to set DATA_RETENTION_TIME_IN_DAYS on the tables explicitly.
Covered in Security patterns for shared data
4.A clean room is just another kind of share, so collaborators can query the other party's raw data directly once they join.Why is that wrong?
In a clean room, data can only be reached through approved templates. Neither party can query or view the imported raw data directly.
Covered in How Secure Data Sharing works, and who pays
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“All database objects shared between accounts are read-only”
↩︎ How Secure Data Sharing works, and who pays“Providers continue to pay for storage of the data that they share.”
↩︎ How Secure Data Sharing works, and who pays“Access to a share (or any of the objects in a share) can be revoked at any time.”
↩︎ How Secure Data Sharing works, and who pays“a Direct Share, in which you directly share specific database objects (a share) to another account in your region”
↩︎ How Secure Data Sharing works, and who pays“a Data Exchange, in which you set up and manage a group of accounts and offer a share to that group”
↩︎ How Secure Data Sharing works, and who pays“a clean room, in which you can share data and control which queries can be run against your data.”
↩︎ How Secure Data Sharing works, and who pays“Use a listing when you want to share across regions, offer data publicly on the Snowflake Marketplace, charge for access”
↩︎ How Secure Data Sharing works, and who pays“Data sharing is only supported between Snowflake accounts.”
↩︎ Who a share can reach: your own accounts and other organizations“One or more accounts are then added to the share, which can include your own accounts (if you have multiple Snowflake accounts).”
↩︎ Who a share can reach: your own accounts and other organizations“A direct share works only with accounts in the same region.”
↩︎ Who a share can reach: your own accounts and other organizations“With Secure Data Sharing, no actual data is copied or transferred between accounts. All sharing uses Snowflake’s services layer and metadata store.”
↩︎ Key concept“The only charges to consumers are for the compute resources (i.e. virtual warehouses) used to query the imported data.”
↩︎ Checkpoint“You can consume as many shares as you want from data providers, but you can only create one database per share.”
↩︎ Checkpoint“Create a share, grant privileges on the objects that you want to share (directly or through a database role), and then add one”
↩︎ Checkpoint - 2.
“Historical data for research, forecasting, and machine learning.”
↩︎ How Secure Data Sharing works, and who pays - 3.
“such as internal departments in your company or vendors, suppliers, and partners external to your company”
↩︎ How Secure Data Sharing works, and who pays - 4.
“Snowflake provides a few stock templates for common use cases such as audience overlap and reach and frequency templates.”
↩︎ How Secure Data Sharing works, and who pays“Data imported into a clean room cannot be queried or viewed directly by either party”
↩︎ Exam trap 4 - 5.
“A direct share is enabled for resharing within the consumer’s organization only.”
↩︎ Who a share can reach: your own accounts and other organizations“require the ACCOUNTADMIN role or a role granted the global CREATE SHARE privilege”
↩︎ Configuring a share: privileges, grants and consumer accounts“A shared database role does not support future grants on objects.”
↩︎ Configuring a share: privileges, grants and consumer accounts“If a standard view is added to a share, Snowflake returns an error.”
↩︎ Configuring a share: privileges, grants and consumer accounts“To provide strict control of access to data in a shared database, you must use secure views, secure materialized views and/or secure UDFs.”
↩︎ Security patterns for shared data“The SIMULATED_DATA_SHARING_CONSUMER session parameter only supports secure views and secure materialized views, but does not support secure UDFs.”
↩︎ Security patterns for shared data“Do not share sensitive data with non-Business Critical accounts.”
↩︎ Security patterns for shared data“Snowflake treats the data access from these accounts as if the access occurred from within your own account.”
↩︎ Security patterns for shared data“A new object created or recreated in a database granted to a share is not automatically available to consumers.”
↩︎ Exam trap 1“The contextual values returned by these functions have no relevance in a consumer’s account and will cause the object to fail when queried/used.”
↩︎ Exam trap 2“A stream on a shared table does not extend the data retention period for the table.”
↩︎ Exam trap 3“You set the CHANGE_TRACKING and DATA_RETENTION_TIME_IN_DAYS parameters when creating or altering a table, using CREATE TABLE or ALTER TABLE.”
↩︎ Checkpoint - 6.
“only users with the ACCOUNTADMIN role or the IMPORT SHARE privilege can get or request data.”
↩︎ Configuring a share: privileges, grants and consumer accounts
Also cited
“With a clean room, the data provider controls which analyses can be run against their data”
↩︎ Checkpoint