6.2 Creating Shares, Granting Objects, and Reader Accounts

SnowPro Core Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: SnowPro Core Orientation and Exam Strategy

1.1 Current SnowPro Core Exam Facts 1.2 Eligibility, Registration, and Scheduling 1.3 Blueprint Domains and Weighting 1.4 Editions, Question Style, and Score Report Thinking 1.5 Study Calendar and Hands-On Practice Plan

2 Chapter 2: Snowflake AI Data Cloud Features and Architecture

2.1 Snowflake AI Data Cloud Features and Architecture Overview 2.2 Core Workflows and Decision Points 2.3 Scenario Practice for Snowflake AI Data Cloud Features and Architecture 2.4 Common Traps in Snowflake AI Data Cloud Features and Architecture 2.5 Practice Drills and Readiness Markers

3 Chapter 3: Account Management and Data Governance

3.1 Account Management and Data Governance Overview 3.2 Core Workflows and Decision Points 3.3 Scenario Practice for Account Management and Data Governance 3.4 Common Traps in Account Management and Data Governance 3.5 Practice Drills and Readiness Markers

4 Chapter 4: Data Loading, Unloading, and Connectivity

4.1 Data Loading, Unloading, and Connectivity Overview 4.2 Core Workflows and Decision Points 4.3 Snowpipe, External Tables, and Storage Integrations 4.4 Bulk Unloading and Semi-Structured Data 4.5 Connectors, Drivers, and Snowsight Loading

5 Chapter 5: Performance Optimization, Querying, and Transformation

5.1 Performance Optimization, Querying, and Transformation Overview 5.2 Core Workflows and Decision Points 5.3 Micro-Partitions, Pruning, Clustering, and the Query Profile 5.4 Search Optimization, Materialized Views, and Query Best Practices 5.5 Transformations: ELT, Streams & Tasks, and Semi-Structured Data

6 Chapter 6: Data Collaboration

6.1 Secure Data Sharing Architecture 6.2 Creating Shares, Granting Objects, and Reader Accounts 6.3 Snowflake Marketplace, Listings, and Data Exchange 6.4 Secure Views, Cross-Region Sharing, and Governance 6.5 Choosing the Right Sharing Method and Readiness Drills

7 Chapter 7: Final Review and Test Day

7.1 Timed Practice Strategy 7.2 Last-Week Review Map 7.3 Exam-Day Checklist 7.4 After the Exam and Next Steps

6.2 Creating Shares, Granting Objects, and Reader Accounts

Key Takeaways Explain This Topic AI

Creating a share follows a fixed order: CREATE SHARE, GRANT USAGE on database/schema then SELECT on objects, then ALTER SHARE ADD ACCOUNTS.

A consumer accesses shared data by running CREATE DATABASE ... FROM SHARE, which creates a read-only pointer database.

Reader accounts let non-Snowflake parties consume data; they are provider-managed and the provider pays their compute credits.

Each reader account belongs to exactly one provider and can only consume from the provider that created it.

Last updated: October 2026

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:

CREATE SHARE sales_share;
GRANT USAGE ON DATABASE sales_db TO SHARE sales_share;
GRANT USAGE ON SCHEMA sales_db.public TO SHARE sales_share;
GRANT SELECT ON TABLE sales_db.public.orders TO SHARE sales_share;
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 provider can share data from multiple databases in one share, as long as those databases belong to the same account, and can add multiple consumer accounts to one share.

When to use secure objects

Snowflake's current list of shareable objects includes regular views, secure views, secure materialized views, and both secure and non-secure UDFs. Use a secure view or secure UDF when the consumer must not see the SQL definition: secure objects hide their definition and restrict optimizations that could let a consumer infer the structure of base tables they were not granted. Older study materials say only secure views can be shared; that rule is out of date.

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.

Step Who runs it Effect
CREATE SHARE Provider Defines the share object
GRANT ... TO SHARE Provider Adds objects to the share
ALTER SHARE ADD ACCOUNTS Provider Authorizes consumer accounts
CREATE DATABASE FROM SHARE Consumer Creates read-only pointer DB
GRANT IMPORTED PRIVILEGES Consumer Lets other roles query it

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.

Characteristic Standard consumer Reader account
Needs own Snowflake account Yes No
Pays its own compute Yes No — provider pays
Can consume from many providers Yes No — only its creating provider
Managed by Itself The provider

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

Recipient situation Recommended object
Recipient already has a Snowflake account, same region Standard consumer via direct share
Recipient is not a Snowflake customer Reader account (provider pays compute)
Recipient is in another region or cloud Listing built on replication

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.