ARA-C01 Question 149
Single answerData sharing methodsA data platform team at a retail company must provide near real-time access to curated sales data to three external business partners. The partners use separate Snowflake accounts in different regions and cloud providers. The retail company wants to minimize operational overhead, avoid copying data into partner-owned tables, and ensure each partner only sees its own subset of rows. Which approach should the architect recommend?
- A
Create a secure data share directly to each partner account and include a secure view with a row access policy that filters rows by the consumer account identifier.
- B
Replicate the database to each partner region, have each partner create local tables from the replicated database, and use masking policies in the consumer accounts to enforce partner-specific visibility.
- C
Unload the curated data to cloud storage in each region and let partners ingest it using Snowpipe so the company can control row-level visibility during ingestion.
- D
Create reader accounts for all three partners and expose the curated tables through standard views, because reader accounts support cross-cloud and cross-region sharing without requiring partner Snowflake accounts.
Show answer and explanation
Correct answer: A
Explanation
The best recommendation is to use Snowflake Secure Data Sharing with secure views, combined with row-level governance such as row access policies, so each consumer only sees authorized rows. This aligns with Snowflake best practices for sharing governed live data without ETL duplication. For consumers in other regions or clouds, Snowflake supports cross-region and cross-cloud data sharing patterns through provider-managed sharing constructs and listings, rather than requiring manual unload/reload workflows. Key architectural principles tested here are: shared data remains live and read-only for consumers, secure views should be used when exposing transformed or filtered data, and governance should be enforced by the provider rather than relying on consumers to implement it. Relevant Snowflake documentation includes topics on Secure Data Sharing, secure views, row access policies, reader accounts, and cross-cloud/cross-region sharing considerations.
- A. Correct.
Correct. Direct Secure Data Sharing is designed to provide live, read-only access to data without copying it into consumer-owned tables. To restrict each partner to its own rows, the provider can share secure views rather than base tables, and apply a row access policy to enforce row-level filtering. Because the consumers are in different regions and cloud platforms, the architect would use listing/fulfillment mechanisms backed by cross-region and cross-cloud sharing capabilities rather than forcing physical copies into partner tables. This approach best meets the requirements of minimal operational overhead, no data duplication for consumers, and partner-specific row visibility.
- B. Incorrect.
Incorrect. Database replication is a disaster recovery and distribution mechanism, but it is not the best fit for this requirement. It introduces additional administrative complexity and does not by itself satisfy the goal of avoiding partner-owned copies, especially if partners create local tables from the replicated data. Also, provider-defined row-level controls should be enforced in the shared objects, not delegated to masking policies created in consumer accounts.
- C. Incorrect.
Incorrect. Unloading to cloud storage and re-ingesting with Snowpipe creates duplicated data and significantly more operational overhead. It also moves away from Snowflake sharing features intended for live, governed access. While file-based distribution can be used in some integration patterns, it does not meet the stated requirement to avoid copying data into partner-owned tables and is less suitable for near real-time governed sharing.
- D. Incorrect.
Incorrect. Reader accounts are useful when the consumer does not already have a Snowflake account. In this scenario, all partners already use separate Snowflake accounts. In addition, reader accounts are not the solution for broad cross-cloud/cross-region distribution to existing customer-managed Snowflake accounts. Standard views are also not appropriate for data sharing; secure views are required when exposing derived objects through shares.