What you will be able to do
- Distinguish replication groups from failover groups and explain what promotion does
- Identify which replication features need Business Critical Edition
- Recognise which objects are and are not replicated
- Explain how Secure Data Sharing gives other accounts read-only access without copying data
1.Replication groups and failover groups
Replication copies objects from a source account to one or more target accounts in the same organization. The copies in each target account are called secondary objects, and they mirror the primary objects in the source. Every Snowflake region on AWS, Google Cloud and Azure supports replication, which works across regions and across cloud platforms. You can replicate freely within a region group. Replicating from a commercial region to a government or Virtual Private Snowflake region requires contacting Snowflake Support.
Objects are replicated in groups:
- A replication group is a set of objects in a source account that are replicated together, as a unit, to one or more target accounts. The replicated objects are read-only. - A failover group is a replication group that can also fail over. In a target account, the secondary failover group is read-only until it is promoted to primary, and then it becomes read-write. Any target account on the failover group's list of allowed accounts can be promoted.
Both kinds of group keep the objects in the target account consistent to a single point in time. Each refresh of a database brings over the changes to its objects and data since the previous refresh.
| Feature | Standard | Enterprise | Business Critical / VPS |
|---|---|---|---|
| Database replication | Yes | Yes | Yes |
| Share replication | Yes | Yes | Yes |
| Replication Group | Yes | Yes | Yes |
| Account object (other than database and share) replication | No | No | Yes |
| Failover Group | No | No | Yes |
Checkpoint 1 of 4· Match them up
Match each replication term to its description
Tap a term, then the definition that fits it.
Replication groups only ever give read-only replicas. A failover group adds the option to promote a secondary group to primary, which makes it writable.
“When a secondary failover group is promoted to become the primary failover group, read-write access is available.”Source: docs.snowflake.com
Sources1
2.What gets replicated, and what doesn't
Database replication and share replication work on every edition. Replicating any other object needs Business Critical Edition or higher. That includes users, roles, warehouses, network policies, resource monitors, integrations, account-level parameters and listings.
When a database is replicated, the objects inside it come along, but not every object type is supported. The rule that matters in a disaster: objects that can't be replicated are skipped and won't exist in the target account after failover. Examples from the replicated-objects table:
| Object | Replicated? | Note |
|---|---|---|
| Permanent and transient tables | Yes | |
| Temporary tables | No | |
| External tables | No | |
| Hybrid tables | No | |
| Apache Iceberg™ tables | Yes | Only Snowflake-managed Iceberg tables; requires external volume replication |
| Stages and pipes | Yes | Replication and failover groups only; not supported for database replication |
| Views, materialized views, secure views | Yes | A view that references another database needs both databases replicated |
| Streams, tasks, UDFs, stored procedures | Yes |
Shares follow their own rule. Shares you provide to others (outbound) can be replicated, but replication of inbound shares, the ones you receive from providers, isn't supported. With failover groups, you can also choose which schemas in a database get replicated. By default, every schema is.
Checkpoint 2 of 4· Check yourself
A company on Business Critical Edition fails over to its secondary account. Which of these will NOT be available there?
Temporary tables aren't marked as replicated. Unsupported objects are skipped during replication, so they aren't in the target account after failover.
“Objects that are not supported for replication are skipped during replication”Source: docs.snowflake.com
Sources1
3.Secure Data Sharing: access without copying
Replication physically moves data to another account. Secure Data Sharing doesn't. A provider shares selected objects from a database with other Snowflake accounts through a share, a named object that holds everything needed to share that database. Objects you can share include databases, tables, dynamic tables, external tables, Iceberg tables, regular views, secure views, secure materialized views and UDFs (secure and non-secure).
No data is copied or transferred between accounts. Sharing runs through Snowflake's services layer and metadata store. That has a few consequences:
- Fast. Setup is quick for the provider, and consumers get access almost immediately. New objects added to a share, and updates to objects already in it, become available to all consumers right away. - Read-only. Consumers can't modify or delete shared objects or change the data in them. - Cost split. Shared data uses no storage in the consumer account. The consumer pays only for the compute used to query it, and the provider keeps paying for storage. - Provider control. The provider can revoke access to a share, or to any object in it, at any time.
The consumer creates a read-only database from the share, with a limit of one database per share. Access to that database is managed with normal role-based access control. A direct share only works with accounts in the same region. To reach other regions or cloud platforms, you need a different method, such as a listing with cross-cloud auto-fulfillment.
Checkpoint 3 of 4· Put it in order
Put the steps for sharing data, from provider set-up to consumer access, in order
- 1.The consumer grants access to that database to roles in its account
- 2.The provider creates a share
- 3.The provider grants privileges on the objects to share, directly or through a database role
- 4.The provider adds one or more consumer accounts to the share
- 5.The consumer creates a database from the share
The provider builds and fills the share and then adds accounts. Only after that can a consumer create its read-only database from the share and grant roles access to it.
“Create a database from the share that the provider made available to your account, and then grant access”Source: docs.snowflake.com
Checkpoint 4 of 4· Exam question
What is the maximum Time Travel retention period that can be configured for a permanent table on Snowflake Enterprise Edition or higher?
Correct answer: A — 90 days
- A. Enterprise Edition and higher allow the DATA_RETENTION_TIME_IN_DAYS parameter to be set up to 90 days for permanent tables, compared to the fixed 1-day maximum on Standard Edition.
- B. One day is the fixed retention available on Standard Edition, not the maximum available once an account is on Enterprise Edition or higher, which supports a much longer configurable window.
- C. There is no built-in 365-day Time Travel retention tier in Snowflake; extending retention that far is not an available configuration for any edition.
- D. Seven days is commonly associated with the Fail-safe period for permanent tables, not the configurable Time Travel retention window, so it does not answer what this question asks.
Sources2
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Any edition can set up a failover group, because replication groups are available on Standard.Why is that wrong?
Database replication, share replication and replication groups work on every edition. Failover groups and account-object replication need Business Critical or higher.
Covered in Replication groups and failover groups
2.Replicating an account also replicates the shares it has received from other providers.Why is that wrong?
Only outbound shares can be replicated. Inbound shares from providers can't.
Covered in What gets replicated, and what doesn't
3.A share copies the provider's data into the consumer account, so the consumer pays storage for it.Why is that wrong?
Sharing goes through the services layer and metadata store, so the consumer stores nothing and pays only for compute.
Covered in Secure Data Sharing: access without copying
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“This feature enables the replication of objects from a source account to one or more target accounts in the same organization.”
↩︎ Replication groups and failover groups“Replication is supported across regions and across cloud platforms.”
↩︎ Replication groups and failover groups“A failover group is a replication group that can also fail over.”
↩︎ Replication groups and failover groups“Replication and failover groups provide point-in-time consistency for the objects on the target account.”
↩︎ Replication groups and failover groups“Replication of all other objects is only available for Business Critical Edition (or higher).”
↩︎ What gets replicated, and what doesn't“Supported for replication and failover groups only. Not supported for database replication.”
↩︎ What gets replicated, and what doesn't“Database replication and share replication are available on all editions.”
↩︎ Exam trap 1“Replication of inbound shares (shares from providers) is not supported.”
↩︎ Exam trap 2“When a secondary failover group is promoted to become the primary failover group, read-write access is available.”
↩︎ Checkpoint“Objects that are not supported for replication are skipped during replication”
↩︎ Checkpoint - 2.
“All database objects shared between accounts are read-only”
↩︎ Secure Data Sharing: access without copying“New objects added to a share become immediately available to all consumers, providing real-time access to imported data.”
↩︎ Secure Data Sharing: access without copying“you can only create one database per share.”
↩︎ Secure Data Sharing: access without copying“A direct share works only with accounts in the same region.”
↩︎ Secure Data Sharing: access without copying“Providers continue to pay for storage of the data that they share.”
↩︎ Secure Data Sharing: access without copying“With Secure Data Sharing, no actual data is copied or transferred between accounts.”
↩︎ Exam trap 3“The only charges to consumers are for the compute resources (i.e. virtual warehouses) used to query the imported data.”
↩︎ Prediction“Create a database from the share that the provider made available to your account, and then grant access”
↩︎ Checkpoint