ARA-C01 Question 140
Single answerSharing to a non-Snowflake customerA data provider uses Snowflake Business Critical Edition in AWS us-east-1 and wants to share a set of secure views with a strategic partner that does not have a Snowflake account. The partner needs read-only access as quickly as possible, and the provider wants to avoid requiring the partner to purchase Snowflake first. Which approach should the architect recommend?
- A
Create a reader account for the partner, grant access to a share-backed database in that reader account, and have the partner connect using credentials provided by the data provider.
- B
Create a direct share to the partner's corporate email address so the partner can query the shared secure views without a Snowflake account.
- C
Replicate the database to the partner's cloud account and allow the partner to query the replicated copy through the provider's Snowflake account.
- D
Export the secure view results to external stage files and send the partner pre-signed URLs as an equivalent alternative to secure data sharing.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use a reader account. In Snowflake, Secure Data Sharing normally occurs between Snowflake accounts. When the consumer is not yet a Snowflake customer, the provider can create a reader account on the consumer's behalf. This allows the provider to share data, including secure views, with controlled read-only access while keeping governance centralized. This is the documented Snowflake approach for sharing data with non-Snowflake customers. In practice, architects should also remember edition and regional considerations: sharing is account-based, and features such as Business Critical-to-non-Business Critical sharing may involve additional configuration requirements depending on the target account type and data protection expectations. Relevant Snowflake documentation includes Secure Data Sharing and Reader Accounts, which describe how providers create and manage reader accounts for consumers who do not already have Snowflake.
- A. Correct.
Correct. For consumers that do not have a Snowflake account, the provider can create a reader account. A reader account is a special type of Snowflake account created and managed by the provider, intended specifically for data consumers who are not already Snowflake customers. The provider can create a share, create a database from that share in the reader account, and grant the reader account access. This gives the partner read-only access without requiring them to buy Snowflake first. This is the standard Snowflake mechanism for sharing with non-Snowflake customers.
- B. Incorrect.
Incorrect. Direct secure sharing is account-to-account, not email-to-email. A consumer must have a Snowflake account identifier to receive a direct share. If the partner does not have a Snowflake account, the provider cannot bypass that requirement by sharing to an email address.
- C. Incorrect.
Incorrect. Database replication is not the mechanism for providing a non-customer with ad hoc read-only access. Replication is intended for business continuity, disaster recovery, migration, and certain cross-region/cross-cloud architectures between Snowflake accounts. It does not let a non-Snowflake customer query data without a Snowflake account, and the phrase 'through the provider's Snowflake account' also conflicts with Snowflake's account isolation model.
- D. Incorrect.
Incorrect. Exporting data to files is not equivalent to secure data sharing and does not preserve the benefits of live shared data, centralized governance, or secure views in the same way. It creates copied data, adds operational overhead, and weakens the provider's ability to control freshness and access centrally. While unloading data may be possible for other integration patterns, it is not the recommended Snowflake-native solution for sharing with a non-Snowflake customer.