Snowflake Replication, Failover & Secure Data Sharing
Day 44 protected data with Time Travel, Fail-safe, and Zero-Copy Cloning. Today moves to sharing data across regions and accounts.
This sub-objective mixes recovery words with collaboration words. The exam separates copying data (replication) from granting access to it (sharing).
| Term | What it sounds like | What it means in Snowflake |
|---|---|---|
| Replication | Making a backup file | Copying a database or account objects to another region or cloud, then keeping the copy in sync. |
| Failover group | A backup that kicks in | A set of objects you can promote in a second account when the first account has an outage. |
| Client Redirect | A web page redirect | A connection URL that can point applications at a different account without changing their code. |
| Share | A file you send | A named object that gives another account read access to your data. Nothing is copied. |
| Provider / consumer | Buyer and seller | The account that offers data, and the account that reads it. |
| Reader account | A free trial login | An account a provider creates and pays for, so a non-Snowflake party can read shared data. |
Replication and Failover: Copies Across Regions
Two scopes of replication
Replication copies objects from a source account to one or more target accounts in the same organization. The copies are called secondary objects. Each secondary is read-only and refreshed on a schedule you set. Replication works across regions and across cloud providers.
The exam tests two scopes. Database replication copies a single database. Account replication copies account objects such as users, roles, and warehouses. Database and share replication are available on every edition. Replication of other account objects needs Business Critical Edition or higher.
| Scope | What it copies | Edition required |
|---|---|---|
| Database replication | One database and its objects | All editions |
| Share replication | Shares and their grants | All editions |
| Account replication | Users, roles, warehouses, more | Business Critical+ |
| Failover and failback | Promotion of secondary to primary | Business Critical+ |
Replication group versus failover group
Two objects drive the feature. A replication group defines what to replicate, where, and how often. A failover group does all of that and also allows promotion of the secondary. Promotion makes the read-only copy a read-write primary during an outage.
Failover groups serve disaster recovery. A planned failover tests readiness in a drill. An unplanned failover responds to a region or cloud outage. Both require Business Critical Edition or higher, the same bar as account-object replication.
Client Redirect keeps the URL stable
Client Redirect gives clients one connection URL that can point at a different account. During an outage you redirect that URL to the account holding the secondary. Applications keep the same URL, so no connection string changes in code. Client Redirect also requires Business Critical Edition or higher.
A common exam framing pairs these features. Replicate critical objects to a second region. Promote the failover group there when the first region fails. Redirect clients to the new primary. That sequence is the standard cross-region recovery path.
Secure Data Sharing: Access Without Copies
No data moves
Secure Data Sharing grants one account read access to another account’s data. No data is copied or transferred between the accounts. Sharing runs entirely through the services layer and the metadata store. The shared data adds no storage to the consumer account.
That metadata-only design is the reason the model is secure. There are no data files crossing the network to intercept. Encryption and secure networks are general Snowflake properties. The defining trait of sharing is that the data itself never moves.
How a share works
The account that offers data is the provider. The account that reads it is the consumer. The provider creates a share, grants objects to it, then adds consumer accounts. The consumer creates one read-only database from each share.
One share can expose objects from several databases, as long as they sit in the same account. A consumer creates exactly one database per share. Every shared object is read-only. The consumer cannot insert, update, or delete shared data.
Secure objects, and cross-database sharing
A share allows secure objects by default. You can share tables, external tables, secure views, secure materialized views, and secure user-defined functions. Non-secure views are blocked unless the share sets SECURE_OBJECTS_ONLY = FALSE. That opt-in exists for views that need query optimization.
To expose data that joins across databases, build a secure view. A secure view hides its definition from the consumer. Its SELECT can reference objects in other databases, so it solves the cross-database case. This is the reason secure views appear so often in sharing questions.
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 VIEW sales_db.public.region_secure_v TO SHARE sales_share;
ALTER SHARE sales_share ADD ACCOUNTS = consumer_account;Direct shares stay in one region
A direct share connects accounts in the same Snowflake region. To reach a consumer in another region or cloud, you replicate the data first or publish a listing. This is where sharing and replication meet. Listings handle the cross-region copy for you, with no manual replication step.
Reader Accounts: Sharing With Non-Snowflake Parties
Sharing works only between Snowflake accounts. A consumer with no Snowflake account cannot read a direct share. A reader account closes that gap. The provider creates it, owns it, and manages it.
The cost model is the exam point. The provider pays for all compute credits a reader account uses, not the consumer. Set a resource monitor on the reader account’s warehouses to cap that spend. A reader account is read-only, so its users cannot load or modify data.
A reader account is a managed account. You create it with CREATE MANAGED ACCOUNT and the TYPE = READER property. It uses the same edition as the provider and sits in the provider’s region. You remove it with DROP MANAGED ACCOUNT.
-- Provider creates and pays for the reader account
CREATE MANAGED ACCOUNT partner_reader
ADMIN_NAME = 'reader_admin',
ADMIN_PASSWORD = 'StrongPass123!',
TYPE = READER;| Aspect | Regular consumer account | Reader account |
|---|---|---|
| Who creates it | The consumer themselves | The provider |
| Who pays compute | The consumer | The provider |
| Snowflake contract | Consumer is a customer | No consumer contract needed |
| Write access | Full DML in their own objects | Read-only on shared data |
Cheat Sheet
| Concept | What to remember | Exam keyword |
|---|---|---|
| Sharing data movement | No data is copied. Metadata only | “no data moves” |
| Consumer cost | Pays compute only, no storage for shared data | “compute only” |
| Cross-database share | Use a secure view that spans databases | “secure view” |
| Shareable objects | Tables, secure views, secure UDFs by default | “secure objects” |
| Reader account payer | Provider pays all reader compute credits | “provider pays” |
| Reader account use | Consumer has no Snowflake account | “non-Snowflake consumer” |
| DB and share replication | Available on every edition | “all editions” |
| Account replication, failover | Business Critical Edition or higher | “Business Critical” |
| Failover group | Promotes a secondary to read-write primary | “promote on outage” |
| Client Redirect | Same connection URL points to another account | “URL stays the same” |
Exam Tip
Sharing never copies data. If a stem asks why Secure Data Sharing is secure, the answer is that no data moves. Options about encryption or secure networks are true of Snowflake in general. They are not the defining trait of sharing, so they are the trap here.
Split replication by scope when an edition appears. Database and share replication run on any edition. Account-object replication, failover and failback, and Client Redirect all need Business Critical Edition or higher. A stem that demotes failover to Standard or Enterprise is using the edition as the catch.
For reader accounts, the payer settles most items. The provider creates the account and pays for every credit it burns. A non-Snowflake consumer gets read-only access with no contract. An option that bills the consumer for reader compute is wrong.
On cross-database sharing, the answer is the secure view. Its definition stays hidden and its SELECT can reference other databases. Regular views are blocked from a share unless SECURE_OBJECTS_ONLY = FALSE is set.
Hands-On Lab
ACCOUNTADMIN role and the shared lab_xs warehouse. This lab creates day45_share_db and lab_share, then drops both. Share creation and inspection are metadata operations. They run on Cloud Services and add no warehouse cost.Build a small throwaway database to share. The warehouse runs the table load only.
USE ROLE ACCOUNTADMIN;
USE WAREHOUSE lab_xs;
CREATE OR REPLACE DATABASE day45_share_db;
CREATE OR REPLACE SCHEMA day45_share_db.public;
CREATE OR REPLACE TABLE day45_share_db.public.regions (
region_id INT,
region_name STRING
);
INSERT INTO day45_share_db.public.regions VALUES
(1, 'AMER'), (2, 'EMEA'), (3, 'APAC');Create a secure view, then build the share. The secure view is the object a real share would expose for privacy.
CREATE OR REPLACE SECURE VIEW day45_share_db.public.regions_v AS
SELECT region_id, region_name FROM day45_share_db.public.regions;
CREATE OR REPLACE SHARE lab_share;
GRANT USAGE ON DATABASE day45_share_db TO SHARE lab_share;
GRANT USAGE ON SCHEMA day45_share_db.public TO SHARE lab_share;
GRANT SELECT ON VIEW day45_share_db.public.regions_v TO SHARE lab_share;Inspect the share. These read-only commands show what a share holds before any account is added.
SHOW SHARES LIKE 'lab_share';
DESCRIBE SHARE lab_share;
SHOW GRANTS TO SHARE lab_share;Look at the replication surface. These commands read metadata only and confirm where replication could target.
SHOW REPLICATION ACCOUNTS;
SHOW REGIONS;Cleanup. Drop the share and the throwaway database, then suspend the shared warehouse.
DROP SHARE lab_share;
DROP DATABASE day45_share_db;
ALTER WAREHOUSE lab_xs SUSPEND;
-- Keep lab_xs itself. It is the shared warehouse reused across days.Practice Questions
Options:
A. No data is transferred during sharing
B. Any transferred data is automatically encrypted
C. Data transfers take place through secure networks
D. The original database owner keeps access control
Why A: Sharing is metadata only. The consumer queries the provider’s data in place, so no files cross the network to be intercepted.
Why not B: Encryption is always on in Snowflake. It is a general property, not what defines sharing as secure.
Why not C: Secure networks also apply to every operation. They do not explain the no-copy design.
Why not D: Owner-controlled access is a result of the metadata model, not its root reason for being secure.
Options:
A. External tables
B. Secure views
C. Materialized views
D. User-defined functions
Why B: A secure view hides its definition and its SELECT can reference objects across databases. That is the standard way to share data spanning more than one database.
Why not A: External tables read files in cloud storage. They do not resolve the cross-database sharing need.
Why not C: A plain materialized view is not the cross-database mechanism. A secure materialized view shares, but the tested answer here is the secure view.
Why not D: A user-defined function returns a value. It is not how a provider exposes joined data from several databases.
Options:
A. The partner, through a separate Snowflake contract
B. The provider that created the reader account
C. Snowflake absorbs reader-account compute
D. Compute is split evenly between both parties
Why B: A reader account is owned and managed by the provider. The provider is billed for every credit the reader account’s warehouses use.
Why not A: The whole point of a reader account is that the partner needs no Snowflake contract.
Why not C: Snowflake does not absorb the compute. The provider does.
Why not D: There is no split model. Reader-account credits land on the provider in full.
Options:
A. Standard Edition
B. Enterprise Edition
C. Business Critical Edition
D. Any edition supports it
Why C: Account-object replication, plus failover and failback, require Business Critical Edition or higher.
Why not A: Standard supports database and share replication, but not account replication or failover.
Why not B: Enterprise also stops short of account replication and failover. The bar is Business Critical.
Why not D: Only database and share replication run on any edition. Account-level replication and failover do not.
Options:
A. A failover group can promote secondary objects in another region to a read-write primary
B. Client Redirect forces every application to change its connection URL after a failover
C. Client Redirect lets clients keep one connection URL that points to a different account
D. Failover groups are available on Standard Edition
E. A direct share fails over to another region on its own
Why A and C: A failover group promotes a read-only secondary to a read-write primary during an outage. Client Redirect keeps the connection URL stable and repoints it to another account.
Why not B: Client Redirect exists so the URL does not change. Applications keep the same string.
Why not D: Failover groups need Business Critical Edition or higher. Re-read Concept 1 if missed.
Why not E: A direct share works only within one region. Cross-region delivery needs replication or a listing.
Snowflake Documentation
Official docs for today’s topics. The exam pulls directly from these.
Today you learned: how Snowflake copies and shares data across regions and accounts. Replication makes read-only secondary copies that refresh on a schedule. Database and share replication run on any edition. Account-object replication, failover and failback, and Client Redirect need Business Critical Edition or higher. A failover group promotes a secondary to a read-write primary during an outage. Client Redirect keeps one connection URL and repoints it. Secure Data Sharing grants read access with no data copied, so the consumer pays compute but no storage. A secure view is the way to share data that references more than one database. A reader account lets a non-Snowflake party read shared data, with the provider paying all compute.
Key takeaway: separate copying from sharing. Replication moves copies and has an edition bar for account-level and failover. Sharing moves no data at all. For the payer, the consumer pays compute on a normal share, while the provider pays compute on a reader account.
Tomorrow (Day 46): Data Clean Rooms, the Snowflake Marketplace, Listings, and Native Apps. You move from private account-to-account sharing to public discovery and privacy-preserving collaboration. Topics include live Marketplace data, listing types, and how clean rooms let two parties analyze overlap without exposing raw data.
