ADA-C01 Question 436
Single answerGiven a scenario, implement sharing solutionsA healthcare analytics company uses Snowflake Business Critical Edition and must share a curated provider-performance dataset with an external partner for read-only analysis. The partner is on a different Snowflake account and is not allowed to copy the data outside Snowflake. The shared dataset includes a secure view that joins several internal tables and applies row-level filtering for only the partner's region. The company also needs to support future consumer accounts without recreating the share each time. Which solution best meets these requirements?
- A
Create a direct share containing the base tables and the secure view, grant imported privileges to the partner, and rely on the secure view to prevent data copying.
- B
Create a listing in a private data exchange and include the secure view; this prevents all forms of data copying by consumers and automatically applies row-level filters for each consumer account.
- C
Create a share that contains only the secure view and any required secure UDFs, then publish it through a listing so multiple consumer accounts can discover and access it without recreating separate shares.
- D
Replicate the database to the partner's account using database replication, then grant the partner SELECT on the replicated tables because replication is the only supported way to share Business Critical data securely.
Show answer and explanation
Correct answer: C
Explanation
The best solution is to share only the governed interface object, not the underlying tables, and to use a scalable distribution mechanism. In Snowflake, secure views are the standard way to expose filtered or masked datasets while protecting underlying logic and limiting direct access to base objects. When a shared view depends on UDFs, those UDFs must be secure as well. For scaling to multiple consumer accounts, listings and private data exchanges are preferable to creating and managing separate direct shares for each new consumer. However, administrators should remember that secure sharing provides live access without physically copying provider data into the consumer account by default, but it does not absolutely prevent a consumer from materializing query results they are allowed to see into their own objects. Relevant Snowflake documentation areas include Secure Data Sharing, Secure Views, and Listings/Data Exchange best practices.
- A. Incorrect.
Incorrect. A direct share can expose shared objects, but including base tables is unnecessary and can broaden data exposure beyond the intended filtered interface. Also, granting imported privileges is something done in the consumer account on a shared database for certain access patterns; it is not how the provider secures the share itself. Most importantly, a share does not guarantee that a consumer cannot copy results into their own objects unless additional controls such as provider-run applications or contractual controls are used. Secure views protect underlying object definitions and enable controlled data access, but they do not make copying impossible.
- B. Incorrect.
Incorrect. A private data exchange or listing can simplify distribution, but listings do not inherently prevent consumers from copying query results into their own tables if their account privileges allow it. In addition, row-level filtering is not automatically personalized per consumer account just because a listing is used. The provider must implement the filtering logic explicitly, typically through secure views and supported sharing patterns. This option overstates what listings do.
- C. Correct.
Correct. For cross-account sharing, the provider should expose only the approved interface object, such as a secure view, rather than raw base tables when filtered access is required. If the view depends on UDFs, those must also be secure and included as needed. To support multiple current and future consumer accounts without recreating separate direct shares, the provider can use a listing-based approach, such as a private listing or private data exchange, which allows discoverability and controlled access by multiple consumers. This aligns with Snowflake sharing best practices: use secure objects for governed data exposure and listings for scalable distribution.
- D. Incorrect.
Incorrect. Database replication is designed for disaster recovery, business continuity, and cross-region or cross-cloud replication scenarios, not as the primary mechanism for governed read-only data sharing to external consumers. Replication creates a replicated database, which is a different operational pattern from secure data sharing. It also does not solve the requirement to expose only a row-filtered curated dataset via a secure view.