ARA-C01 Question 141
Single answerSharing across cloud providersA data provider runs Snowflake in AWS us-east-1 and needs to distribute a curated sales dataset to two external business partners: one partner uses Snowflake on Azure East US 2, and the other uses Snowflake on Google Cloud us-central1. The provider wants both partners to query the same shared dataset without building and operating separate ETL pipelines in each cloud. The architect must choose the most appropriate design while keeping the provider's operational overhead low. Which approach should the architect recommend?
- A
Create reader accounts for both partners in the provider's AWS region, because reader accounts support cross-cloud consumption without replication.
- B
Use database replication or failover groups to copy the database into provider-managed Snowflake accounts in Azure and Google Cloud, then create shares from those regional copies to the partners.
- C
Create a direct share from the AWS account and grant imported privileges to the Azure and Google Cloud consumer accounts, because Secure Data Sharing is cloud-agnostic.
- D
Unload the curated dataset to external stages in each cloud and let the partners create external tables, because this is the only supported method for cross-cloud data sharing.
Show answer and explanation
Correct answer: B
Explanation
For Snowflake Secure Data Sharing, direct shares are constrained by cloud and region locality: the provider and consumer must be in the same Snowflake region on the same cloud platform. When consumers are in different clouds or regions, the recommended architecture is to replicate the relevant database to Snowflake accounts in those target locations and then create local shares from the replicated database. This can be implemented using cross-region/cross-cloud database replication and, where appropriate, failover groups for broader account object replication management. Reader accounts do not remove the cross-region/cross-cloud limitation of native shares. External stages and external tables can be used as a workaround, but they introduce more engineering and operational effort and are not the preferred low-overhead Snowflake-native sharing design. This aligns with Snowflake documentation on Secure Data Sharing limitations and cross-region/cross-cloud replication best practices.
- A. Incorrect.
Incorrect. Reader accounts allow a provider to share data with consumers that do not already have their own Snowflake account, but the reader account is created under the provider's organization in a specific region/cloud. Reader accounts do not eliminate the regional/cloud locality requirement for native shares. This option reflects a common misconception that reader accounts are a universal cross-cloud sharing mechanism.
- B. Correct.
Correct. Native Secure Data Sharing requires the provider and consumer to be in the same cloud platform and region for direct sharing. To serve consumers in other clouds/regions, the provider must first make the data available there, typically by using database replication or failover groups to replicate eligible databases to Snowflake accounts in the target regions/clouds. The provider can then create shares from those replicated copies to local consumer accounts, avoiding separate custom ETL pipelines while preserving a Snowflake-native architecture.
- C. Incorrect.
Incorrect. Direct Secure Data Sharing is not cloud-agnostic. The consumer must access the share from a Snowflake account in the same region and cloud as the share provider. Granting imported privileges does not overcome cross-cloud limitations; imported privileges apply to objects from a shared database after the share is already established.
- D. Incorrect.
Incorrect. Unloading to cloud storage and having partners define external tables is a possible interoperability pattern, but it is not the only supported method for cross-cloud sharing. It also increases operational overhead, creates separate storage/data management concerns, and does not meet the goal of using the same shared dataset with low provider overhead as effectively as Snowflake replication plus local shares.