What you will be able to do
- Delegate replication work to custom roles holding only CREATE FAILOVER GROUP, REPLICATE or FAILOVER rather than ACCOUNTADMIN
- Explain why REPLICATE and FAILOVER must be granted separately in the source and target accounts
- Explain how OWNERSHIP of a group and OWNERSHIP of replicated objects are decided
- Limit which accounts a group can reach and which object types it carries
- Choose the object types a group needs so that network policies replicate without failing the refresh
Key concept
Replication / failover group — A named object in the source account that lists which object types and databases are copied, and which accounts they may be copied to. A failover group is the same thing, except a target account can also be promoted to become the primary. The group's settings and privileges decide which security objects leave the account and who can move them.
1.Least privilege for replication roles
Each replication task needs a different privilege, so least privilege means giving each task to a narrow custom role instead of running everything as ACCOUNTADMIN. The documentation separates three tasks. Creating a group needs the account-level CREATE FAILOVER GROUP privilege. Refreshing a secondary group needs REPLICATE on that group. Promoting a secondary to primary needs FAILOVER on that group. Adding a database to a failover group also requires the active role to hold MONITOR on that database.
The documentation also says the considerations topic lists 'the replication privileges that are available to be granted to roles'. The sources retrieved for this lesson only show the CREATE FAILOVER GROUP grant. The equivalent CREATE REPLICATION GROUP grant syntax is not in them, so check it against the GRANT reference before you rely on it.
USE ROLE ACCOUNTADMIN; CREATE ROLE myrole; GRANT CREATE FAILOVER GROUP ON ACCOUNT TO ROLE myrole;REPLICATE and FAILOVER are the privileges people most often get wrong. You can replicate roles, along with their grants and hierarchies, but these two privileges do not travel with them. A role that can refresh in the source account will not be able to refresh in the target until someone grants REPLICATE there as well. FAILOVER has to be granted in both accounts in the same way. To audit these privileges, check the grants on the group in every account. Checking only the primary account will miss grants in the targets.
GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;Checkpoint 1 of 6· Fill the gap
An operator only needs to run scheduled and manual refreshes, never failovers. Which privilege completes this least-privilege grant?
GRANT ? ON FAILOVER GROUP myfg TO ROLE my_replication_role;A refresh needs REPLICATE on the group. FAILOVER is only for promotion, and OWNERSHIP would let the operator re-grant privileges on the group.
Source: docs.snowflake.comCheckpoint 2 of 6· Exam question
A platform team must let a disaster-recovery engineering group create failover groups in the production account, but the security standard forbids handing out ACCOUNTADMIN. Which approach follows least privilege?
Correct answer: C — Create a custom role, grant it CREATE FAILOVER GROUP on the account, and assign it only to the DR engineers.
- A. Incorrect: SECURITYADMIN does not hold CREATE FAILOVER GROUP by default and brings extensive user and role management rights.
- B. Incorrect: REPLICATE is a privilege on an existing group that permits refreshing it; it does not allow creating groups.
- C. Correct: CREATE FAILOVER GROUP is an account-level privilege held only by ACCOUNTADMIN by default, so it can be delegated narrowly to a dedicated custom role.
- D. Incorrect: MANAGE GRANTS lets a role grant any privilege, which is far broader than needed and defeats least privilege.
2.Who owns the group, and who owns what it creates
Ownership comes up in two separate ways here, and they are easy to mix up.
The first is OWNERSHIP of the group object. The owning role decides who else can operate the group: the documented REPLICATE and FAILOVER grants are run by a role with OWNERSHIP on the group, in each account where the grant is needed. Treat that owning role as the most sensitive role in your replication design. Keep it separate from the day-to-day refresh role so that an operator cannot hand out FAILOVER to other roles.
The second is OWNERSHIP of objects that a refresh creates in the target account. This depends on whether roles are replicated. If roles are not replicated, the new objects are owned by GLOBALORGADMIN. If roles are replicated, ownership goes to the matching role, the same one that owns the object in the source account, once roles are next replicated. Put roles in the same group as the objects they own, so both arrive in one refresh.
Checkpoint 3 of 6· Check yourself
A refresh creates new objects in a target account. The group does not replicate roles. Which role owns the new objects?
If roles are not replicated, there is no matching role in the target to receive ownership, so Snowflake gives OWNERSHIP of the new objects to GLOBALORGADMIN.
“roles are not replicated to the target account, the OWNERSHIP privilege for the new objects is granted to the GLOBALORGADMIN role”Source: docs.snowflake.com
3.Constraining where security objects can go
Three controls limit where a group's contents can go. First, an organization administrator has to enable replication on each source and target account by setting ENABLE_ACCOUNT_DATABASE_REPLICATION. An account that has not been enabled cannot take part. Second, the group's ALLOWED_ACCOUNTS list names the accounts that may hold a secondary copy. These are also the only accounts that can be promoted. Third, OBJECT_TYPES and ALLOWED_INTEGRATION_TYPES set which kinds of objects leave the source account. If a review finds security objects that could reach an unexpected account, check two things: which accounts are enabled for replication, and the group's ALLOWED_ACCOUNTS list.
SELECT SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER('<organization_name>.<account_name>', 'ENABLE_ACCOUNT_DATABASE_REPLICATION', 'true');Some structural rules also apply. An account can have only one replication or failover group that contains objects other than databases or shares. As a result, users, roles, integrations and network policies all sit in a single group. An object can belong to only one failover group. Edition matters too: replicating users, roles, integrations, network policies and account parameters requires Business Critical Edition or higher.
Checkpoint 4 of 6· Exam question
Which privilege must a role hold on a replication group before it can run a manual refresh of that group in a target account?
Correct answer: D — The REPLICATE privilege on the group, allowing the role to refresh the secondary group.
- A. Incorrect: FAILOVER authorizes promoting a secondary failover group to primary, not refreshing it.
- B. Incorrect: MONITOR only permits viewing group details and does not allow a refresh to be started.
- C. Incorrect: USAGE is not a privilege that governs refreshing replication or failover groups.
- D. Correct: REPLICATE on the group is the privilege that authorizes a manual refresh of the group's objects in the target.
Checkpoint 5 of 6· Check yourself
An Enterprise Edition account wants to put users, roles and network policies in a replication group. What happens?
Every edition can replicate databases and shares. Users, roles, network policies and other account objects need Business Critical Edition or higher.
“Replication of all other objects is only available for Business Critical Edition (or higher).”Source: docs.snowflake.com
4.Replicating network policies with their dependencies
If the target account has no network policies, anyone who fails over to it reaches it from any IP address. Replicating network policies applies the same IP-based restrictions in the target account.
Replication copies the policy object and also every reference to it and assignment of it. For that to work, the objects it refers to or is attached to have to exist in the target account. If a supporting object is not already there, add its object type to the same group as the policy. Network rules are schema-level objects, so they replicate with the database that contains them.
| How the network policy is used | Also include in OBJECT_TYPES |
|---|---|
| Uses network rules | databases (with ALLOWED_DATABASES) |
| Assigned to the account | account parameters |
| Assigned to a user | users |
| Assigned to a Snowflake OAuth or SCIM security integration | integrations, with ALLOWED_INTEGRATION_TYPES = security integrations |
CREATE FAILOVER GROUP fg OBJECT_TYPES = network policies, integrations, databases ALLOWED_DATABASES = testdb2 ALLOWED_INTEGRATION_TYPES = security integrations ALLOWED_ACCOUNTS = myorg.myaccount2;Checkpoint 6 of 6· Match them up
Match each network policy situation to the object type the group must also include
Tap a term, then the definition that fits it.
Each assignment points at another object, and that object's type has to be replicated as well. Network rules are schema-level, so they arrive with their database.
“The replication or failover group must include network policies and account parameters.”Source: docs.snowflake.com
Sources4
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.If roles are replicated, a role's REPLICATE and FAILOVER grants arrive in the target account along with it.Why is that wrong?
These two privileges are never replicated. They have to be granted on the group separately in the source account and in each target account.
Covered in Least privilege for replication roles
2.If a replicated network policy's assigned user or network rule is missing, the refresh just skips that assignment.Why is that wrong?
Snowflake fails the whole refresh. Include the users, account parameters, databases or integrations object types that the policy depends on.
Covered in Replicating network policies with their dependencies
3.You can split users and network policies across several replication groups in the same account.Why is that wrong?
An account can have only one group that contains objects other than databases or shares.
Covered in Constraining where security objects can go
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“The REPLICATE privilege is currently not replicated and must be granted on a failover (or replication) group”
↩︎ Least privilege for replication roles“The FAILOVER privilege is currently not replicated and must be granted in each source and target account.”
↩︎ Least privilege for replication roles“To add a database to a failover group, the active role must have the MONITOR privilege on the database.”
↩︎ Least privilege for replication roles“Execute in the target account using a role with the OWNERSHIP privilege on the failover group”
↩︎ Who owns the group, and who owns what it creates“The organization administrator must enable replication for the source and target accounts.”
↩︎ Constraining where security objects can go - 2.
“This section describes the replication privileges that are available to be granted to roles”
↩︎ Least privilege for replication roles“An object can only be in one failover group.”
↩︎ Constraining where security objects can go“An account can only have one replication or failover group that contains objects other than databases or shares.”
↩︎ Exam trap 3 - 3.
“the OWNERSHIP privilege is granted to the same role on the target account as the role with the OWNERSHIP privilege”
↩︎ Who owns the group, and who owns what it creates“You can promote any target account specified in the list of allowed accounts in a failover group”
↩︎ Constraining where security objects can go“A failover group is a replication group that can also fail over.”
↩︎ Key concept“The REPLICATE and FAILOVER privileges are not replicated.”
↩︎ Exam trap 1“roles are not replicated to the target account, the OWNERSHIP privilege for the new objects is granted to the GLOBALORGADMIN role”
↩︎ Checkpoint“Replication of all other objects is only available for Business Critical Edition (or higher).”
↩︎ Checkpoint - 4.
“Replicating a network policy replicates the network policy object and any network policy references/assignments.”
↩︎ Replicating network policies with their dependencies“Network rules are schema-level objects and are replicated with the database in which they are contained.”
↩︎ Replicating network policies with their dependencies“If you do not replicate the supporting object types properly, Snowflake fails the refresh operation in the target account.”
↩︎ Exam trap 2“If you do not replicate the supporting object types properly, Snowflake fails the refresh operation in the target account.”
↩︎ Prediction“The replication or failover group must include network policies and account parameters.”
↩︎ Checkpoint