ARA-C01 Question 117
Single answerDomain 2.0: Snowflake Architecture (30%)A global retail company runs Snowflake in AWS us-east-1 for its primary analytics platform. The company is acquiring a regional brand that already uses Snowflake in Azure West Europe. For legal reasons, customer-level data for the regional brand must remain in Azure West Europe, but headquarters analysts in AWS us-east-1 need near real-time access to selected curated datasets from that region for consolidated reporting. The architecture team wants to minimize operational overhead, avoid building custom file movement pipelines, and ensure secure sharing across cloud platforms. Which Snowflake architecture approach best meets these requirements?
- A
Create a database replication and failover group from the Azure account to the AWS account, and allow analysts to query the replicated database directly for near real-time cross-cloud reporting.
- B
Use Secure Data Sharing directly from the Azure account to the AWS account so headquarters can query the provider's live data without copying it, even across cloud platforms.
- C
Configure database replication from Azure West Europe to AWS us-east-1 for the curated datasets, and have headquarters query the local replicated copy in AWS.
- D
Export curated datasets from Azure Snowflake to external cloud storage every few minutes and ingest them into AWS Snowflake with Snowpipe for cross-cloud reporting.
Show answer and explanation
Correct answer: C
Explanation
The best answer is to use Snowflake database replication for the curated datasets so they are available in the headquarters AWS account as a local replicated database. This aligns with Snowflake architecture best practices when data must remain mastered in one account/cloud/region but be made available in another with minimal custom engineering. Secure Data Sharing is highly efficient, but native direct sharing is not the right answer for cross-cloud account-to-account access in this scenario. Failover groups are valuable for disaster recovery and account object replication, but they are not the most targeted solution for an ongoing analytics consumption requirement focused on selected curated datasets. Snowflake documentation on replication and failover/grouping patterns distinguishes operational analytics replication from DR/failover objectives, and Snowflake sharing documentation distinguishes same-region sharing from scenarios that require replication-based architectures.
- A. Incorrect.
Incorrect. Failover groups are used for business continuity and disaster recovery orchestration across accounts/regions/clouds, including replication of groups of objects and account-level objects. While replication underpins failover groups, using a failover group specifically for this reporting requirement is not the best architectural fit. The scenario is about ongoing cross-cloud data access for analytics, not planned failover or DR management. It also adds unnecessary DR-oriented scope compared with straightforward database replication for selected curated datasets.
- B. Incorrect.
Incorrect. Secure Data Sharing does not support direct sharing across different cloud platforms. Native sharing works when provider and consumer accounts are in the same Snowflake region. For cross-region or cross-cloud sharing scenarios, organizations typically use replication-based patterns or listings/marketplace constructs where applicable, but not direct live querying across clouds with native secure sharing alone. Choosing this option reflects a common misconception that secure sharing works transparently across all regions and clouds.
- C. Correct.
Correct. Cross-cloud database replication is the Snowflake-native approach that fits this scenario. It allows selected databases containing curated datasets to be replicated from Azure West Europe to AWS us-east-1, where headquarters can query a local read-only copy with low operational overhead. This avoids custom file export/import pipelines and provides a secure, managed pattern for near real-time availability, subject to replication frequency and latency. It also supports the legal requirement that the source operational data remains in Azure while curated data is made available in AWS.
- D. Incorrect.
Incorrect. This approach can work technically, but it introduces significantly more operational overhead and complexity than necessary. The scenario explicitly asks to avoid custom file movement pipelines. Exporting to storage and reloading with Snowpipe requires orchestration, storage management, monitoring, and schema/data handling that Snowflake replication is designed to reduce. It is a plausible distractor because many teams build this pattern before learning Snowflake's native cross-region/cross-cloud replication capabilities.