ADA-C01 Question 551
Single answerIdentify the appropriate failover or fallback procedureA company runs a customer-facing application on Snowflake in AWS us-east-1. The account is part of an account replication and failover configuration with a secondary account in AWS us-west-2. During a regional outage, users must be redirected to the secondary account with the least downtime and without changing application SQL. The primary account is unavailable, but replication had been running on schedule before the outage. What is the MOST appropriate procedure for the Snowflake administrator to restore service?
- A
Promote the replicated failover group in the secondary account to become primary, update client connectivity so applications use the secondary account endpoint, and continue operations there until the original region is recovered.
- B
Convert all replicated databases in the secondary account to writable databases individually, then recreate users and roles manually because account-level objects cannot be failed over.
- C
Use Time Travel in the primary account to restore the latest database versions, then resume client traffic to the original account because Time Travel is designed for regional disaster recovery.
- D
Refresh the replication schedule in the primary account and wait for the next synchronization cycle before switching users, because failover should only occur after a clean final replication.
- E
Clone the secondary databases into a new account in us-west-2 and point applications there, because replicated objects cannot be queried until they are cloned.
Show answer and explanation
Correct answer: A
Explanation
For Snowflake disaster recovery across regions or cloud regions, the correct fallback/failover procedure is to use replication and failover features that were preconfigured, then promote the secondary during an outage. In practice, administrators create replication or failover groups, replicate supported objects to a secondary account, and during a disaster execute failover from the secondary side if the primary is unavailable. After promotion, applications must connect to the new active account endpoint; SQL usually does not need to change if the object structure is replicated consistently. Time Travel and Fail-safe are not substitutes for regional failover: Time Travel helps recover prior data states within an account, and Fail-safe is a Snowflake-managed last-resort recovery window, not an immediate customer-controlled DR mechanism. Snowflake documentation on account replication, replication groups/failover groups, and business continuity/disaster recovery best practices supports this approach.
- A. Correct.
Correct. In a cross-region disaster recovery scenario using account replication/failover groups, the appropriate action is to fail over from the secondary account by promoting the replicated failover group. This makes the secondary copy the active primary for the replicated objects. After that, application connectivity must be redirected to the secondary account's locator/endpoint. This is the standard Snowflake failover procedure for regional outages and preserves object metadata included in the failover group, such as databases and supported account objects, minimizing application changes.
- B. Incorrect.
Incorrect. This reflects a common misconception that administrators must recover each database separately and rebuild account objects manually. Snowflake failover groups are specifically designed to replicate and fail over supported account objects together, not just databases. While not every account object type is supported, the failover process is not performed by individually converting replicated databases and manually reconstructing the environment as a first-choice recovery procedure.
- C. Incorrect.
Incorrect. Time Travel is for recovering historical data within the same account, such as restoring dropped or changed objects, not for account-level regional disaster recovery when the primary account or region is unavailable. If the primary region is down, relying on Time Travel in that unavailable account does not restore service.
- D. Incorrect.
Incorrect. During an actual outage of the primary region, waiting for another replication cycle is not appropriate because the primary account is unavailable. Disaster recovery procedures assume some recovery point objective based on the last successful replication. Administrators should fail over to the secondary using the most recent replicated state rather than wait for a final sync that cannot occur.
- E. Incorrect.
Incorrect. Replicated databases in a secondary account are available as replicated databases and become writable through failover/promotion; cloning them into another account is unnecessary and adds complexity and delay. The key recovery mechanism is failover of the configured replication/failover objects, not ad hoc cloning.