ARA-C01 Question 251
Single answerReplication and failoverA global company runs a business-critical Snowflake deployment in AWS us-east-1 and has created a secondary account in AWS us-west-2 for disaster recovery. The primary account contains multiple databases, an account-level role hierarchy, users, and a warehouse configuration used by BI workloads. The company wants a failover design that minimizes recovery time during a regional outage while preserving access controls and object consistency for the reporting application. Which approach best meets these requirements?
- A
Create replication groups for the required databases and a separate failover group for account objects such as users, roles, and warehouses; replicate on a schedule, and promote the secondary account during an outage.
- B
Replicate only the databases to the secondary account because account objects such as users, roles, and warehouses are recreated automatically when a secondary database is promoted.
- C
Use database replication for all objects, including users, roles, and warehouse definitions, because database replication includes dependent account metadata needed for failover.
- D
Configure cross-region database replication and then use client connection failover only; no account promotion is needed because queries can run directly against read-only secondary databases after an outage.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use both replication groups and failover groups so that the disaster recovery environment contains not only replicated databases but also the required account objects and security model. In Snowflake, database replication addresses data/object continuity for supported databases, but account-level objects required for operational recovery, such as users, roles, and warehouses, are handled through failover groups for supported object types. After replication is established and refreshed on an appropriate schedule, the secondary account can be promoted during an outage to minimize RTO. This aligns with Snowflake best practices for business continuity and disaster recovery: replicate the full set of supported dependencies needed by the application, not just the database objects. Relevant Snowflake documentation areas include replication groups, failover groups, account object replication support, and failover/failback procedures.
- A. Correct.
Correct. In Snowflake, replication groups are used to replicate supported databases and certain related objects, while failover groups are used to replicate supported account-level objects such as users, roles, warehouses, resource monitors, and other account metadata required for account failover. For a realistic DR design, you must replicate both the data layer and the account-layer security/configuration objects so the reporting application can resume quickly with consistent privileges and operational settings. During an outage, the secondary account is promoted/failover is initiated so it becomes writable and operational.
- B. Incorrect.
Incorrect. Database replication alone does not automatically recreate all account objects in the target account upon promotion. Users, roles, and warehouse definitions are account-level objects and are not covered simply by promoting a replicated database. This is a common misconception when teams focus only on data replication and overlook security and compute dependencies needed for application recovery.
- C. Incorrect.
Incorrect. Database replication does not include all account metadata. Users, roles, and warehouses are not replicated as part of database replication. Snowflake separates replication of database objects from replication of supported account objects, which is why failover groups exist. Choosing this option reflects a misunderstanding of replication scope.
- D. Incorrect.
Incorrect. Secondary databases are read-only until promoted, so they cannot fully replace the primary environment for normal production workloads during a regional outage. In addition, client connection failover by itself does not address missing account-level objects or writable production capability. A DR plan for a production application typically requires account failover/promotion, not just redirecting clients to read-only replicas.