What you will be able to do
- Choose between a direct share, a listing, a data exchange and a clean room for a given sharing scenario
- Create a share, add objects to it directly or through database roles, add consumer accounts, and maintain it over time
- Use secure views, secure UDFs and context functions such as CURRENT_ACCOUNT to filter shared data per consumer
- Explain how replication and Cross-Cloud Auto-fulfillment carry shared data across regions, clouds and editions
Key concept
Share (zero-copy sharing) — A share is a named object, owned and controlled by the provider, that grants other accounts read-only access to selected database objects. The data stays where it is: consumers query it in place and pay only for the compute they use.
1.Sharing models: who you share with and how
Every sharing scenario has two roles. The provider creates shares. The consumer creates a read-only database from a share. Any full Snowflake account can act as both. Because nothing is copied, shared data uses no storage in the consumer account. The consumer pays only for the warehouses that query it, and the provider keeps paying to store the data.
Snowflake offers four ways to deliver a share, and exam scenarios usually come down to choosing between them. A direct share is the simplest one-to-one or one-to-few model, but it works only within one region. Once the audience grows, Snowflake suggests a listing or a data exchange. A listing is also how you go *public*: it is the option that can publish to the Snowflake Marketplace, charge for access or carry descriptive metadata. A listing can also reach other regions through Cross-Cloud Auto-fulfillment. A direct share can reach other regions too, but only through the replication-based approach taught later on this page. A clean room is for cases where you need to control which queries run against your data, not just which objects are visible.
Private versus public. A listing offered to specific consumer accounts is a *private* listing. A listing on the Snowflake Marketplace is *public*. A data exchange is a managed group of accounts that you set up, so it is private by nature. For all three, the provider gets consumer usage metrics, which a plain direct share does not offer. Two later topics matter for these scenarios: secure views, which are taught in the secure objects section below, and REFERENCE_USAGE, a privilege for sharing data that spans several databases, which is covered in the outbound share section.
| Option | What it is | Typical fit |
|---|---|---|
| Direct Share | Specific database objects shared to another account in your region | Private, one-to-one or one-to-few, same region |
| Listing | A share plus metadata offered as a data product to one or more accounts | One-to-many, cross-region, public Marketplace or paid access |
| Data Exchange | A group of accounts you set up and manage, offered a share | Private one-to-many within a managed group |
| Clean room | Share data and control which queries can be run against it | Joint analysis without exposing raw rows |
Checkpoint 1 of 7· Check yourself
A provider wants to sell a dataset publicly to unknown buyers and show them sample queries. Which option fits?
Of these options, only a listing can publish publicly on the Marketplace, charge for access and carry metadata such as sample queries.
“Use a listing when you want to share across regions, offer data publicly on the Snowflake Marketplace, charge for access,”Source: docs.snowflake.com
Checkpoint 2 of 7· Exam question
A provider administrator wants to add a standard view, which joins the `orders` and `customers` tables, to an outbound share. The consumer must not be able to read the view definition. What is the MOST appropriate approach?
Correct answer: C — Recreate it with CREATE SECURE VIEW and grant SELECT on that secure view to the share, plus the needed USAGE grants
- A. Incorrect. A standard view cannot be added to a share regardless of the share's SECURE_OBJECTS_ONLY setting, and exposing the definition would also leak the join logic.
- B. Incorrect. Stored procedures are not shareable object types, so a consumer cannot call one through an outbound share.
- C. Correct. Only secure views (not standard views) can be shared, and a secure view hides its definition from consumers. The share also needs USAGE on the database and schema.
- D. Incorrect. Only secure materialized views can be shared; a regular materialized view is rejected, and a materialized view cannot join two tables anyway.
Sources1
2.Creating and maintaining an outbound share
Any role can prepare objects for sharing. Creating the share and adding consumers needs ACCOUNTADMIN or a role with the global CREATE SHARE privilege. The role that grants objects to the share must also own the database, or hold USAGE on it WITH GRANT OPTION.
You can add objects in two ways. Option 1 grants privileges to a database role and then grants that role to the share. Consumers can then give different shared database roles to different local roles. Option 2 grants privileges directly to the share. Option 2 is required if the share spans several databases, because REFERENCE_USAGE cannot be granted to a database role. In the documented multi-database pattern, a view lives in a main database and references objects in another. The provider grants USAGE on the main database to the share and REFERENCE_USAGE on the referenced database to the share, then grants USAGE on the schema and SELECT on the view. A share can combine both options. Either way, the share needs USAGE on the database. The SQL sequence below is the programmatic way to configure a share.
GRANT DATABASE ROLE d1.r1 TO SHARE share1;
GRANT DATABASE ROLE d1.r2 TO SHARE share1;Checkpoint 3 of 7· Put it in order
Put the provider's steps for the database-role sharing example in order
- 1.GRANT USAGE ON DATABASE d1 TO SHARE share1;
- 2.CREATE SHARE share1;
- 3.ALTER SHARE share1 ADD ACCOUNTS = org1.consumer1,org1.consumer2;
- 4.GRANT DATABASE ROLE d1.r1 TO SHARE share1;
The share starts as an empty container. The database is added first with USAGE, then the objects via database roles, and finally the consumer accounts.
“Create a share using CREATE SHARE. The share is an empty container at this stage in the process.”Source: docs.snowflake.com
Maintenance. As soon as an account is added, the share is available to it. New and changed rows show up for consumers right away. A *new* object does not, and that includes an object you dropped and recreated under the same name. You must grant it to the share again. Use SHOW GRANTS TO SHARE to list what a share exposes and SHOW GRANTS OF SHARE to list its consumer accounts. You can revoke access to the share, or to any object in it, at any time. Removing an account cuts off its access immediately. One more fact applies to the consumer side: a shared database role does not support future grants.
Editions and reader accounts. Consumers who have no Snowflake account can be given a reader account, which the provider creates and pays for. A reader account uses the same Snowflake edition as the provider account and is created in the same region. So the edition of a reader account is the provider's edition, not a separate choice. Sharing between full accounts of different editions is covered in the cross-region section, including the special case of a Business Critical provider.
3.Secure views, secure UDFs and context functions
Sharing a whole table is fine when every consumer should see every row. To filter by date, by condition or by consumer account, you need secure views, secure materialized views and/or secure UDFs. These keep the base tables and business logic hidden from consumers. On standard views, the documentation looks inconsistent. The sharing-intro and provider pages list "Regular views" among the object types you can share. The same provider page also says that, for data security and privacy reasons, only secure views are supported in shares at this time, and that adding a standard view returns an error. The sources do not reconcile the two. For the exam, treat a secure view as the answer whenever a scenario shares a view. Do not rely on a standard view being accepted.
The documented pattern uses a private schema and a public schema. The private schema holds the base table plus a *mapping table* that links an access ID to account names. The public schema holds the secure view, and only the public schema is shared. The view joins to the mapping table on sa.snowflake_account = current_account(). Because CURRENT_ACCOUNT evaluates to the querying consumer's account, one share can serve each consumer a different set of rows.
That logic works because the account means something on both sides. CURRENT_USER and CURRENT_ROLE do not: their values have no meaning in a consumer's account, and secure objects that use them fail when queried. IS_ROLE_IN_SESSION is no substitute, because it returns NULL when used in a shared object such as a secure view accessed from a consumer account. When the requirement is role-based access to shared, policy-protected data, the documented tool is IS_DATABASE_ROLE_IN_SESSION. The provider writes a masking or row access policy that checks a shared database role, then grants that role to the share.
Secure UDFs. User-defined functions, secure and non-secure, are on the list of shareable objects. For strict control of access, the provider documentation names secure UDFs alongside secure views and secure materialized views. Secure objects are defined with the usual CREATE or ALTER commands for that object type, and they are added to a share with the same GRANT <privilege> ... TO SHARE command used for other objects. The same rule on context functions applies to them. For very large base tables, define clustering keys so that consumers of shared secure views or secure UDFs are not slowed down. One related limit: if a policy on a shared table calls a secure UDF, Snowflake returns NULL for the UDF in the consumer account. The sources give no worked CREATE SECURE FUNCTION example, and they do not state a rule for when a secure UDF is preferable to a secure view, so none is claimed here. What they do say is that both hide the base tables and logic.
Before you add consumers, validate that a per-account view returns only what each consumer should see. Set the session parameter to a consumer account name, query the secure view, and you get the rows that consumer would get.
Checkpoint 4 of 7· Fill the gap
Which session parameter lets a provider query a secure view as consumer account xy12345 would see it?
ALTER SESSION SET ? = xy12345;SIMULATED_DATA_SHARING_CONSUMER simulates a consumer account in the current session. It works for secure views and secure materialized views.
Source: docs.snowflake.comCheckpoint 5 of 7· Check yourself
A provider's shared secure view filters rows with CURRENT_ROLE(). What happens when consumers query it?
CURRENT_USER and CURRENT_ROLE values are meaningless in a consumer account, so shared secure objects that use them fail. Filter on CURRENT_ACCOUNT, or on shared database roles, instead.
“Do not include secure objects that use the CURRENT_USER or CURRENT_ROLE functions in their definition.”Source: docs.snowflake.com
4.Across regions, clouds and editions
A direct share stops at the region boundary. There are two ways past it, and both rely on replication. In the manual approach, the provider replicates a primary database into its own account in the consumer's region, on AWS, GCP or Azure, and shares from there. Only one copy is needed per region, not one per consumer. If a shared view references objects in other databases, each of those databases must be included in the replication group. Replicating a database that has such cross-database references on its own can leave dangling references, so keep related databases together in one group. Check for legal or regulatory limits before replicating data into another country. The sources point to the replication documentation for the commands. They do not walk through enabling replication or building a replication group for sharing, so this lesson does not either.
The automated approach is Cross-Cloud Auto-fulfillment for listings. Snowflake fulfills the data product to a region automatically, and the provider pays transfer and storage costs only when there is consumer demand there. The provider must choose a refresh frequency of at most 8 days. A private listing to a consumer in another region requires auto-fulfillment. If you share only within one region, do not enable it. If auto-fulfillment cannot be used, the provider can choose manual fulfillment instead: set up accounts in the regions with demand, replicate the product to each one, create shares there and attach them to the listing. For listings defined as code, the manifest declares auto-fulfillment like this:
auto_fulfillment:
refresh_schedule: 10 MINUTE
refresh_type: SUB_DATABASEGovernance travels with replication. Masking policies and their assignments can be replicated through database replication and replication groups. This is also where editions matter. If the primary database sits in an Enterprise (or higher) account and contains a policy, replication fails when any target account is on a lower edition. For Business Critical providers, sharing with non-Business Critical accounts is something you must request from Snowflake before it is enabled. Snowflake recommends not sharing sensitive data with non-Business Critical accounts, though it does not enforce this. One option is a separate non-Business Critical account that holds the less sensitive data for sharing. Note that these sources do not describe a feature named "Cross-cloud Data Governance". The mechanisms above (policy replication, shared database roles and secure objects) are what they do document, so this lesson does not assert further detail about it.
Checkpoint 6 of 7· Check yourself
A provider in AWS us-west wants to share with a consumer account in Azure West Europe. What is wrong with simply adding the account to an existing direct share?
A direct share works only between accounts in the same region. To cross regions or clouds, replicate the data or use a listing with Cross-Cloud Auto-fulfillment.
“A direct share works only with accounts in the same region.”Source: docs.snowflake.com
Checkpoint 7 of 7· Exam question
A provider keeps curated tables in database `ANALYTICS`, and a secure view in `ANALYTICS` reads a table from a second database, `RAW_DB`. Granting SELECT on the view to a share fails. Which action resolves the failure while exposing only the view?
Correct answer: A — Grant REFERENCE_USAGE on `RAW_DB` to the share, then grant SELECT on the secure view to that share
- A. Correct. A secure view that references objects in another database requires REFERENCE_USAGE on that database to be granted to the share first. This lets the view resolve without exposing the underlying table.
- B. Incorrect. This would publish the raw tables to consumers, which the provider does not want. The view only needs a reference grant on the database, not table access.
- C. Incorrect. IMPORTED PRIVILEGES is a privilege granted on a database created from a share, to roles in the consumer account. It does not apply to a share object.
- D. Incorrect. A database cannot be cloned into a schema, and ownership of objects is never granted to a share.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.If I drop and recreate a shared table with the same name, consumers keep seeing it.Why is that wrong?
A recreated object counts as new and must be granted to the share again with GRANT ... TO SHARE.
Covered in Creating and maintaining an outbound share
2.A shared secure view can filter rows per consumer user with CURRENT_USER().Why is that wrong?
CURRENT_USER and CURRENT_ROLE values have no relevance in a consumer account, so the object fails. Per-consumer filtering uses CURRENT_ACCOUNT with a mapping table.
3.Sharing to ten consumers in another region needs ten replicated copies.Why is that wrong?
Cross-region sharing needs one replicated copy of the dataset per region, however many consumers are there.
Covered in Across regions, clouds and editions
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,”
↩︎ Sharing models: who you share with and how“If you want to provide a share to many accounts, you might want to use a listing or a data exchange.”
↩︎ Sharing models: who you share with and how“a clean room, in which you can share data and control which queries can be run against your data.”
↩︎ Sharing models: who you share with and how“If you provide listings privately, using a data exchange, or on the Snowflake Marketplace, you have access to various metrics”
↩︎ Sharing models: who you share with and how“Removing an account from a share immediately removes that account’s access to the shared data.”
↩︎ Creating and maintaining an outbound share“Views Regular views Secure views Secure materialized views Semantic views”
↩︎ Secure views, secure UDFs and context functions“With Secure Data Sharing, no actual data is copied or transferred between accounts.”
↩︎ Key concept“Use a listing when you want to share across regions, offer data publicly on the Snowflake Marketplace, charge for access,”
↩︎ Checkpoint“A direct share works only with accounts in the same region.”
↩︎ Checkpoint - 2.
“require the ACCOUNTADMIN role or a role granted the global CREATE SHARE privilege.”
↩︎ Creating and maintaining an outbound share“If a standard view is added to a share, Snowflake returns an error.”
↩︎ Secure views, secure UDFs and context functions“To provide strict control of access to data in a shared database, you must use secure views, secure materialized views and/or secure UDFs.”
↩︎ Secure views, secure UDFs and context functions“User-defined functions (UDFs) (secure and non-secure)”
↩︎ Secure views, secure UDFs and context functions“before requesting Snowflake to enable Secure Data Sharing with non-Business Critical accounts”
↩︎ Across regions, clouds and editions“Do not share sensitive data with non-Business Critical accounts.”
↩︎ Across regions, clouds and editions“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“The SIMULATED_DATA_SHARING_CONSUMER session parameter only supports secure views and secure materialized views, but does not support secure UDFs.”
↩︎ Prediction“Do not include secure objects that use the CURRENT_USER or CURRENT_ROLE functions in their definition.”
↩︎ Checkpoint - 3.
“the REFERENCE_USAGE privilege cannot be granted to a database role to include objects from multiple databases in a share.”
↩︎ Creating and maintaining an outbound share“Create a share using CREATE SHARE. The share is an empty container at this stage in the process.”
↩︎ Checkpoint - 4.
“The reader account utilizes the same Snowflake Edition as the provider account and is created in the same region.”
↩︎ Creating and maintaining an outbound share - 5.
“or the policy conditions call a secure UDF, Snowflake returns a NULL value for the function or the UDF in the consumer account.”
↩︎ Secure views, secure UDFs and context functions“Masking policies and their assignments can be replicated using database replication and replication groups.”
↩︎ Across regions, clouds and editions - 6.
“This function returns NULL when used in a shared object, such as a secure view, when accessed through a data sharing consumer account.”
↩︎ Secure views, secure UDFs and context functions - 7.
“In the first insert, CURRENT_ACCOUNT() gives your account access to the AAPL and MSFT data.”
↩︎ Secure views, secure UDFs and context functions - 8.
“The provider defines the policy to call the IS_DATABASE_ROLE_IN_SESSION function to evaluate the shared database role”
↩︎ Secure views, secure UDFs and context functions - 9.
“Since cross-region data sharing utilizes Snowflake data replication functionality”
↩︎ Across regions, clouds and editions“each of these other databases must be included in the replication group.”
↩︎ Across regions, clouds and editions“Data providers only need to create one copy of the dataset per region; and not a copy per consumer.”
↩︎ Exam trap 3 - 10.
“you incur costs only when there is consumer demand in that region.”
↩︎ Across regions, clouds and editions“You must select a refresh frequency of a maximum of 8 days.”
↩︎ Across regions, clouds and editions“If you can’t use auto-fulfillment, select Manual to manually replicate your data product.”
↩︎ Across regions, clouds and editions