What you will be able to do
- Tell a direct share apart from the other ways Snowflake can share data
- Choose secure objects to control what a share exposes, and add new objects to a share correctly
- Explain the limits on resharing a direct share and the provider, resharer and consumer roles in listing resharing
- Describe what a data clean room adds beyond a plain share
1.Direct shares among the sharing options
Every form of Snowflake sharing is built on the same share object. What differs is how the share reaches its consumers. The documentation lists four options. A direct share is the most basic one: the provider names specific database objects and shares them with another account in its own region. There is no extra wrapping and no discovery mechanism.
The other three options build on that idea. A listing offers a share together with extra metadata as a data product. 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. You can also convert a direct share into a listing later. The documentation suggests that if a share needs to reach many accounts, a listing or a data exchange may suit better than adding accounts to a direct share one at a time.
| Option | What it is |
|---|---|
| Direct share | Specific database objects (a share) shared straight to another account in your region |
| Listing | A share plus extra metadata, offered as a data product to one or more accounts |
| Data exchange | A group of accounts you set up and manage, to which you offer a share |
| Clean room | Shared data where you control which queries can be run against it |
Checkpoint 1 of 6· Match them up
Match each sharing option to its description.
Tap a term, then the definition that fits it.
All four use shares. They differ in packaging (listing), audience (data exchange) and query control (clean room). A direct share is the plain account-to-account case.
“a Direct Share, in which you directly share specific database objects (a share) to another account in your region,”Source: docs.snowflake.com
Sources1
2.What goes into a share: secure objects and explicit grants
Many kinds of object can be shared. The list includes databases, tables, dynamic tables, external tables, Iceberg tables, several kinds of view, Cortex Search services, UDFs and certain model types. Sharing a whole database or whole tables takes little or no preparation. The planning starts when a provider wants to share only part of the data, for example filtering rows by date or giving each consumer account its own slice from a single share.
That is the job of secure objects: secure views, secure materialized views and secure UDFs. They let the provider choose how fine-grained the sharing is, while keeping the base tables and business logic hidden from the consumer. (The provider guide's usage notes are stricter still: they say only secure views are supported in shares and that adding a standard view returns an error, even though the object list includes regular views.)
Two design rules come with secure objects. Do not use CURRENT_USER or CURRENT_ROLE in their definitions, because those values mean nothing in the consumer's account and the object will fail. And check the result before you share it. The SIMULATED_DATA_SHARING_CONSUMER session parameter lets you query a secure view as if you were a given consumer account. It works with secure views and secure materialized views, but not with secure UDFs.
ALTER SESSION SET SIMULATED_DATA_SHARING_CONSUMER = xy12345;Last, a share does not automatically pick up new objects in a database. New and changed rows in objects already granted reach consumers immediately. But a newly created object is not shared until you grant it to the share, and neither is one that was dropped and recreated under the same name. You add it with GRANT <privilege> … TO SHARE.
Checkpoint 2 of 6· Check yourself
A provider drops a shared table and recreates it with the same name and new data. What do consumers see?
A recreated object counts as a new object, even under the same name. It must be added to the share with GRANT <privilege> … TO SHARE.
“A new object created or recreated in a database granted to a share is not automatically available to consumers.”Source: docs.snowflake.com
Sources2
3.Sharing and resharing
Resharing means a consumer passes data it received on to further accounts. For a direct share, the limit is tight: resharing is possible within the consumer's own organization and nowhere else. A consumer can reshare an imported database only when resharing is allowed. To check, run SHOW DATABASES and look at the resharing_settings column for that imported database.
Resharing listings is more flexible, and the provider controls it. The provider can turn resharing on or off for each listing. Three accounts are involved. The provider owns the original data. The resharer is a consumer of the provider's listing that builds new views on the incoming data and shares them onward. The downstream consumer accesses the reshared listing. Resharing can be multi-hop, so a resharer may pass on data that was itself reshared to it. When a resharer shares to another region, auto-fulfillment replicates the data there. The provider pays nothing for that replication; the cost is attributed to the resharer.
The provider also decides whose view of governance policies applies downstream, using the reshare_policy_enforcement property in the listing manifest. RESHARER is the default: consumers see exactly what the resharer can see. CALLER evaluates policies in each consumer's own account context, so each consumer sees only what it is entitled to. CALLER is the recommended mode for resharing within one organization when the provider wants per-consumer entitlements enforced.
Checkpoint 3 of 6· Put it in order
Put the steps of a typical resharing workflow in order.
- 1.Consumer A shares that outgoing view with Consumer B
- 2.Consumer B retrieves and uses the reshared data product
- 3.The provider shares its data product with Consumer A
- 4.Consumer A creates a view that references the shared data
The resharer (Consumer A) has to receive the data first, wrap it in its own view, and only then share that view with the second-level account.
“Consumer A creates a view that references the shared data and then shares these outgoing views”Source: docs.snowflake.com
Checkpoint 4 of 6· Check yourself
A resharer shares a listing's data to an account in another region, and auto-fulfillment replicates it. Who pays for the replication?
Cross-region resharing does replicate data. The documentation attributes that cost to the resharer, not the provider.
“The provider doesn’t incur additional costs for this replication. Replication costs are attributed to the resharer.”Source: docs.snowflake.com
Checkpoint 5 of 6· Exam question
A data platform team at a provider organization has already run CREATE SHARE and now wants to expose two tables in one schema to a named consumer account. Which sequence correctly finishes this setup?
Correct answer: A — Grant USAGE on the database and schema to the share, grant SELECT on the two tables to the share, then run ALTER SHARE ADD ACCOUNTS to add the consumer account.
- A. Populating a share requires granting USAGE down the container hierarchy (database, then schema) plus SELECT on the specific tables, and the consumer account is added to the share with ALTER SHARE ADD ACCOUNTS.
- B. Grants for a share must be made to the share object itself, not to the consumer's role directly, and USAGE on the database and schema is required for the table-level SELECT grant to be usable.
- C. Adding the consumer account before the share contains any usable objects, and skipping schema- and table-level grants, leaves the consumer with an empty or inaccessible share.
- D. Shares do not take OWNERSHIP grants on tables, and there is no GRANT USAGE ON ACCOUNT statement for registering a consumer; consumer accounts are added with ALTER SHARE ADD ACCOUNTS.
4.Data clean rooms
A plain share gives consumers read access to whatever objects it contains. A data clean room goes further by controlling *what can be done* with the data. In the overview of sharing options, it is the option in which you share data and also control which queries can be run against it.
Snowflake Data Clean Rooms is the built-in way to set these up. It provides a secure environment with several collaborators. Each collaborator shares data, and that data is queried through templates added to the collaboration. Collaborators can approve or reject new templates or data sources proposed by others. All analysis happens inside the clean room. Collaborators get back aggregated results and insights, but cannot query the raw data directly. The collaborator sharing the data defines which analyses the others may run. Query results can be shown directly or activated to a collaborator's Snowflake account, as all collaborators decide.
That makes clean rooms the right answer when parties need to combine and analyse each other's sensitive data, for example to find overlaps, without either side seeing the other's rows. The documentation lists the benefits as enhanced privacy, deeper insights from combined sources, increased security, and private machine learning on combined data.
Checkpoint 6 of 6· Check yourself
Two companies want to analyse their combined customer data. Neither may see the other's raw records, and each must approve the analyses that run. Which option fits?
In a clean room, data is queried only through approved templates and results come back aggregated. A share of tables or views would expose the rows themselves.
“Collaborators can return aggregated results and insights, but can’t directly query the raw data in the clean room.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Because updates to a share are real-time, a table created (or dropped and recreated) in a shared database shows up for consumers automatically.Why is that wrong?
Only changes to objects already granted reach consumers immediately. A new or recreated object must be added explicitly with GRANT <privilege> … TO SHARE.
Covered in What goes into a share: secure objects and explicit grants
2.A consumer of a direct share can reshare the imported data with any external partner.Why is that wrong?
Resharing a direct share is limited to the consumer's own organization, and only when resharing is allowed for that imported database.
Covered in Sharing and resharing
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“a Direct Share, in which you directly share specific database objects (a share) to another account in your region,”
↩︎ Direct shares among the sharing options“You can also convert a direct share to a listing.”
↩︎ Direct shares among the sharing options“If you want to provide a share to many accounts, you might want to use a listing or a data exchange.”
↩︎ Direct shares among the sharing options“a clean room, in which you can share data and control which queries can be run against your data.”
↩︎ Data clean rooms - 2.
“To provide strict control of access to data in a shared database, you must use secure views, secure materialized views and/or secure UDFs.”
↩︎ What goes into a share: secure objects and explicit grants“ensuring that the base tables and business logic are protected from exposure.”
↩︎ What goes into a share: secure objects and explicit grants“For data security and privacy reasons, only secure views are supported in shares at this time.”
↩︎ What goes into a share: secure objects and explicit grants“Do not include secure objects that use the CURRENT_USER or CURRENT_ROLE functions in their definition.”
↩︎ What goes into a share: secure objects and explicit grants“enables you to simulate querying a secure view as a user in any of the consumer account(s)”
↩︎ What goes into a share: secure objects and explicit grants“A new object created or recreated in a database granted to a share is not automatically available to consumers.”
↩︎ What goes into a share: secure objects and explicit grants“A direct share is enabled for resharing within the consumer’s organization only.”
↩︎ Sharing and resharing“you must use the GRANT <privilege> … TO SHARE command to explicitly add the object to the share.”
↩︎ Exam trap 1“A direct share is enabled for resharing within the consumer’s organization only.”
↩︎ Exam trap 2 - 3.
“Run SHOW DATABASES and check the resharing_settings column for the imported database.”
↩︎ Sharing and resharing - 4.
“The provider can turn on or off resharing on their listings to control downstream resharing of their data.”
↩︎ Sharing and resharing“Multi-hop resharing is possible, so a resharer may reshare data that itself has been reshared with them.”
↩︎ Sharing and resharing“CALLER: Each consumer sees only what they themselves are permitted to see from the provider’s data, regardless of what the resharer can see.”
↩︎ Sharing and resharing“Consumer A creates a view that references the shared data and then shares these outgoing views”
↩︎ Checkpoint“The provider doesn’t incur additional costs for this replication. Replication costs are attributed to the resharer.”
↩︎ Checkpoint - 5.
“It offers a secure, multi-collaborator environment where collaborators can share data that can be queried using templates added to the collaboration.”
↩︎ Data clean rooms“Collaborators can review and approve or reject the inclusion of new templates or data sources by other collaborators.”
↩︎ Data clean rooms“can define what analyses are available to the other collaborators, allowing them to tightly control how their data is used”
↩︎ Data clean rooms“They allow you to combine and analyze data from different parties with privacy-preserving configurations that help protect the underlying data.”
↩︎ Data clean rooms“Collaborators can return aggregated results and insights, but can’t directly query the raw data in the clean room.”
↩︎ Checkpoint