What you will be able to do
- Choose between a replication group and a failover group for a cross-region requirement
- Identify which objects and features need Business Critical Edition
- Promote a secondary failover group, and explain why the promotion fails while a refresh is running
- Use backup sets, backup policies and retention lock to protect against deletion
1.Replication groups and failover groups
Time Travel and Fail-safe protect data inside a single account. To survive the loss of a whole region, you need a copy in another account, and replication provides it. Replication copies objects from a source account to one or more target accounts in the same organization. It works across regions and across AWS, Google Cloud and Azure. You can replicate between any regions in the same region group. Replicating into a different region group, such as a government region, requires contacting Snowflake Support. The copies in the target account are called secondary objects.
You replicate objects as a group, and there are two kinds of group. A replication group gives the target account read-only copies, which suits a reporting copy in another region. A failover group also replicates, and in addition one of its target accounts can be promoted. Once promoted, its copy becomes the primary and accepts reads and writes. Both kinds of group keep their objects consistent with each other at a single point in time on the target. So after a refresh, the objects in the group reflect the same moment and are never partly updated.
Checkpoint 1 of 6· Check yourself
Analysts need a read-only copy of a database in a second region. That region will never take over as primary. Which object fits with the least extra capability?
Replication groups give read-only access in the target account. You only need a failover group if the target must be able to become the read-write primary.
“Replication groups provide read-only access for the replicated objects.”Source: docs.snowflake.com
Sources1
2.What gets replicated, and on which edition
Your edition decides how much of a disaster recovery plan you can build. Database replication and share replication are available on every edition. Replicating anything else requires Business Critical Edition or higher. That includes users, roles, warehouses, resource monitors, network policies, integrations and account-level parameters. Failover groups also require Business Critical. So an Enterprise account can keep read-only database copies in another region, but it cannot fail over, and it cannot replicate the account objects users would need after a failover. Note also that the REPLICATE and FAILOVER privileges themselves are not replicated, even when roles are.
| Feature | Standard | Enterprise | Business Critical | VPS |
|---|---|---|---|---|
| Database replication | ✔ | ✔ | ✔ | ✔ |
| Share replication | ✔ | ✔ | ✔ | ✔ |
| Replication Group | ✔ | ✔ | ✔ | ✔ |
| Account object (other than database and share) replication | ✔ | ✔ | ||
| Failover Group | ✔ | ✔ |
Even within a replicated database, some objects are not copied. Permanent and transient tables, dynamic tables, sequences, views, streams and tasks are replicated. Temporary tables, external tables, hybrid tables and event tables are not. Stages and pipes are replicated only through replication and failover groups, not through plain database replication. Objects that are not replicated are skipped without failing the refresh, so after a failover they simply are not there. A disaster recovery plan has to account for them separately. With failover groups you can also choose which schemas in a database to replicate.
Checkpoint 2 of 6· Check yourself
An Enterprise Edition account plans cross-region failover that includes warehouses, roles and resource monitors as well as databases. What should the architect flag?
Enterprise can replicate only databases and shares. Failover groups and replication of users, roles, warehouses and resource monitors require Business Critical or higher.
“Replication of all other objects is only available for Business Critical Edition (or higher).”Source: docs.snowflake.com
Sources1
3.Disaster recovery and availability: promoting a failover group
To fail over, a role with the FAILOVER privilege signs in to the target account. It lists the failover groups there, then promotes each secondary group it needs with ALTER FAILOVER GROUP … PRIMARY. There is one rule to know for the exam. In a partial outage, the replication service may still be running and refreshing secondary groups. To protect data integrity, Snowflake will not fail over while a refresh is in progress. The command returns an error telling you to wait for the refresh to finish or cancel it, and then try again.
ALTER FAILOVER GROUP myfg PRIMARY;Checkpoint 3 of 6· Put it in order
Put the SQL failover steps in order
- 1.Sign in to the target account with a role that has the FAILOVER privilege
- 2.Run ALTER FAILOVER GROUP … PRIMARY for each secondary group to promote
- 3.Run SHOW FAILOVER GROUPS to list the failover groups
You promote from the target account: first list the groups, then promote each secondary.
“Execute the following statement for each secondary failover group you want to promote to serve as the primary failover group”Source: docs.snowflake.com
Checkpoint 4 of 6· Check yourself
An administrator runs ALTER FAILOVER GROUP … PRIMARY while a scheduled refresh of that secondary group is running. What happens?
To protect data integrity, Snowflake blocks failover while a refresh is in progress and returns an error.
“To ensure data integrity, Snowflake prevents failover if a refresh operation is in progress.”Source: docs.snowflake.com
Checkpoint 5 of 6· Exam question
An architect is documenting which combinations of table type and edition receive extended Time Travel on an account that runs Enterprise Edition. Which of the following statements are accurate? (Select all that apply.)(Select 3)
Correct answers: A, C, D — A permanent table can be configured with retention anywhere from 0 to 90 days because the account runs Enterprise Edition.; A temporary table's Time Travel history is lost once the session that created it ends, independent of the configured retention value.; Setting DATA_RETENTION_TIME_IN_DAYS to 0 on a permanent table disables Time Travel for that specific object while leaving Fail-safe untouched.
- A. Correct - Enterprise Edition permanent tables support the full 0-to-90-day configurable range for DATA_RETENTION_TIME_IN_DAYS.
- B. Incorrect - transient tables are capped at 1 day of Time Travel retention regardless of what DATA_RETENTION_TIME_IN_DAYS is raised to.
- C. Correct - a temporary table exists only for its session, so its historical row versions and Time Travel access disappear when that session ends.
- D. Correct - a retention value of 0 turns off self-service Time Travel access for that object, but the object's Fail-safe period still applies afterward.
- E. Incorrect - Standard Edition is fixed at a 1-day retention period and cannot be raised to 90 days regardless of table type.
- F. Incorrect - a transient table's retention is governed by its own type cap and configured setting, not automatically inherited from a source table via cloning.
Sources2
4.Backups: immutable point-in-time snapshots
Replication copies changes to the target, so a corrupting change or a malicious delete is copied there too. Backups solve a different problem. A backup is a point-in-time snapshot of a table, a schema or a whole database, and nobody can modify it once it exists. You manage backups through a backup set, which is a schema-level object holding the backups for one object. A backup policy attached to the set controls when backups are taken and when they expire. You can also add or delete backups manually. To list backups, run SHOW BACKUPS IN BACKUP SET. To take a new one, run ALTER BACKUP SET.
CREATE BACKUP POLICY hourly_backup_policy SCHEDULE = '60 MINUTE' EXPIRE_AFTER_DAYS = 90 COMMENT = 'Hourly backups expire after 90 days';For protection against attackers, a policy can apply a retention lock. A retention lock stops anyone, including privileged users, from deleting or changing locked backups. Even an attacker who gains the ACCOUNTADMIN or ORGADMIN role cannot delete them, which is why Snowflake presents locked backups as part of a defence against ransomware. Basic backups are available on every edition. Retention lock and legal holds require Business Critical or higher, and creating a policy with a retention lock requires the APPLY BACKUP RETENTION LOCK privilege. Backups have three costs. Snowflake-managed compute creates and expires backups, and Snowflake-managed warehouses perform restores; both are billed. Backup storage is billed like bytes retained for clones. You can monitor it in the RETAINED_FOR_CLONE_BYTES column and in the BACKUP_STORAGE_USAGE view.
Checkpoint 6 of 6· Check yourself
Ransomware gains ACCOUNTADMIN in a Business Critical account. Which recovery option is designed to withstand an attacker who holds that role?
A retention lock stops even ACCOUNTADMIN or ORGADMIN from deleting the backups. ACCOUNTADMIN can change retention settings, and replication copies the attacker's changes to the target.
“even if they gain access to the account by using the ACCOUNTADMIN or ORGADMIN roles.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Enterprise Edition is enough for account-level failover of users, roles and warehouses.Why is that wrong?
Only database and share replication are available below Business Critical. Failover groups and account-object replication need Business Critical or higher.
Covered in What gets replicated, and on which edition
2.After failover, every object in a replicated database exists in the new primary.Why is that wrong?
Objects that cannot be replicated, such as temporary, external, hybrid and event tables, are skipped and are missing after failover.
Covered in What gets replicated, and on which edition
Practise it for real
Put a table under scheduled, immutable backups and inspect what was captured
1.Run CREATE BACKUP POLICY hourly_backup_policy SCHEDULE = '60 MINUTE' EXPIRE_AFTER_DAYS = 90 COMMENT = 'Hourly backups expire after 90 days';
Why: The policy sets how often backups are taken and when they expire
You should see: A backup policy named hourly_backup_policy exists
2.Run CREATE BACKUP SET t1_backups FOR TABLE t1 WITH BACKUP POLICY hourly_backup_policy;
Why: The backup set is the schema-level object that holds t1's backups
You should see: Backups of t1 are now taken on the policy's schedule
3.Run ALTER BACKUP SET to take a backup now, then run SHOW BACKUPS IN BACKUP SET t1_backups
Why: You manage individual backups through the backup set that contains them
You should see: At least one backup is listed, each with its own Snowflake-generated ID
Stuck? Get a nudge
Check BACKUP_STORAGE_USAGE afterwards. Backup storage is billed like bytes retained for clones.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Replication is supported across regions and across cloud platforms.”
↩︎ Replication groups and failover groups“When a secondary failover group is promoted to become the primary failover group, read-write access is available.”
↩︎ 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“Customers can replicate across all regions within a region group.”
↩︎ Replication groups and failover groups“Replication of all other objects is only available for Business Critical Edition (or higher).”
↩︎ What gets replicated, and on which edition“The REPLICATE and FAILOVER privileges are not replicated.”
↩︎ What gets replicated, and on which edition“If you use failover groups, you can choose which schemas within a database are replicated.”
↩︎ What gets replicated, and on which edition“Backups with retention lock and backups with legal holds are available for Business Critical Edition (or higher).”
↩︎ Backups: immutable point-in-time snapshots“Database replication and share replication are available on all editions.”
↩︎ Exam trap 1“Objects that are not supported for replication are skipped during replication and won’t be available in the target account after failover.”
↩︎ Exam trap 2“Replication groups provide read-only access for the replicated objects.”
↩︎ Checkpoint - 2.
“The example in this section must be executed by a role with the FAILOVER privilege.”
↩︎ Disaster recovery and availability: promoting a failover group“Either wait for the refresh to finish or cancel the refresh and try again.”
↩︎ Disaster recovery and availability: promoting a failover group“Execute the following statement for each secondary failover group you want to promote to serve as the primary failover group”
↩︎ Checkpoint“To ensure data integrity, Snowflake prevents failover if a refresh operation is in progress.”
↩︎ Checkpoint - 3.https://docs.snowflake.com/en/user-guide/backupsOfficial docs
“A backup represents a point-in-time snapshot of an object.”
↩︎ Backups: immutable point-in-time snapshots“A backup set is a schema-level object that contains a set of backups for a specific database, schema, or table.”
↩︎ Backups: immutable point-in-time snapshots“Backups with retention lock are part of an overall cyber-resilience strategy.”
↩︎ Backups: immutable point-in-time snapshots“even if they gain access to the account by using the ACCOUNTADMIN or ORGADMIN roles.”
↩︎ Checkpoint - 4.
“Billed for bytes retained for backups, similar to bytes retained for clones.”
↩︎ Backups: immutable point-in-time snapshots“Snowflake-managed warehouses are used to restore objects from backups.”
↩︎ Backups: immutable point-in-time snapshots