6.2 Creating Shares, Granting Objects, and Reader Accounts

Creating and Configuring a Share

As a provider you build a share with a deterministic sequence of privilege grants. The order matters because USAGE on the container (database, then schema) must precede SELECT on the contained objects. A typical flow:

1. CREATE SHARE sales_share;
2. GRANT USAGE ON DATABASE sales_db TO SHARE sales_share;
3. GRANT USAGE ON SCHEMA sales_db.public TO SHARE sales_share;
4. GRANT SELECT ON TABLE sales_db.public.orders TO SHARE sales_share;
5. ALTER SHARE sales_share ADD ACCOUNTS = consumer_acct;

Only the ACCOUNTADMIN role, or a role granted the CREATE SHARE global privilege, can create and manage shares. A single database can be added to a share, but you cannot add objects from more than one database to the same share — each share is rooted in a single database. You can, however, add multiple consumer accounts to one share.

Secure objects are mandatory

When sharing a view or UDF, you must use a secure view or secure UDF. Regular (non-secure) views cannot be granted to a share. Secure objects hide their SQL definition and query plan from the consumer, preventing them from inferring the structure of base tables they were not granted. This requirement is heavily tested: if a share must include a view, it must be a secure view.

How the Consumer Accesses the Share

On the consumer side, an ACCOUNTADMIN (or a role with IMPORT SHARE / CREATE DATABASE privilege) creates a database from the inbound share:

CREATE DATABASE shared_sales FROM SHARE provider_acct.sales_share;

This new database is a read-only pointer — it consumes no storage and is queried with the consumer's own warehouse. The consumer can grant access to other roles in its account via GRANT IMPORTED PRIVILEGES ON DATABASE shared_sales TO ROLE analyst;. Consumers see live data instantly; any change the provider makes to the source is immediately visible.

A share can be granted to multiple consumers at once, and all of them read the same live data with no additional storage anywhere.

Reader Accounts

A reader account (formerly "read-only account") lets a provider share data with a party that does not have its own Snowflake account. The provider creates the reader account with CREATE MANAGED ACCOUNT, and that reader account is wholly provider-managed: it belongs to the provider's account, appears in the provider's organization, and can only consume data from the provider that created it.

The billing model flips here. For a reader account, the provider pays all compute credits the reader's warehouses consume, in addition to storage. This is the opposite of a standard consumer (who pays its own compute), and it is a classic exam contrast.

Use a reader account when the recipient is not a Snowflake customer and you are willing to absorb their compute cost in exchange for fully controlling their environment. The provider creates warehouses, users, and roles within the reader account on the recipient's behalf.

Managing Reader Accounts and Revoking Access

Because a reader account is created with CREATE MANAGED ACCOUNT, the provider receives the new account's URL and initial credentials and is responsible for everything inside it. The provider must create at least one virtual warehouse in the reader account (consumers in a reader account still need compute to query), set up users and roles, and then share databases to the reader account exactly as it would to any consumer. To control costs, the provider should attach resource monitors to the reader account's warehouses, since the provider is paying for that compute.

Revoking access is a core operational skill the exam may probe. A provider stops sharing in one of several ways:

• Remove a consumer from a share: ALTER SHARE sales_share REMOVE ACCOUNTS = consumer_acct;
• Revoke an object from the share: REVOKE SELECT ON TABLE ... FROM SHARE sales_share;
• Drop the share entirely: DROP SHARE sales_share;

Each of these takes effect immediately and removes the consumer's ability to query the affected objects, but none of them deletes any data — the provider's source tables are untouched. This reinforces the no-copy model: access is purely a metadata grant that can be added or removed instantly.

When to choose each consumer type

The key contrast to lock in: a standard consumer pays its own compute and can consume from many providers, whereas a reader account is provider-paid, provider-managed, and tied to a single provider. Many exam items hinge entirely on that distinction.