ADA-C01 Question 548
Single answerRedirect client connections in case of a failoverA company uses Snowflake Business Critical Edition with account replication and failover groups between AWS us-east-1 (primary) and AWS us-west-2 (secondary). Several internal applications connect with the Snowflake Python Connector using a hard-coded account URL for the primary account. During a planned failover test, administrators promote the secondary account. The applications can authenticate, but many still attempt to connect to the old primary account URL and fail until developers manually update connection settings. The company wants future failovers to require the fewest application changes possible and to redirect clients automatically to the current primary account. Which action should the Snowflake administrator take?
- A
Configure a client redirect object for the primary/secondary accounts and have applications connect using the client redirect connection name instead of the region-specific account URL
- B
Enable database replication on all application databases and keep using the existing account URLs, because replication automatically updates client endpoints after failover
- C
Create a network policy that includes both regions so Snowflake can route incoming sessions from the old account URL to the new primary account
- D
Use session failover parameters in the Python Connector so existing connections are transparently reattached to the promoted secondary account without changing the connection target
Show answer and explanation
Correct answer: A
Explanation
The key issue is that the applications are tied to a region-specific account URL. In a replicated/failover architecture, promoting the secondary account does not automatically cause client applications to switch endpoints. Snowflake's recommended capability for this requirement is client redirect, which lets administrators define a stable connection name and later repoint it to the current primary account during failover or failback. This reduces application changes and operational effort. By contrast, replication/failover groups handle object and data availability, network policies handle access restrictions, and connector retry behavior handles transient failures rather than account endpoint changes. Candidates should know that successful disaster recovery planning in Snowflake includes both account/data failover design and client connection redirection planning.
- A. Correct.
Correct. Snowflake supports client redirect to help applications connect to the current primary account after failover/failback. Administrators configure a connection object for client redirect and associate it with the relevant accounts. Applications then use the redirect-enabled connection identifier rather than a region-specific account URL. After failover, the administrator updates the client redirect target so clients are directed to the promoted primary account with minimal or no application code changes beyond using the redirect name.
- B. Incorrect.
Incorrect. Replication and failover groups protect and synchronize Snowflake objects and metadata, but they do not automatically change the endpoint that client applications use. If applications continue to use a hard-coded account URL for the old primary account, they will still attempt to connect there after failover. Replication addresses data and object availability, not client endpoint redirection.
- C. Incorrect.
Incorrect. Network policies control allowed IP addresses, CIDR blocks, private connectivity restrictions, and related access controls. They do not provide DNS-style redirection or endpoint remapping between Snowflake accounts. Including both regions in a network policy would not redirect clients from one account URL to another after a failover.
- D. Incorrect.
Incorrect. The Python Connector can retry connections and handle transient connectivity issues, but it does not provide a feature that transparently rebinds sessions to a different Snowflake account after account failover while preserving the same hard-coded endpoint. The underlying problem is the client target endpoint, which is addressed by client redirect, not a connector session parameter.