What you will be able to do
- Audit replication and failover group configuration and freshness before a failover is needed
- Run a controlled failover test that proves security objects arrive and work in the target account
- Configure Client Redirect with primary and secondary connection objects across regions
Key concept
Primary connection (Client Redirect) — A connection object gives clients one URL built from the organization name and connection name. That URL resolves to whichever account currently holds the primary connection, so promoting a secondary connection moves every client without changing any client settings.
1.Auditing replication configuration before you need it
A failover can only promote what was already replicated, and only as of the most recent refresh. A readiness audit therefore asks two separate questions. First, is the right content in the failover group? Second, is the replica fresh enough to meet the recovery objective?
For content, check the primary failover group definition. Security objects only travel if their types are listed. A group that should carry network policies and integrations has to name them in OBJECT_TYPES, and it has to say which integration types are allowed. Here is the documented example:
CREATE FAILOVER GROUP myfg
OBJECT_TYPES = USERS, ROLES, WAREHOUSES, RESOURCE MONITORS, DATABASES, INTEGRATIONS, NETWORK POLICIES
ALLOWED_DATABASES = db1, db2
ALLOWED_INTEGRATION_TYPES = API INTEGRATIONS
ALLOWED_ACCOUNTS = myorg.myaccount2
REPLICATION_SCHEDULE = '10 MINUTE';For freshness, Snowflake recommends scheduling secondary refreshes with REPLICATION_SCHEDULE instead of relying on manual refreshes. Under Admin » Accounts » Replication in Snowsight, each group shows a Status (the outcome of the latest refresh), a Replication Lag (the time since the last refresh), and a Next Refresh time. A failed latest refresh, or a lag longer than your recovery point objective, means the replica is not ready even though the configuration looks correct.
An audit should also check two things the target account does not inherit. Tri-Secret Secure and private connectivity are not enabled on target accounts by default, so you have to configure them yourself if compliance requires them. The REPLICATE and FAILOVER privileges on the group are not replicated either. A role that can fail over in one account may have no such grant in the other.
| Column | What it shows | Audit signal |
|---|---|---|
| Status | Status of the latest refresh operation | Refresh Failed or Refresh Cancelled means the replica is behind |
| Replication Lag | Length of time since the last refresh operation | Compare against your recovery point objective |
| Next Refresh | Date and time of the next scheduled refresh | No schedule means freshness depends on someone refreshing manually |
Checkpoint 1 of 6· Check yourself
An auditor confirms that a failover group lists INTEGRATIONS and NETWORK POLICIES. Which additional observation shows the replica may still fail the recovery point objective?
Replication Lag measures how far the secondary is behind the primary. Correct contents do not help if the copy is stale.
“The length of time since the last refresh operation.”Source: docs.snowflake.com
Checkpoint 2 of 6· Exam question
A security team audits its failover group each quarter. They must prove that network policies, security integrations, users, and roles are all in the replicated object set, not only databases. Which audit step answers this directly?
Correct answer: A — Run SHOW FAILOVER GROUPS on the primary account and review the object_types and allowed_integration_types columns of the group definition.
- A. Correct. The group definition lists object_types and allowed_integration_types, so reviewing it shows whether network policies, users, roles, and integrations are in scope for replication.
- B. Incorrect. Login history shows authentication activity, not which object types the group replicates, and secondary users may not have logged in at all.
- C. Incorrect. There is no per-role REPLICATE privilege that marks objects as replicated; scope is defined by the group's object types.
- D. Incorrect. Replicated objects are applied by refresh operations, not by re-running DDL statements, so the secondary's query history will not mirror the primary's.
2.Controlled failover tests for security objects
Reading a configuration does not prove that security objects work after promotion. Snowflake documents a test approach for each replicated network policy and security integration: identify the source account, the target account, and the connection URL; complete the source-side steps; complete the target-side steps; then test failover and failback.
Take a baseline before the first refresh. Record what the target account already has with SHOW USERS and SHOW INTEGRATIONS. After you refresh the secondary group, run both commands again and DESCRIBE INTEGRATION on the replicated integration. You should see the new users and one new integration. Then promote the secondary connection and confirm that users can authenticate. For SAML2, the documentation says SSO works on the new primary connection after failover.
The test also covers the people who will run the real failover. Promotion requires a role with the FAILOVER privilege, and that privilege is not replicated, so the test should run under the same role you will use in a real event. Refreshes also have a trap of their own: if the user who calls the refresh in the target account was dropped in the source account, the refresh fails.
Checkpoint 3 of 6· Check yourself
In a controlled test, what should you do in the target account BEFORE the first refresh so you can later prove the security integration replicated?
The documented procedure records the user and integration counts first, then compares them after the refresh.
“Prior to replication, verify the number of users and security integrations that are present in the target account”Source: docs.snowflake.com
3.Configuring Client Redirect
Client Redirect is built on a connection object. Its hostname has the form organization_name-connection_name.snowflakecomputing.com. The hostname names no account. Clients reach whichever account holds the primary connection. This is why the organization name and connection name matter: the connection name must be unique across all connection names and account names in the organization.
Setup takes four steps. In the source account, create the primary connection and list the accounts allowed to hold a secondary. In each of those accounts, create a secondary connection with the same name. Finally, point the clients at the connection URL. Only ACCOUNTADMIN can run these commands.
-- Create a new primary connection
CREATE CONNECTION myconnection;
-- View accounts in your organization that are enabled for replication
SHOW REPLICATION ACCOUNTS;
-- Configure failover accounts for the primary connection
ALTER CONNECTION myconnection
ENABLE FAILOVER TO ACCOUNTS myorg.myaccount2, myorg.myaccount3;
-- View the details for the connection
SHOW CONNECTIONS;Checkpoint 4 of 6· Fill the gap
Which keyword completes the statement that creates the secondary connection in a target account?
CREATE CONNECTION myconnection
AS ? OF myorg.myaccount1.myconnection;A secondary connection is created AS REPLICA OF the fully qualified primary connection and must keep the same name.
Source: docs.snowflake.comTwo constraints catch people out. First, every account holding a secondary connection must be in a different region from the primary. Client Redirect between two accounts in the same region does not work. Second, if the account uses private connectivity, Snowsight cannot create the connections. You must also create and manage a DNS CNAME record for the connection URL, and update it each time a connection is promoted.
Checkpoint 5 of 6· Put it in order
Put the Client Redirect setup steps in order
- 1.Update Snowflake clients to use the connection URL
- 2.CREATE CONNECTION in the source account
- 3.ALTER CONNECTION … ENABLE FAILOVER TO ACCOUNTS for the target accounts
- 4.CREATE CONNECTION … AS REPLICA OF in each target account
The primary must exist and list the target before a secondary can be created there. Clients switch to the URL once the connection group exists.
“Complete the steps in Configuring Client Redirect (in this topic) to create a connection URL for client connections.”Source: docs.snowflake.com
Checkpoint 6 of 6· Exam question
Before an annual DR exercise, an engineer wants to confirm that replicated users, roles, and network policies are fully functional after promotion, without touching the production failover group. What is the most reliable controlled test?
Correct answer: A — Create a dedicated failover group with the same security object types between two non-production accounts, refresh it, promote the secondary, and run functional checks.
- A. Correct. A parallel test group in non-production accounts exercises real promotion of security objects, including write access and enforcement, without risking production.
- B. Incorrect. Secondary objects are read-only until promotion, so inspecting them cannot validate that roles, users, and policies work once the account becomes primary.
- C. Incorrect. Promoting production for a test exposes live workloads to risk, and reverting is itself a failover that needs a fresh refresh and validation, not an instant undo.
- D. Incorrect. Cloning does not exercise replication or promotion, and users, roles, and network policies are account-level objects that cannot be cloned into a database.
Sources4
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A secondary connection in another account in the same region gives you a working Client Redirect target.Why is that wrong?
Client Redirect works only across regions. A same-region secondary will not redirect clients.
Covered in Configuring Client Redirect
2.Because the target is a replica, it automatically has the same Tri-Secret Secure and PrivateLink protections as the source.Why is that wrong?
These features are off on target accounts by default and must be configured there separately.
Covered in Auditing replication configuration before you need it
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“As a best practice, we recommend scheduling your secondary refreshes by setting the REPLICATION_SCHEDULE parameter”
↩︎ Auditing replication configuration before you need it“The REPLICATE privilege is currently not replicated”
↩︎ Auditing replication configuration before you need it“If the user who calls the function in the target account was dropped in the source account, the refresh operation fails.”
↩︎ Controlled failover tests for security objects“Target accounts do not have Tri-Secret Secure or private connectivity to the Snowflake service, such as AWS PrivateLink, enabled by default.”
↩︎ Exam trap 2“The FAILOVER privilege is currently not replicated and must be granted in each source and target account.”
↩︎ Prediction - 2.
“Displays the status of the latest refresh operation.”
↩︎ Auditing replication configuration before you need it“The length of time since the last refresh operation.”
↩︎ Checkpoint - 3.
“Identify the source account and target account for replication, and identify the connection URL.”
↩︎ Controlled failover tests for security objects“Verify the refresh operation was successful by executing the following commands:”
↩︎ Controlled failover tests for security objects“Prior to replication, verify the number of users and security integrations that are present in the target account”
↩︎ Checkpoint - 4.
“Note that this hostname does not specify the account to which you are connecting.”
↩︎ Configuring Client Redirect“Each secondary connection must have the same name as its primary connection.”
↩︎ Configuring Client Redirect“you must create and manage a DNS CNAME record for your connection URL.”
↩︎ Configuring Client Redirect“you are connecting to the account that contains the primary connection.”
↩︎ Key concept“Client Redirect only operates successfully across regions.”
↩︎ Exam trap 1“Complete the steps in Configuring Client Redirect (in this topic) to create a connection URL for client connections.”
↩︎ Checkpoint