ARA-C01 Question 153
Single answerSecurity patterns for data sharingA healthcare analytics company uses Snowflake to share curated patient trend data with several external research partners. The company must ensure that each partner can access only the rows for its own region, while the provider retains full control over the shared objects and avoids copying data into separate databases for each partner. The architect wants a scalable design that minimizes operational overhead as new partners are added. Which approach should the architect implement?
- A
Create a separate secure data share for each partner, and in each share include a secure view that filters rows based on that partner's region.
- B
Create one data share that contains the base tables, and rely on each consumer account to apply its own row access policies after the share is imported.
- C
Create one data share with standard views over the provider tables, and grant partners access to different virtual warehouses so they only see their own regional data.
- D
Unload each partner's regional data to stage files and let each consumer create an external table so row-level security is enforced outside Snowflake.
Show answer and explanation
Correct answer: A
Explanation
For secure data sharing, the provider should enforce access controls in the provider account, not depend on consumers to limit access after data is shared. When different consumers must see different subsets of the same source data, a common Snowflake pattern is to expose secure views through shares, often creating consumer-specific secure views or shares where needed. Secure views help protect underlying business logic and support governed sharing without data duplication. In contrast, sharing base tables directly exposes all rows in those tables, and compute constructs such as warehouses do not provide row-level security. This aligns with Snowflake documentation on Secure Data Sharing and secure views as a mechanism for safely exposing filtered datasets to data consumers.
- A. Correct.
Correct. A provider can share secure views, and secure views are a common security pattern for data sharing when the provider must control exactly what each consumer can see. Creating a partner-specific secure view per share allows the provider to enforce row filtering centrally without copying data into separate physical tables. This is operationally scalable compared with duplicating datasets, and it aligns with Snowflake data sharing best practices where consumers access shared objects read-only and governance remains with the provider.
- B. Incorrect.
Incorrect. Consumers cannot be relied upon to enforce provider-side security requirements for shared data. The provider must enforce row-level restrictions before or as part of sharing. Sharing base tables directly would expose all rows in those tables to the consumer. Applying row access policies in the consumer account after importing the share does not prevent the consumer from already having access to the underlying shared data.
- C. Incorrect.
Incorrect. Standard views are not the recommended mechanism for securely sharing filtered data because secure views are specifically designed to protect underlying logic and prevent exposure through query optimization behaviors. Also, warehouses control compute resources, not data visibility. Granting different warehouses does not restrict which rows a consumer can query from shared objects.
- D. Incorrect.
Incorrect. Unloading data to files and having consumers create external tables introduces unnecessary data movement, additional storage and governance complexity, and loss of the simplicity of Snowflake secure sharing. It also conflicts with the requirement to avoid copying data into separate datasets for each partner. This pattern is not the best fit when Snowflake secure data sharing can provide controlled, live access directly.