What you will be able to do
- Decide whether a data share or a zero-copy clone fits a given requirement
- Create a share with SQL, grant objects to it, add consumer accounts and verify it
- Use secure views to filter shared rows by condition or by consumer account, and test the result as a consumer
Key concept
Share — A share is a named object in the provider account. It records which database objects other accounts may read and which accounts may read them. No data moves: consumers query the provider's data in place through a read-only database that they create from the share.
1.Share or clone: what each one gives you
Secure Data Sharing lets one Snowflake account (the provider) expose selected objects to other accounts (the consumers). You can share databases, tables, dynamic tables, external tables, Iceberg tables, secure views, secure materialized views and UDFs. Nothing is copied. Sharing runs through Snowflake's services layer and metadata store, and the consumer creates a read-only database from the share. Each share can back only one database in a consumer account.
The provider controls a share entirely. Updates to shared objects reach every consumer immediately, and the provider can revoke access to the share, or to any object in it, at any time. That makes a share the right tool when another account needs live, read-only access to data you keep maintaining.
A clone answers a different need. CREATE <object> … CLONE creates a copy of an existing object. It is mainly used to create zero-copy clones of databases, schemas and tables, and for those objects it can also clone from a point in the past using Time Travel. Use a clone when you want your own copy of an object, for example a snapshot at a given time. Use a share when a separate account must read the provider's current data without receiving a copy.
| Account type | Can consume from | Can load or modify data | Who pays for it |
|---|---|---|---|
| Full Snowflake account | Any provider; it can also be a provider itself | Yes in its own databases; imported objects are read-only | The account's own Snowflake customer |
| Reader account | Only the provider account that created it | No DML such as data loading, insert or update | The provider account that owns it |
Reader accounts cover the case where a consumer has no Snowflake account. The provider creates and pays for the reader account, and shares databases with it through ordinary shares.
Checkpoint 1 of 6· Check yourself
A partner in another Snowflake account in your region needs read-only access to an order table that your pipelines update hourly. They must always see the latest rows. What fits best?
A share gives another account live, read-only access without copying anything, and changes reach consumers immediately. A clone is a separate copy that falls behind the source.
“Updates to existing objects in a share become immediately available to all consumers.”Source: docs.snowflake.com
Checkpoint 2 of 6· Exam question
A retailer's finance team needs a nightly, fully independent snapshot of the `SALES` database so they can run destructive what-if transformations without affecting the source or any other consumer, and without needing live updates from production. Which mechanism should the data engineer choose over Secure Data Sharing?
Correct answer: A — Zero-copy cloning, because it creates an independent, writable copy of the database that can be freely modified without touching production data
- A. Zero-copy cloning is correct because CLONE creates a metadata-only copy that diverges immediately once either side is modified, giving the finance team a fully independent, writable dataset without live coupling to production, which is exactly what destructive what-if work requires.
- B. A share only grants read access to the provider's live objects; consumers cannot write back into the shared database, and any changes on the provider side would still propagate through the read-only reference, so it does not give the isolated, mutable snapshot the finance team needs.
- C. Reader accounts are provisioned by the provider for consumers who have no Snowflake account of their own, and they only ever get read-only access to the data shared with them; they never receive write access to the provider's storage.
- D. Snowpipe Streaming ingests new rows into a table via the streaming API; it is a continuous ingestion mechanism, not a way to produce an isolated writable point-in-time copy, and it would still leave the finance team dependent on an ongoing pipeline rather than a standalone dataset.
2.Implementing a share with SQL
Any role can prepare the objects you plan to share. Creating a share and adding consumer accounts to it needs the ACCOUNTADMIN role or a role with the global CREATE SHARE privilege. The SQL procedure has three steps: create an empty share, grant privileges on objects to it, then add accounts.
CREATE SHARE sales_s;You can grant privileges to the share directly, or grant them to a database role and then grant that database role to the share. For direct grants, work from the outside in: grant USAGE on the database first, then on the schema, then SELECT on the table. Shared database roles do not support future grants.
GRANT USAGE ON DATABASE sales_db TO SHARE sales_s; GRANT USAGE ON SCHEMA sales_db.aggregates_eula TO SHARE sales_s; GRANT SELECT ON TABLE sales_db.aggregates_eula.aggregate_1 TO SHARE sales_s;Run SHOW GRANTS TO SHARE sales_s to confirm what the share contains before anyone can see it. Then add the consumers with ALTER SHARE. Check the account names carefully: if you name an account that does not exist, the command still succeeds but the share is not updated. SHOW SHARES lists the share with kind OUTBOUND and shows the consumer accounts in its to column. SHOW GRANTS OF SHARE shows which of those accounts are using it.
Checkpoint 3 of 6· Fill the gap
Which keyword completes the statement that makes the share visible to two consumer accounts?
ALTER SHARE sales_s ADD ? =xy12345, yz23456;ALTER SHARE … ADD ACCOUNTS adds consumer accounts to a share. After it runs, those accounts can see the share and create a database from it.
Source: docs.snowflake.comLater changes to a share behave differently depending on what changes. New and modified rows in objects that are already shared reach consumers immediately, and so do objects you explicitly grant to the share. An object you create, or drop and recreate, in the shared database is a new object, and it is not shared until you grant it to the share again.
Checkpoint 4 of 6· Put it in order
Put these steps for sharing one table in the order the documentation requires
- 1.CREATE SHARE sales_s
- 2.ALTER SHARE sales_s ADD ACCOUNTS=xy12345, yz23456
- 3.GRANT USAGE ON DATABASE sales_db TO SHARE sales_s
- 4.GRANT USAGE ON SCHEMA sales_db.aggregates_eula TO SHARE sales_s
- 5.GRANT SELECT ON TABLE sales_db.aggregates_eula.aggregate_1 TO SHARE sales_s
Grant USAGE on a container before the objects inside it. Grant the objects before adding accounts, because adding an account before the database usage grant fails.
“Attempting to add an account before granting usage on a database results in an error.”Source: docs.snowflake.com
Sources3
3.Secure views and row-level filtering in shares
If you share whole databases or tables, little or no preparation is needed. To share only part of a table, filtered by a condition such as date or by consumer account, you must create secure views. Secure objects, meaning secure views, secure materialized views and secure UDFs, let you choose exactly which data consumers see and keep the base tables and business logic hidden. You define them with the usual CREATE or ALTER commands for that object type.
Shares accept only secure views. Adding a standard view to a share returns an error. A secure view that references a table by its fully qualified name can be shared only if that database name matches the share's database. To add a view that references objects in other databases, create the share with SQL; the Snowsight interface does not support it.
Checkpoint 5 of 6· Check yourself
A provider grants SELECT on an ordinary (non-secure) view to a share. What happens?
For data security and privacy reasons, shares currently accept only secure views.
“If a standard view is added to a share, Snowflake returns an error.”Source: docs.snowflake.com
With a single share you can partition data across consumer accounts. Snowflake's sample script tags each row of the sensitive table with an access_id, then fills a second table that maps access groups to account names. Do not filter with CURRENT_USER or CURRENT_ROLE. Their values have no meaning in a consumer's account, and an object that uses them fails when the consumer queries it.
create or replace table mydb.private.sharing_access ( access_id string, snowflake_account string ); /* In the first insert, CURRENT_ACCOUNT() gives your account access to the AAPL and MSFT data. */ insert into mydb.private.sharing_access values('STOCK_GROUP_1', CURRENT_ACCOUNT());Before you share the view, confirm that each consumer sees only what you intend. Set the SIMULATED_DATA_SHARING_CONSUMER session parameter to a consumer account, then query the view from your own account as if you were that consumer.
ALTER SESSION SET SIMULATED_DATA_SHARING_CONSUMER = xy12345;If consumers will build streams on what you share, you have to prepare the source tables. Enable CHANGE_TRACKING on each shared table, or on the tables under a shared view. Also set DATA_RETENTION_TIME_IN_DAYS yourself, because a stream on a shared object does not extend retention.
Checkpoint 6 of 6· Check yourself
Which shared object can you test with SIMULATED_DATA_SHARING_CONSUMER?
The parameter simulates a consumer querying secure views and secure materialized views. It does not work with secure UDFs.
“The SIMULATED_DATA_SHARING_CONSUMER session parameter only supports secure views and secure materialized views, but does not support secure UDFs.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Once a database is in a share, any table you later create in it, or drop and recreate, is shared automatically.Why is that wrong?
A new or recreated object is not available to consumers until you grant it to the share explicitly with GRANT … TO SHARE.
Covered in Implementing a share with SQL
2.If ALTER SHARE … ADD ACCOUNTS succeeds, the consumers now have the share.Why is that wrong?
A misspelled or nonexistent account name does not raise an error, and the share stays unchanged. Check the account names and confirm the result with SHOW SHARES.
Covered in Implementing a share with SQL
3.To filter rows per consumer in a shared secure view, filter on CURRENT_ROLE() or CURRENT_USER().Why is that wrong?
Those values mean nothing in the consumer's account, and the view fails when queried. Map rows to consumer accounts with CURRENT_ACCOUNT() instead.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“The only charges to consumers are for the compute resources (i.e. virtual warehouses) used to query the imported data.”
↩︎ Share or clone: what each one gives you“you can only create one database per share”
↩︎ Share or clone: what each one gives you“a reader account can only consume data from the provider account that created it”
↩︎ Share or clone: what each one gives you“Shares are named Snowflake objects that encapsulate all of the information required to share a database.”
↩︎ Key concept“Shared data does not take up any storage in a consumer account”
↩︎ Prediction“Updates to existing objects in a share become immediately available to all consumers.”
↩︎ Checkpoint - 2.
“This command is primarily used for creating zero-copy clones of databases, schemas, and tables.”
↩︎ Share or clone: what each one gives you“For databases, schemas, and non-temporary tables, CLONE supports an additional AT | BEFORE clause for cloning using Time Travel.”
↩︎ Share or clone: what each one gives you - 3.
“require the ACCOUNTADMIN role or a role granted the global CREATE SHARE privilege”
↩︎ Implementing a share with SQL“The kind column indicates that the share is OUTBOUND, meaning this share is sharing a database with other Snowflake accounts.”
↩︎ Implementing a share with SQL“you can decide to use a single share to partition shared data for different consumer accounts”
↩︎ Secure views and row-level filtering in shares“you must ensure that the referenced database name matches the database for the share”
↩︎ Secure views and row-level filtering in shares“A stream on a shared table does not extend the data retention period for the table.”
↩︎ Secure views and row-level filtering in shares“A new object created or recreated in a database granted to a share is not automatically available to consumers.”
↩︎ Exam trap 1“When adding accounts to a share, if the accounts do not exist, the command completes successfully, but no updates are made to the share.”
↩︎ Exam trap 2“Do not include secure objects that use the CURRENT_USER or CURRENT_ROLE functions in their definition.”
↩︎ Exam trap 3“Attempting to add an account before granting usage on a database results in an error.”
↩︎ Checkpoint“If a standard view is added to a share, Snowflake returns an error.”
↩︎ Checkpoint“The SIMULATED_DATA_SHARING_CONSUMER session parameter only supports secure views and secure materialized views, but does not support secure UDFs.”
↩︎ Checkpoint - 4.
“data that maps the stock data to individual accounts”
↩︎ Secure views and row-level filtering in shares“CURRENT_ACCOUNT() gives your account access to the AAPL and MSFT data.”
↩︎ Prediction