ARA-C01 Question 137
Single answerSharing between different Snowflake accountsA data platform team at a retail company needs to provide near real-time access to curated sales data from its Snowflake production account to a separate Snowflake account used by an external analytics partner. The partner must be able to query the shared data without the retail company copying or unloading it, and the retail company wants to minimize ongoing administration as new tables are added to the curated schema. Which approach best meets these requirements?
- A
Create a secure data share from the production account, grant USAGE on the database and schema plus SELECT on the required objects to the share, and add the partner's Snowflake account as a consumer.
- B
Set up database replication from the production account to the partner's account so the partner receives a read-only copy that updates automatically.
- C
Unload the curated tables to cloud storage on a schedule and let the partner create external tables over the files in its own account.
- D
Create a reader account for the partner and publish a standard view-based share without using secure views because the data stays inside Snowflake.
Show answer and explanation
Correct answer: A
Explanation
The best solution is Snowflake Secure Data Sharing between accounts. It allows a provider account to share live, queryable data with a consumer account without physically copying or unloading the data. This directly addresses the requirements for near real-time access and minimal administrative overhead. In practice, the provider creates a SHARE object, grants privileges such as USAGE on the database and schema and SELECT on tables or secure views, and then adds the consumer account. For maintainability, future grants can be used for newly created tables in the shared schema where supported. If views are part of the shared design, they must be secure views to be shareable. Reader accounts are only appropriate when the recipient does not have a Snowflake account. Snowflake documentation on Secure Data Sharing, Reader Accounts, Secure Views, and Replication/Failover distinguishes these patterns and their intended use cases.
- A. Correct.
Correct. Secure data sharing is designed for sharing live data between Snowflake accounts without copying or unloading the data. The provider creates a share, grants the necessary privileges on the database, schema, and objects, and adds the consumer account. To reduce administration when new objects are added, the provider can also use future grants on supported object types in the shared schema. This approach gives the consumer near real-time access to the provider's data while the data remains stored only in the provider account.
- B. Incorrect.
Incorrect. Database replication is intended for account/business continuity and cross-region or cross-account replication scenarios under the same organization or for data movement, not the standard pattern for external partner consumption. Replication creates a replicated database rather than a zero-copy live share for the consumer. It is a heavier-weight solution than secure data sharing and does not best satisfy the requirement to let the partner query data without copying it.
- C. Incorrect.
Incorrect. Unloading to cloud storage and querying with external tables introduces data copies/files outside the provider account, additional orchestration, and higher operational overhead. It also does not provide the simplest near real-time access pattern when both parties already use Snowflake. This is a common misconception when teams think of cross-account exchange as a file-sharing problem rather than using Snowflake's native sharing features.
- D. Incorrect.
Incorrect. Reader accounts are used when the recipient does not already have a Snowflake account. In this scenario, the partner already has its own Snowflake account, so a direct share is more appropriate. Also, if views are shared, they must be secure views; standard views cannot be shared through secure data sharing because they could expose underlying details in ways Snowflake does not allow for shared objects.