SnowPro Advanced: Security Engineer Question 147
Single answerSupport collaborative analysis without direct data exposureA healthcare provider stores regulated patient data in Snowflake and wants to let an external research partner analyze treatment trends without exposing any row-level patient records or granting the partner direct access to the provider's tables. The provider also wants to keep full control over the underlying data while enabling the partner to run approved analytical queries from the partner's own Snowflake account. Which solution best meets these requirements?
- A
Create a secure data sharing relationship and expose only secure views that aggregate and de-identify the source data for the partner
- B
Replicate the patient tables into the partner's Snowflake account and apply masking policies after replication
- C
Unload the patient data to an external stage with server-side encryption and let the partner query it from there
- D
Grant the partner's users imported privileges on the provider's database so they can query the base tables directly
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Secure Data Sharing with secure views that expose only approved, de-identified, or aggregated results. This is a core Snowflake pattern for collaborative analysis without direct data exposure because the consumer can query from their own Snowflake account while the provider retains ownership and control of the data. For sensitive datasets, sharing base tables is often inappropriate even if the platform itself is secure; instead, providers should publish secure views that enforce the intended level of disclosure. This aligns with Snowflake best practices around secure data sharing, secure views, and least-privilege access. Relevant Snowflake documentation areas include Secure Data Sharing, Secure Views, and data governance features such as masking policies and row access policies. In this scenario, masking and row access controls can complement governance, but the most direct and appropriate solution is sharing secure views rather than replicating, unloading, or exposing base tables.
- A. Correct.
Correct. Secure Data Sharing is designed to let consumers query shared data from their own Snowflake account without copying the underlying data. By sharing secure views instead of base tables, the provider can expose only aggregated or otherwise transformed results that support collaborative analysis while avoiding direct exposure of sensitive rows. Secure views are specifically intended to prevent users from seeing underlying query logic and can be used to present governed, limited datasets. This approach preserves provider control over the source objects while allowing near real-time analysis.
- B. Incorrect.
Incorrect. Replication or copying data into the partner's account increases data exposure and reduces the provider's control over the underlying regulated dataset. Applying masking policies after the data has already been replicated is not the best fit when the goal is to avoid direct data exposure in the first place. It also creates additional governance and lifecycle risks because a separate physical copy now exists outside the provider's account.
- C. Incorrect.
Incorrect. Unloading data to an external stage creates exported files outside Snowflake and is contrary to the requirement to support collaborative analysis without exposing raw row-level data. Encryption protects data at rest and in transit, but it does not solve the core requirement of preventing direct access to the underlying sensitive records. This option also adds operational overhead and weakens centralized governance.
- D. Incorrect.
Incorrect. Imported privileges can be used by consumers of shared databases, but granting access that allows querying base tables directly would violate the requirement to avoid exposing row-level patient records. The misconception here is assuming that sharing alone is sufficient; in this scenario, the provider must constrain what is shared by exposing only governed secure views or similarly restricted objects rather than the underlying sensitive tables.