ADA-C01 Question 544
Single answerAnalyze the impact of database failover across multiple accountsA company uses Snowflake Business Critical Edition with replication and failover groups to protect a production database used by two regional accounts: ACCT_PRIMARY and ACCT_DR. The failover group includes the PROD_DB database and account objects required for application continuity. During a regional outage, an administrator promotes the secondary failover group in ACCT_DR. After failover, analysts can query PROD_DB successfully in ACCT_DR, but an ETL service account used by an external application starts failing when attempting to write to target tables. The security team confirms the user exists in ACCT_DR. Which action is the MOST likely required to restore the ETL writes after failover?
- A
Grant the ETL role the necessary privileges on PROD_DB objects in ACCT_DR because object grants are not carried over by database failover
- B
Recreate the network policy and authentication integrations for the ETL user in ACCT_DR because these are account-level objects and may need to be available in the target account after failover
- C
Refresh the secondary database again in ACCT_DR because writable access is not enabled until a second replication cycle completes after promotion
- D
Convert PROD_DB to a database created from a share in ACCT_DR because shared databases are the only supported writable target after failover
Show answer and explanation
Correct answer: B
Explanation
This question tests the ability to analyze what changes, and what does not, when a database is failed over across accounts. In Snowflake, cross-account disaster recovery is commonly implemented with replication and failover groups. Replicated databases include database objects and associated metadata, allowing the promoted secondary database to become writable after failover. However, applications often depend on account-level objects outside the database itself, such as users, roles, network policies, warehouses, resource monitors, and supported integrations. If those dependencies are not present or properly replicated in the target account, application behavior may differ after failover even when the database itself is healthy. In this scenario, analysts can query the database, which indicates the promoted database is available. The ETL service account's inability to write points to an account-level dependency, especially authentication or network access controls. Snowflake documentation on replication/failover groups distinguishes between database-level replication and account object replication, and best practice is to include all required supported account objects in the failover design and validate application dependencies during disaster recovery testing.
- A. Incorrect.
Incorrect. Database replication and failover preserve database objects and their grants as part of the replicated database state. If the failover group was configured to include the required account objects for continuity, the likely gap is not database object privileges disappearing from PROD_DB after promotion. A common misconception is that all grants must be manually reapplied after failover; while some account-level dependencies can cause access issues, replicated database privileges are part of the database metadata.
- B. Correct.
Correct. The scenario says the database is accessible for querying, but an ETL service account cannot write after failover even though the user exists in ACCT_DR. This strongly suggests an account-level dependency rather than a database-level one. In Snowflake, items such as network policies, certain integrations, and other account objects are separate from the database itself. To support continuity across accounts, these account-level objects must be replicated or otherwise made available in the target account using failover groups where supported. If the ETL connection depends on a network policy or authentication/security integration that is missing or not active in ACCT_DR, authentication or session establishment for writes can fail even though the database itself has been promoted successfully.
- C. Incorrect.
Incorrect. Once a secondary database is promoted during failover, it becomes the primary and is writable. There is no requirement for an additional replication cycle before write operations are allowed. This option reflects a misunderstanding of failover behavior. If users can query the promoted database, the issue is more likely related to security, connectivity, or account object dependencies rather than database writability.
- D. Incorrect.
Incorrect. A database created from a share is read-only and is not the mechanism used to restore write capability after failover. Failover groups and database replication are the relevant features for disaster recovery between accounts. This option confuses data sharing with replication/failover capabilities.