What you will be able to do
- Explain why Secure Data Sharing needs no copying or movement of data, and who pays for what
- Tell apart the provider and consumer roles in a share, and the privileges each one needs
- Create a database from a share and describe what an imported database cannot do
- Say when a reader account is the right choice and what it is limited to
Key concept
Share (Secure Data Sharing) — A share is a named object that a provider account uses to give other accounts read-only access to selected database objects. The data is never copied. Consumers query the provider's data through Snowflake's metadata, so they pay only for the compute they use.
1.How Secure Data Sharing works: no copy, read-only
Secure Data Sharing lets one Snowflake account expose selected objects in its databases to other Snowflake accounts. Nothing is exported, and no files or replicas are made. All sharing runs through Snowflake's services layer and metadata store, and the consumer queries the provider's data where it already lives. This has two effects that the exam returns to often. First, shared data takes up no storage in the consumer account and adds nothing to the consumer's monthly storage bill. Second, setup is quick and access is near-instantaneous, because there is nothing to copy.
The unit of sharing is the share. Shares are named Snowflake objects that hold all the information needed to share a database. The provider adds objects to a share, either by granting privileges on them through a database role or by granting privileges directly to the share. The provider then adds the accounts that may consume it. One share can draw on several databases, as long as they all belong to the same account.
The provider stays in control the whole time. New objects added to a share, and updates to objects already in it, become available to every consumer straight away. Access to the whole share, or to any object in it, can be revoked at any time. On the consumer side, every shared object is read-only. Nothing can be modified or deleted, and that includes adding or changing table data.
Checkpoint 1 of 5· Check yourself
A consumer account has imported a shared database. Which statement is true?
Shared objects cannot be modified, shared data uses no consumer storage, and updates in the share reach consumers immediately rather than as a snapshot.
“All database objects shared between accounts are read-only (i.e. the objects cannot be modified or deleted, including adding or modifying table data).”Source: docs.snowflake.com
Sources1
2.Providers and consumers
Every share has two sides. The account that shares data is the provider, and the account that receives it is the consumer. These are roles an account plays, not kinds of account: any full Snowflake account can both provide and consume. One account can publish shares to partners and import shares from vendors at the same time, and you can even share between your own accounts.
Provider side. A provider can create as many shares as it wants and add as many accounts to each one. Grants give fine-grained control over which objects in a database are exposed. Anyone can prepare the objects to be shared, but creating a share or adding consumer accounts to it needs ACCOUNTADMIN or a role that holds the global CREATE SHARE privilege.
Consumer side. A consumer becomes one by creating a database from a share. That task needs ACCOUNTADMIN or a role that holds the IMPORT SHARE global privilege. SHOW SHARES lists available shares. A share made available to you has INBOUND in the kind column, and an empty database_name means you have not imported it yet. DESC SHARE shows the objects in a share before you import it. The database is then created with special syntax:
CREATE DATABASE <name> FROM SHARE <provider_account>.<share_name>A consumer can import as many shares as it likes, but each share can be consumed only once per account. In other words, one database per share. After import, only the role that created the database can see its objects. Other roles must be granted access through normal role-based access control.
Imported databases have further limits besides being read-only. You cannot clone an imported database or any schema or table in it. Time Travel does not work on them, you cannot edit their comments, and they cannot be replicated.
Checkpoint 2 of 5· Fill the gap
Complete the statement that creates the snow_sales database from the provider's sales_s share.
CREATE DATABASE snow_sales FROM ? xy12345.sales_s;Imported databases use the CREATE DATABASE … FROM SHARE <provider_account>.<share_name> syntax.
Source: docs.snowflake.comCheckpoint 3 of 5· Check yourself
An analyst wants to use Time Travel on a table in a database imported from a share. What happens?
Time Travel is on the list of actions not supported for imported databases, along with cloning and replication.
“Time Travel for an imported database or any schemas/tables in the database.”Source: docs.snowflake.com
3.Reader accounts: sharing with non-Snowflake customers
Sharing works only between Snowflake accounts. So what does a provider do when the party it wants to share with is not a Snowflake customer? It creates a reader account, formerly called a read-only account. A reader account lets that party query the provider's shared data without signing a Snowflake licence and without any setup or usage cost of its own.
The trade-off is that the provider owns everything. The provider creates, owns and manages the reader account, and it pays all credit charges run up by the account's users. Warehouses in a reader account can consume an unlimited number of credits each month, all billed to the provider. A resource monitor is the recommended way to cap that spending. Because the reader account has no licensing agreement with Snowflake, its users cannot use Snowflake support. The provider answers their questions and raises a support ticket itself if needed.
Reader accounts are created with the MANAGED ACCOUNT object. This needs ACCOUNTADMIN or a role that holds the CREATE ACCOUNT global privilege:
CREATE MANAGED ACCOUNT <account_name>
ADMIN_NAME = <username> , ADMIN_PASSWORD = '<password>' ,
TYPE = READER;A new reader account uses the same Snowflake edition as its provider and is created in the same region. Once it is provisioned, the provider adds it to one or more shares and configures it. The consumer-side import steps from the previous section do not apply here: an administrator in the provider account has already done them.
What a reader account can do is deliberately narrow. It can consume data only from the provider account that created it. Its users can query that data, and can do things such as create materialized views. They cannot load, insert, update, delete or merge data, and they cannot create shares, stages, pipes, masking policies or row access policies. By default a provider can create up to 75 reader accounts. A dropped reader account still counts against that limit for its 7-day retention period, and dropping one cannot be undone.
| Aspect | Full consumer account | Reader account |
|---|---|---|
| Who pays for compute | The consumer | The provider that created it |
| Can consume shares from | Any number of providers | Only the provider that created it |
| Snowflake licence and support | Has its own agreement | No agreement; the provider handles support |
| Load or change data (INSERT, COPY INTO <table>) | Yes, in its own databases | No |
| How it is created | Normal Snowflake account | CREATE MANAGED ACCOUNT … TYPE = READER |
Checkpoint 4 of 5· Check yourself
A provider creates a reader account for a partner that is not a Snowflake customer. The partner's users run heavy queries all month. Who is billed for the warehouse credits?
The provider owns the reader account and pays for all credits used in it. That is why a resource monitor is recommended.
“Warehouses in a reader account can consume an unlimited number of credits each month, which will be charged to your provider account.”Source: docs.snowflake.com
Checkpoint 5 of 5· Exam question
A retail analytics team creates a database from a share provided by a supplier. The retail team wants to know what costs to expect on its own Snowflake bill purely from using the shared data. What should it expect?
Correct answer: A — Compute costs when it runs queries against the shared database, since storage for the shared objects is not duplicated into the retail team's account.
- A. Secure Data Sharing exposes the provider's data through metadata rather than copying files, so the consumer only pays for the compute it uses to query the data, not for storage of it.
- B. Data sharing does not copy files into the consumer's account, so no additional storage charge is incurred there; only the compute used to run queries against the shared data is billed to the consumer.
- C. The provider only bears the storage cost of its own data; a consumer's own query compute is billed to the consumer's account, so this understates the consumer's exposure to charges.
- D. There is no replication step and therefore no replication fee; ongoing costs come from the compute the consumer's warehouse uses each time it queries the shared tables.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Sharing a database copies its data into the consumer account, so the consumer pays storage for it.Why is that wrong?
No data is copied or moved. Shared data uses no consumer storage, and the consumer pays only for the compute used to query it.
Covered in How Secure Data Sharing works: no copy, read-only
2.A reader account can import shares from any provider, just like a normal consumer account.Why is that wrong?
A reader account belongs to the provider that created it and can consume data only from that provider.
Covered in Reader accounts: sharing with non-Snowflake customers
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“With Secure Data Sharing, no actual data is copied or transferred between accounts.”
↩︎ How Secure Data Sharing works: no copy, read-only“New objects added to a share become immediately available to all consumers, providing real-time access to imported data.”
↩︎ How Secure Data Sharing works: no copy, read-only“Access to a share (or any of the objects in a share) can be revoked at any time.”
↩︎ How Secure Data Sharing works: no copy, read-only“Any full Snowflake account can both provide and consume imported data.”
↩︎ Providers and consumers“You can consume as many shares as you want from data providers, but you can only create one database per share.”
↩︎ Providers and consumers“Data sharing is only supported between Snowflake accounts.”
↩︎ Reader accounts: sharing with non-Snowflake customers“With Secure Data Sharing, no actual data is copied or transferred between accounts.”
↩︎ Key concept“Shared data does not take up any storage in a consumer account and therefore does not contribute to the consumer’s monthly data storage charges.”
↩︎ Exam trap 1“a reader account can only consume data from the provider account that created it.”
↩︎ Exam trap 2“The only charges to consumers are for the compute resources (i.e. virtual warehouses) used to query the imported data.”
↩︎ Prediction“All database objects shared between accounts are read-only (i.e. the objects cannot be modified or deleted, including adding or modifying table data).”
↩︎ Checkpoint - 2.
“require the ACCOUNTADMIN role or a role granted the global CREATE SHARE privilege”
↩︎ Providers and consumers - 3.
“You must use the ACCOUNTADMIN role (or a role granted the IMPORT SHARE global privilege) to perform these tasks.”
↩︎ Providers and consumers“When a database is created from a share, only the role used to create the database can access objects in the database by default.”
↩︎ Providers and consumers“Imported databases cannot be replicated.”
↩︎ Providers and consumers“If you are using a reader account to consume imported data, you do not need to perform any of these tasks”
↩︎ Reader accounts: sharing with non-Snowflake customers“Time Travel for an imported database or any schemas/tables in the database.”
↩︎ Checkpoint - 4.
“which assumes all responsibility for credit charges incurred by users in the reader account”
↩︎ Reader accounts: sharing with non-Snowflake customers“To limit usage, set up a resource monitor for the warehouse.”
↩︎ Reader accounts: sharing with non-Snowflake customers“The reader account utilizes the same Snowflake Edition as the provider account and is created in the same region.”
↩︎ Reader accounts: sharing with non-Snowflake customers“By default, the total number of reader accounts a provider can create is 75.”
↩︎ Reader accounts: sharing with non-Snowflake customers“Because a reader account does not have a licensing agreement with Snowflake, support services are not available to the general users in the account.”
↩︎ Reader accounts: sharing with non-Snowflake customers“Warehouses in a reader account can consume an unlimited number of credits each month, which will be charged to your provider account.”
↩︎ Checkpoint