ADA-C01 Question 545
Single answerAnalyze the impact of database failover across multiple accountsA company uses Snowflake Business Critical Edition with replication and failover enabled between two accounts: PROD_US (primary) and DR_EU (secondary). The FINANCE database in PROD_US is configured as a primary database and replicated to DR_EU as a secondary database. During a regional outage, an administrator promotes the secondary FINANCE database in DR_EU to serve production workloads. After the outage is resolved, leadership asks what operational impact this failover had across the two accounts. Which statement best describes the result of promoting the secondary database?
- A
The FINANCE database in DR_EU becomes writable, and the original FINANCE database in PROD_US is demoted so it can no longer be used as the writable primary until replication/failback is re-established.
- B
Both FINANCE databases remain writable in PROD_US and DR_EU so users in each region can continue making changes independently until the outage is resolved.
- C
The failover automatically synchronizes all account-level objects, such as users, roles, warehouses, and network policies, so applications can resume without any additional account configuration in DR_EU.
- D
Once PROD_US becomes available again, Snowflake automatically reverses the failover and merges any changes made in DR_EU back into PROD_US without administrator action.
Show answer and explanation
Correct answer: A
Explanation
This question tests the practical impact of database failover across multiple accounts. In Snowflake, replication and failover for databases are based on primary/secondary roles. Promoting a secondary database makes that copy writable in the target account, but it does not create two writable copies or automatically synchronize unrelated account-level objects. Administrators must separately ensure that DR accounts have the required users, roles, warehouses, integrations, and network/security setup for applications to function after failover. In addition, failback is not automatic; it must be planned and executed by administrators after service is restored. These behaviors align with Snowflake documentation on replication and failover/failback, including the distinction between database-level replication and account-level operational readiness.
- A. Correct.
Correct. When a secondary database is failed over/promoted, it becomes the writable database in the target account. The former primary is no longer the active writable primary for that failover group/database relationship. To resume the original topology, administrators must perform planned recovery steps such as reconfiguring replication/failover and failing back intentionally. This reflects Snowflake's database failover design: only one side is the active writable database at a time for a given replicated database.
- B. Incorrect.
Incorrect. Snowflake database replication and failover do not create an active-active writable model for the same replicated database across accounts. Allowing both copies to be independently writable would create conflicting changes. A common misconception is to assume cross-region replication behaves like multi-master database technology; Snowflake failover is designed around primary/secondary roles with one writable copy after promotion.
- C. Incorrect.
Incorrect. Database failover applies to replicated databases, not to all account-level objects automatically. Account-level items such as users, roles, virtual warehouses, resource monitors, and many security/network configurations are managed separately. Even if database objects are available after failover, applications may still require pre-provisioned account objects and access configuration in the DR account. This option reflects a common misunderstanding between database failover and broader account object readiness.
- D. Incorrect.
Incorrect. Snowflake does not automatically perform failback or merge divergent writes from the promoted secondary into the original primary once the source account is back online. Administrators must explicitly plan and execute recovery steps, including re-establishing replication direction as needed. The idea of automatic bidirectional merge is a misconception; Snowflake avoids this because replicated databases are not designed for conflict resolution across two writable copies.