SnowPro Advanced: Security Engineer Question 198
Single answer2.6 Configure and maintain data replication policies and procedures.A financial services company uses Snowflake across two regions for business continuity. The primary account hosts a database that contains highly sensitive customer data protected by row access policies, masking policies, and tags. The security engineer must implement cross-region replication so the secondary account can be promoted during a regional outage with the same security controls intact. During testing, the team also wants to ensure that changes to data and security objects in the primary can be propagated on a defined cadence with minimal manual effort. Which approach should the security engineer take?
- A
Create a replication group in the primary account that includes the database and relevant account-level objects, enable replication to the target account, and configure a refresh schedule so replicated security metadata stays current.
- B
Share the database to the secondary account and create local masking policies and row access policies in the secondary account, because policy objects are not replicated with databases.
- C
Use database replication only for the source database, then manually recreate tags and policy references in the target account after each refresh because security objects cannot be included in replication configurations.
- D
Export the database DDL and security policy definitions to scripts, store them in an internal stage, and run them in the secondary account after failover because scheduled replication does not support security-related metadata.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake replication/failover capabilities designed for business continuity, specifically a replication group that includes the protected database and any required eligible account objects so security controls remain aligned in the secondary account. This approach supports regular refresh operations on a schedule, reducing manual administration and improving failover readiness. Snowflake documentation on replication and failover emphasizes using replication groups/failover groups to manage databases and supported account objects across accounts/regions, rather than relying on shares or manual scripting. For a Security Engineer, the key point is that disaster recovery planning must account for both the data and the security framework around the data, including supported policies, tags, and related metadata, and that these should be maintained through native replication procedures wherever supported.
- A. Correct.
Correct. For business continuity involving protected data, Snowflake supports replication groups that can replicate databases and eligible account-level objects together, which is important when security controls such as policies and tags must remain consistent in the failover environment. Configuring replication and a refresh schedule helps keep both data and supported metadata synchronized with minimal manual effort. This is the appropriate operational approach for maintaining replication policies and procedures.
- B. Incorrect.
Incorrect. Secure data sharing is not a failover or disaster recovery mechanism and does not create an independently promotable replica for outage recovery. In addition, this option incorrectly assumes policy objects must always be recreated locally rather than using supported replication/failover capabilities. While sharing can expose data, it does not satisfy the requirement for coordinated cross-region business continuity with replicated security controls.
- C. Incorrect.
Incorrect. This reflects a common misconception that only table data can be replicated and security metadata must always be recreated manually. Snowflake replication can include supported security-related metadata when configured appropriately. Relying on manual recreation after each refresh increases operational risk and does not meet the requirement for minimal manual effort.
- D. Incorrect.
Incorrect. Script-based export and re-deployment is a manual workaround, not the recommended Snowflake-native approach for ongoing replication and failover readiness. Scheduled replication is specifically intended to reduce manual intervention and preserve supported metadata consistently. This option would be error-prone and operationally weaker than using replication groups and scheduled refresh.