SnowPro Advanced: Security Engineer Question 213
Single answerReplicate network policies to maintain consistent access controlsA global company uses Snowflake account replication to maintain a secondary account in another region for disaster recovery. The primary account restricts connectivity by using a network policy that allows only corporate NAT IP ranges and blocks all other access. During a failover test, the security team discovers that users can authenticate to the secondary account from networks that should not be allowed. The team needs a solution that keeps the same access restrictions after future replications and failovers with minimal manual intervention. Which action should the security engineer take?
- A
Create the same network policy manually in the secondary account and set it as the account-level network policy there, because network policies are not replicated with account replication or database replication.
- B
Add the network policy to a failover group so that it is replicated along with users, roles, and grants, then attach it to the replicated databases.
- C
Enable replication for the SECURITY database, because network policies are stored there and will be included automatically during failover.
- D
Use object tagging on the network policy so Snowflake applies the same IP restrictions automatically in the target account after replication.
Show answer and explanation
Correct answer: A
Explanation
The key point is that network policies are not replicated through Snowflake replication features such as database replication or failover groups. In a disaster recovery architecture, this means the target account must have equivalent network policies created and applied separately. The best practice is to automate this configuration using infrastructure-as-code or scripted account setup so that failover does not weaken access controls. Candidates should distinguish between replicable account objects and non-replicable account-level security settings. Snowflake documentation on replication/failover and network policies makes this distinction clear: network policies must be managed independently in each account to maintain consistent access restrictions.
- A. Correct.
Correct. Network policies are account-level security objects and are not replicated as part of database replication or account object replication through failover groups. To maintain consistent access controls in a replicated/failover design, the security engineer must recreate the network policy in the target account and explicitly apply it there, typically as part of DR runbooks or automation. This is the practical approach when minimizing risk during failover.
- B. Incorrect.
Incorrect. Failover groups replicate supported account objects such as users, roles, and certain grants, but network policies are not included as replicated objects. Also, network policies are not attached to databases; they are applied at the account, user, or security integration context depending on the feature being used. This option reflects a common misconception that all security objects are covered by failover groups.
- C. Incorrect.
Incorrect. There is no customer-managed SECURITY database that stores network policies for replication purposes. Network policies are account-level objects managed by Snowflake metadata and are not made replicable by enabling replication on a database. This distractor targets the misunderstanding that all security configurations are database-scoped.
- D. Incorrect.
Incorrect. Tags in Snowflake are governance metadata and do not cause security enforcement logic such as IP allow/block rules to be propagated or applied across accounts. Tagging a network policy would not make Snowflake enforce the same access restrictions in another account after replication.