ARA-C01 Question 148
Single answerData ExchangeA healthcare analytics company uses Snowflake to share curated claims data with several external partners. The company must meet the following requirements: partners should query the latest shared data without waiting for periodic file deliveries, partners must not be able to write back to the provider's data, and the provider wants to avoid creating and managing user accounts inside its own Snowflake account for each partner. Some partners already have Snowflake accounts, while one smaller partner does not. Which approach best satisfies these requirements with the least operational overhead?
- A
Create a secure data share for partners with Snowflake accounts, and provide a reader account for the partner that does not have a Snowflake account.
- B
Unload the curated claims data to cloud storage on a schedule and let each partner load the files into its own environment.
- C
Replicate the database into each partner's Snowflake account so they can query a local copy without depending on the provider account.
- D
Create individual database roles and user accounts in the provider's Snowflake account for every external partner, then grant SELECT privileges on the shared tables.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake Data Sharing: a secure share for partners that already have Snowflake accounts, and a reader account for the partner that does not. This design is a core Snowflake pattern for Data Exchange and direct B2B data distribution. Secure shares provide live access to current data without physically copying the underlying tables to the consumer, and access is read-only from the consumer perspective. Reader accounts extend this model to organizations that do not yet have their own Snowflake account. This reduces administrative burden compared with managing external users in the provider account and avoids the latency and operational complexity of file-based exports. Snowflake documentation on secure data sharing and reader accounts consistently positions these features as the preferred approach for controlled, near-real-time external data distribution.
- A. Correct.
Correct. A Snowflake secure data share allows live, read-only access to shared database objects without copying the data into the consumer account. Consumers with existing Snowflake accounts can create a database from the share and query the latest provider data immediately. For consumers without a Snowflake account, the provider can create a reader account, which gives the consumer read-only access to shared data without requiring the provider to provision standard users in its own account. This approach aligns directly with the requirements for near-real-time access, read-only consumption, and reduced administrative overhead.
- B. Incorrect.
Incorrect. Scheduled unloads to cloud storage create file-based data delivery rather than live sharing. This introduces latency, additional orchestration, storage management, and separate load logic for each consumer. It also shifts complexity to versioning, schema drift handling, and refresh timing. While it is a common legacy integration pattern, it does not meet the requirement for partners to query the latest shared data directly with minimal operational overhead.
- C. Incorrect.
Incorrect. Database replication is intended for account-level replication scenarios such as business continuity, disaster recovery, and cross-region/cloud data distribution within an organization's Snowflake environment. It is not the standard mechanism for external partner data distribution in place of data sharing. Replication creates additional storage and synchronization considerations and is not the simplest or most appropriate way to provide read-only partner access to current data.
- D. Incorrect.
Incorrect. Creating user accounts for external partners inside the provider's own Snowflake account increases operational and security overhead, which the scenario explicitly seeks to avoid. It also mixes external consumer identities into the provider's account boundary. Snowflake data sharing and reader accounts are designed specifically to avoid this model when distributing data externally.