Study guide
6.1 Database & Account Replication Mechanics
SnowPro Advanced: Architect ARA-C01
Track your progress as you read
Finished sections get a check mark.
1 Introduction: The ARA-C01 Exam
About the SnowPro Advanced: Architect (ARA-C01) Exam
2 Chapter 1: Account Strategy & Organization Architecture
1.1 Multi-Account Strategy & Snowflake Organizations 1.2 Snowflake Parameter Hierarchy & Configuration 1.3 Database and Schema Design Architecture
3 Chapter 2: Identity, Access Control & Storage Integrations
2.1 Role-Based Access Control Architecture & Hierarchy 2.2 Secondary Roles, Object Ownership & Delegated Administration 2.3 Cloud Storage Integrations & IAM Trust Policies 2.4 Identity Federation, SSO, SCIM & Authentication Policies
4 Chapter 3: Governance, Data Privacy, Network Security & Compliance
3.1 Column-Level Masking & Row Access Policies 3.2 Object Tagging, Tag-Based Masking & Audit Governance 3.3 Encryption, Key Management & Tri-Secret Secure 3.4 Aggregation Policies, Projection Policies & External Tokenization 3.5 Network Policies, Network Rules, External Access & Private Connectivity 3.6 Snowflake Editions & Compliance Architecture (PCI DSS, PII & PHI)
5 Chapter 4: Data Modeling in Snowflake
4.1 Dimensional Modeling: Star vs. Snowflake Schemas 4.2 Data Vault 2.0 Architecture in Snowflake 4.3 Relational Constraints & Query Optimizer Integration
6 Chapter 5: Data Sharing & Collaboration Solutions
5.1 Direct Data Sharing Architecture & Security 5.2 Managed Reader Accounts for External Consumers 5.3 Snowflake Marketplace, Data Exchange & Clean Rooms
7 Chapter 6: Multi-Cloud, Multi-Region & Business Continuity
6.1 Database & Account Replication Mechanics 6.2 Disaster Recovery Architecture & Client Redirect 6.3 Cross-Cloud Auto-Fulfillment & Listing Replication 6.4 Data Protection: Time Travel, Fail-safe & Storage Costs
8 Chapter 7: Environments, Lakehouse, DevOps & AI/ML Applications
7.1 Multi-Tier Environment Strategy & Zero-Copy Cloning 7.2 Data Lakehouse Architecture & Apache Iceberg 7.3 DataOps, CI/CD & Snowflake Git Integration 7.4 AI/ML Pipelines & Applications: Cortex AI, ML Functions, Snowpark Container Services, Streamlit & Native Apps
9 Chapter 8: Data Ingestion Architecture
8.1 Bulk Ingestion Architecture: COPY INTO Optimization 8.2 Snowpipe Continuous Automated Ingestion 8.3 Snowpipe Streaming & Real-Time Ingestion 8.4 Data Unloading Architecture & Cloud Export Patterns 8.5 Schema Detection, Schema Evolution & Source-Change Architecture
10 Chapter 9: Continuous Pipelines & Stream Transformation
9.1 Change Data Capture (CDC) with Snowflake Streams 9.2 Task Orchestration, DAGs & Serverless Scheduling 9.3 Declarative Data Pipelines with Dynamic Tables 9.4 Views, Materialized Views & Transformation Table Design
11 Chapter 10: Semi-Structured Data & Ecosystem Tooling
10.1 Semi-Structured Data: VARIANT, OBJECT & ARRAY Processing 10.2 Snowflake Ecosystem Connectors, Drivers & SQL API 10.3 Snowpark, User-Defined Functions & Stored Procedures
12 Chapter 11: Virtual Warehouse Architecture & Concurrency
11.1 Virtual Warehouse Architecture, Sizing & Credit Economics 11.2 Multi-Cluster Warehouses & Concurrency Scaling Policies 11.3 Warehouse Types & Query Acceleration Service
13 Chapter 12: Query Profiling & Performance Diagnostics
12.1 Query Profile Deep-Dive & Bottleneck Analysis 12.2 Memory Spilling, Warehouse Queuing & Timeout Governance 12.3 Three-Tier Caching Architecture & Result Reuse
14 Chapter 13: Storage Optimization, Cost Governance & Observability
13.1 Micro-Partitioning & Automatic Clustering 13.2 Search Optimization Service (SOS) & Point Lookup Acceleration 13.3 Resource Monitors, Financial Governance & Usage Observability 13.4 Warehouse Monitoring, Alerts, Event Tables & Performance Explorer
6.1 Database & Account Replication Mechanics
Key Takeaways Explain This Topic AI
Replication and failover groups replicate databases and shares, plus account objects such as users, roles, warehouses, resource monitors, network policies, integrations, and account parameters; database and share replication work in every edition, while other account objects and failover require Business Critical.
Replication Groups (CREATE REPLICATION GROUP) provide unidirectional read-only synchronization across cloud regions, whereas Failover Groups (CREATE FAILOVER GROUP) enable promoting a secondary group to a read-write primary for disaster recovery.
Secondary databases and replicated objects are strictly read-only; attempts to execute DML or DDL against secondary replicas fail with an explicit read-only error.
Replication synchronization runs on Snowflake serverless compute; costs comprise cloud provider data egress charges on the primary account, serverless compute credits, and secondary storage charges.
Masking and row access policies are schema-level objects replicated with their database; if a policy lives in a database outside the group (a dangling reference), the group containing the policy must be replicated first.
Last updated: September 2026
6.1 Database & Account Replication Mechanics
Enterprise data platforms cannot tolerate single-cloud or single-region vulnerabilities. Natural disasters, regional cloud networking partitions, regulatory shifts, and cloud service provider outages demand robust multi-cloud and multi-region business continuity strategies. Snowflake provides native, cross-cloud account and database replication capabilities across Amazon Web Services (AWS) , Microsoft Azure , and Google Cloud Platform (GCP) without requiring third-party extraction tools, external message buses, or bespoke ETL pipelines.
For the SnowPro Advanced: Architect exam, you must master the mechanics of Snowflake's replication engine, understand the architectural distinction between Replication Groups and Failover Groups, design synchronization schedules, manage dependent security policies, and evaluate the financial cost model of cross-cloud data movement.
Replication Architecture & Multi-Cloud Topology
Snowflake replication operates by creating point-in-time metadata snapshots of primary objects and transferring delta micro-partitions asynchronously to one or more target secondary accounts across cloud providers and geographical regions. ┌─────────────────────────────────────────────────────────────────┐
- │ Snowflake Organization │
- │ │
- │ ┌───────────────────────────┐ Replication Delta Transport │
- │ │ Primary Account (AWS) │ ──────────────────────────────┐ │
- │ │ • Primary Database (R/W) │ │ │
- │ │ • Users, Roles, Warehouses│ ▼ │
- │ │ • Resource Monitors │ ┌───────────────────────────┐
- │ └───────────────────────────┘ │ Secondary Account (Azure) │
- │ │ │ • Secondary Database (RO) │
- │ │ Replication Delta Transport │ • Synced RBAC & Monitors │
- │ ▼ └───────────────────────────┘
- │ ┌───────────────────────────┐ │
- │ │ Secondary Account (GCP) │ │
- │ │ • Secondary Database (RO) │ │
- │ │ • Synced RBAC & Monitors │ │
- │ └───────────────────────────┘ │
- └─────────────────────────────────────────────────────────────────┘
- Primary vs. Secondary Objects
Primary Database / Object : Resides in the authoritative source account. The primary database is read-write ; all ingestion pipelines, transformations, ETL/ELT tasks, and analytical writes execute against the primary.
Secondary Database / Object : Resides in a replica target account. Secondary databases are strictly read-only . Any attempt to execute write DML ( INSERT , UPDATE , DELETE , MERGE ), truncate tables, or execute DDL creating new schemas or tables inside a secondary database returns an error: -- Executed in secondary account
INSERT INTO target_db.public.orders VALUES (101, 'ACTIVE', CURRENT_TIMESTAMP());
-- Result: SQL compilation error: Operation not allowed on secondary database 'TARGET_DB'.
Database Replication vs. Account Replication
Snowflake replication has evolved across two major architectural generations:
Legacy Database Replication ( ALTER DATABASE ... ENABLE REPLICATION ) :
Operates strictly at the individual database boundary.
Replicates only the database schema and table micro-partitions.
Critical Architectural Flaw : Fails to replicate account-level RBAC roles, users, warehouse definitions, network policies, or resource monitors. If a replicated table has a row access policy or masking policy referencing an account role that does not exist in the target account, queries fail or policy evaluation breaks upon secondary access.
Account Replication (Replication & Failover Groups) :
Modern enterprise standard introduced to synchronize entire operational environments.
Groups multiple databases and global account objects into a single, transactionally consistent replication unit.
Replicates databases and shares alongside account objects such as USERS , ROLES , WAREHOUSES , RESOURCE MONITORS , NETWORK POLICIES , INTEGRATIONS (security, API, storage, external access, and some notification integrations), and ACCOUNT PARAMETERS . Policies such as masking, row access, session, and password policies are schema-level objects, so they replicate as part of the database that contains them.
Edition rule: database and share replication are available to all editions; replicating other account objects and failover/failback require Business Critical Edition or higher.
Prerequisite: an organization administrator must enable replication for the source and target accounts before groups can be created.
Supported Replicated Object Types
When defining modern replication groups, architects specify the exact set of object types synchronized across accounts:
Object Type Identifier Replicated Primitives & Metadata
DATABASES Databases listed in ALLOWED_DATABASES , including their schema objects (tables, views, sequences, UDFs, tags, masking/row access/session/password policies, and more).
SHARES Shares listed in ALLOWED_SHARES .
ROLES Account roles and the grants on replicated object types; role grants to users replicate when USERS is also included.
USERS User objects and their properties.
WAREHOUSES Warehouse definitions (size, auto-suspend, multi-cluster settings).
RESOURCE MONITORS Resource monitors in the source account.
NETWORK POLICIES Network policies in the source account (include the database holding their network rules to avoid dangling references).
INTEGRATIONS Security, API, storage, external access, and some notification integrations (requires ALLOWED_INTEGRATION_TYPES ).
ACCOUNT PARAMETERS , EXTERNAL VOLUMES , LISTINGS , PROFILES Account-level parameters and other supported objects.
Exam Trap: There is no POLICIES object type. Governance policies travel inside DATABASES .
Replication Groups vs. Failover Groups
A critical distinction on the SnowPro Advanced: Architect exam is the functional and operational boundary between a Replication Group and a Failover Group .
Architectural Comparison
- Dimension Replication Group Failover Group
- DDL Command CREATE REPLICATION GROUP CREATE FAILOVER GROUP
Primary Purpose Read-only distribution, multi-region reporting, cross-cloud sharing enablement Business continuity, disaster recovery (DR), operational failover
Secondary Promotion Unsupported . A secondary replication group cannot be promoted to primary Supported . Secondary failover group can be promoted to primary via ALTER ... PRIMARY
Replication Direction Unidirectional (Primary -> Secondary) Bidirectional lifecycle (Primary -> Secondary, reversible upon failover)
Target Topology One primary to multiple read-only secondary accounts One primary to multiple secondary accounts enabled for failover
- Client Redirect Support None Integrates directly with Snowflake CONNECTION objects for seamless failover
- Defining a Failover Group on the Primary Account
To establish a Failover Group, an administrator holding the ACCOUNTADMIN role executes CREATE FAILOVER GROUP on the primary source account. The group specifies which object types to replicate, which specific databases to include, which target accounts in the organization are authorized replicas, and the automated refresh schedule. -- Step 1: Switch to ACCOUNTADMIN on Primary Account (e.g., prod_aws_useast1)
USE ROLE ACCOUNTADMIN;
- - Step 2: Create the primary failover group
- CREATE FAILOVER GROUP fg_enterprise_dr
- OBJECT_TYPES = USERS, ROLES, WAREHOUSES, RESOURCE MONITORS, DATABASES, NETWORK POLICIES
ALLOWED_DATABASES = sales_dw, finance_dw, crm_dw, governance_db -- include the database holding shared policies
- ALLOWED_ACCOUNTS = acme_org.prod_azure_westeurope, acme_org.prod_gcp_uscentral1
- REPLICATION_SCHEDULE = '15 MINUTE';
- Creating the Secondary Failover Group on the Target Account
Once the primary failover group is defined and permissions are established within the Snowflake Organization, the target account administrator creates the secondary replica referencing the organization account identifier of the source: -- Step 3: Switch to ACCOUNTADMIN on Secondary Account (e.g., prod_azure_westeurope)
USE ROLE ACCOUNTADMIN;
- - Step 4: Create secondary replica of the failover group
- CREATE FAILOVER GROUP fg_enterprise_dr
- AS REPLICA OF acme_org.prod_aws_useast1.fg_enterprise_dr;
Note: The secondary group's name can be — but is not required to be — the same as the primary's; keeping them identical makes runbooks clearer. AS REPLICA OF must reference the primary group as <org_name>.<source_account_name>.<group_name> .
Synchronization Mechanics & Scheduling
Replication in Snowflake is driven by a point-in-time metadata snapshot and differential micro-partition extraction. The synchronization process can be scheduled automatically or triggered ad-hoc via DDL.
- Synchronization Workflow 1. Scheduled / Manual Trigger
- │
- ▼
- 2. Snapshot Generation ──► Primary account freezes point-in-time metadata snapshot
- │
- ▼
- 3. Delta Calculation ──► Identifies newly committed micro-partitions & metadata modifications
- │
- ▼
- 4. Cloud Egress & Transport ──► Micro-partitions encrypted & streamed across cloud networks
- │
- ▼
- 5. Target Ingestion ──► Secondary account commits micro-partitions to local cloud object storage
- │
- ▼
- 6. Metadata Pointer Update ──► Secondary catalog atomically updates metadata pointers
- Scheduling Synchronization
Automated replication schedules are defined using the REPLICATION_SCHEDULE parameter on the primary failover group: -- Interval-based schedule (every 10 minutes)
- ALTER FAILOVER GROUP fg_enterprise_dr
- SET REPLICATION_SCHEDULE = '10 MINUTE';
- - Cron-based schedule (every weekday at 02:00 UTC)
- ALTER FAILOVER GROUP fg_enterprise_dr
- SET REPLICATION_SCHEDULE = 'USING CRON 0 2 * * MON-FRI UTC';
- Manual Ad-Hoc Refresh
Administrators can trigger an immediate manual synchronization directly on the secondary account. This is a common architectural pattern prior to conducting planned maintenance or disaster recovery drills: -- Executed on Secondary Account to pull latest delta changes immediately
- USE ROLE ACCOUNTADMIN;
- ALTER FAILOVER GROUP fg_enterprise_dr REFRESH;
- Serverless Compute Execution Engine
A pivotal architectural principle tested on the ARA-C01 exam is that Snowflake replication does not require an active virtual warehouse . The replication engine runs entirely on Snowflake-managed serverless compute infrastructure :
Virtual warehouses are not spun up or billed for replication tasks.
Compute consumption is measured in serverless compute credits, appearing under the REPLICATION service type in credit billing views.
Snowflake automatically scales the underlying serverless compute resources to handle large initial seed loads versus small incremental micro-partition deltas.
Monitoring Replication Telemetry
Architects monitor synchronization performance, transferred byte volumes, and operational status using dedicated ACCOUNT_USAGE views: -- Inspect replication refresh history and duration across groups
- SELECT
- replication_group_name,
- phase_name,
- start_time,
- end_time,
- total_bytes,
- status,
- error_code,
- error_message
- FROM snowflake.account_usage.replication_group_refresh_history
- WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
- ORDER BY start_time DESC;
- - Monitor serverless credit consumption for replication
- SELECT
- start_time,
- end_time,
- replication_group_name,
- credits_used
- FROM snowflake.account_usage.replication_group_usage_history
- WHERE start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
- ORDER BY start_time DESC;
Financial Economics & Cost Model
Cross-cloud and cross-region replication introduces three distinct cost components that data architects must budget and optimize:
1. Cloud Provider Data Egress Charges
When data travels across regions or across cloud providers (e.g., from AWS us-east-1 to Azure westeurope ), the source cloud provider levies data transfer fees for outbound network egress.
Snowflake passes these cloud egress charges directly through to the customer contract at standard cloud provider rates per gigabyte.
Data transferred within the same cloud provider and same region incurs zero data egress fees.
2. Serverless Replication Compute Credits
The Snowflake serverless replication service consumes Snowflake credits to calculate micro-partition differences, generate snapshots, and write remote catalog metadata.
Billed per-second based on serverless compute time utilized during each refresh cycle.
3. Remote Cloud Storage Charges
Micro-partitions replicated to the target account reside physically in the target cloud provider's object storage (e.g., Azure Blob Storage or Google Cloud Storage).
Storage in the secondary account is billed at the target region's standard Snowflake storage rate per terabyte per month.
Replicated databases consume storage for active data micro-partitions and Time Travel history according to the target account's retention settings.
Replication Cost Summary Matrix
Cost Component Billed Account / Entity Cost Driver Optimization Architectural Strategy
Data Transfer (Egress) Primary (Source) Account Gigabytes transferred across cloud/region boundaries Increase replication interval for non-critical data; avoid replicating high-churn transient staging tables
Serverless Compute Secondary (Target) Account Duration and frequency of snapshot delta synchronization Align REPLICATION_SCHEDULE to real RPO requirements rather than arbitrarily high frequencies
Remote Storage Secondary (Target) Account Terabytes of active micro-partitions and Time Travel history Use transient databases for ETL staging; purge unneeded historical tables before replicating
- Architectural Scenarios & Exam Traps
- Exam Trap 1: Dangling References to Policies and Other Objects
Policies are schema objects. If tables in sales_dw are protected by masking policies stored in governance_db , and governance_db is not in the same group, the table has a dangling reference . Snowflake requires that the group containing a data-protecting security policy be replicated before any group whose objects reference it; the simplest design keeps the policy database in the same group. Network policies similarly need the database that holds their network rules, and ROLES should be replicated so ownership and grants exist in the target. ACCOUNT_USAGE.OBJECT_DEPENDENCIES helps find these references before you design groups.
Exam Trap 2: Replicating Internal vs. External Stages
External Stages : Replicate metadata only (URL, storage integration name, encryption specs). Cloud object storage files referenced by external stages are not moved.
Internal Stages : Named internal stages can be replicated if explicitly included and enabled in replication configurations, but staging large uncompressed files directly inflates data transfer egress costs.
Exam Trap 3: Dropping Objects in Primary vs. Secondary
Dropping a database in the primary account propagates during the next refresh, dropping the secondary replica.
Dropping a secondary database directly on the target account is prohibited while it is linked to an active replication or failover group; the secondary failover group must be dropped first.