ADA-C01 Question 433
Single answer5.1 Implement and manage data sharing.A data platform team at a provider account must share a curated SALES database with several external business partners. The partners should be able to query only a subset of rows from the ORDERS table based on region, and they must not see sensitive columns such as CUSTOMER_EMAIL. The provider wants to manage this centrally without copying data for each partner. Which approach should the Snowflake administrator implement?
- A
Create a secure share on the SALES database directly and grant imported privileges to the partners so they can apply their own filters after creating databases from the share.
- B
Create secure views that filter rows and exclude sensitive columns, place those secure views in a database/schema included in the share, and grant SELECT on the secure views to the share.
- C
Create standard views on the ORDERS table with the required filters, add the underlying table and the views to the share, and rely on the consumers' roles to prevent access to sensitive columns.
- D
Clone the SALES database for each partner, remove the restricted columns from each clone, and share the cloned tables because row-level restrictions cannot be enforced through Snowflake data sharing.
Show answer and explanation
Correct answer: B
Explanation
The best solution is to share secure views rather than base tables. In Snowflake Secure Data Sharing, providers control exactly which objects are exposed in a share. To restrict access to subsets of data without copying it, a common best practice is to create secure views that exclude sensitive columns and filter rows before granting SELECT on those views to the share. This keeps governance centralized in the provider account and prevents consumers from bypassing the intended restrictions. Snowflake documentation on secure data sharing and secure views emphasizes using secure objects when exposing curated or restricted datasets to consumers.
- A. Incorrect.
Incorrect. A share exposes only the objects and privileges explicitly granted by the provider. Consumer accounts cannot be expected to enforce the provider's row and column restrictions on shared base tables. If the provider shares the underlying table directly, consumers could query all exposed rows and columns. Also, imported privileges are used by consumers to access a shared database after creation, not as a mechanism for provider-side row filtering.
- B. Correct.
Correct. Snowflake data sharing commonly uses secure views to provide restricted access to shared data without copying it. Secure views can project only approved columns and apply WHERE clauses or policy-based logic to limit rows. The provider shares the secure views rather than the base table, allowing centralized control over what each consumer can query while keeping the underlying data hidden.
- C. Incorrect.
Incorrect. Standard views are not appropriate for secure data sharing scenarios because their definitions and optimization behavior do not provide the same protections as secure views. In addition, if the underlying table is also shared, consumers could bypass the view entirely and query the base table, exposing restricted columns and rows. Consumer-side roles do not solve provider-side data minimization requirements.
- D. Incorrect.
Incorrect. Cloning databases per partner would introduce unnecessary administrative overhead and is not required for standard Snowflake sharing use cases. Snowflake supports sharing without data copies, and row/column restrictions can be implemented through secure views and, where applicable, policy-based controls. This option reflects a common misconception that separate physical copies are needed for each consumer.