SnowPro Advanced: Security Engineer Question 148
Single answerUnderstand the security implications of using secure objects, including views, functions, and proceduresA healthcare company shares patient analytics with an external partner through a Snowflake data share. The analytics team created a view that filters out direct identifiers and exposes only approved columns from a sensitive PATIENT_CLAIMS table. During a security review, the company discovers that the partner may still be able to infer details about the underlying table definition and business logic from query behavior and metadata. The security engineer must reduce metadata exposure while preserving the ability to share the derived dataset. Which action should the engineer take?
- A
Replace the existing view with a SECURE VIEW and share that secure object instead of the standard view.
- B
Keep the standard view, but revoke SELECT on the underlying PATIENT_CLAIMS table from the partner account.
- C
Convert the view into a materialized view, because materialized views do not expose underlying definition details.
- D
Wrap the query in a stored procedure, because procedures can be shared directly through Secure Data Sharing and hide all metadata automatically.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use a SECURE VIEW. Snowflake secure objects, including secure views, are intended to protect sensitive logic and reduce exposure of underlying metadata and implementation details. This matters especially when sharing derived data externally, because standard views can allow more inference about base objects or filtering logic than an organization intends. Revoking access to the base table is necessary for least privilege but does not by itself provide the protections of a secure object. Materialized views are not a substitute for secure views in this context. Stored procedures and functions have their own security considerations, but they are not the correct mechanism for publishing a shareable relational dataset in this scenario. This aligns with Snowflake guidance on secure views and secure data sharing best practices.
- A. Correct.
Correct. A SECURE VIEW is specifically designed to limit exposure of underlying implementation details compared with a standard view. In Snowflake, secure objects help prevent certain query optimizations and metadata exposure that could reveal information about underlying base tables, expressions, or business logic. Secure views are also required in many sharing scenarios where protecting the underlying definition is important.
- B. Incorrect.
Incorrect. Revoking SELECT on the base table is good least-privilege practice, but it does not address the main issue in the scenario: metadata and implementation-detail exposure from the view itself. A standard view can still expose more information than desired through query behavior and metadata, even if the consumer cannot directly query the base table.
- C. Incorrect.
Incorrect. A materialized view is primarily a performance and maintenance feature, not a control for hiding implementation details from consumers. Converting a standard view to a materialized view does not solve the secure-object requirement and is not the recommended approach for protecting metadata in shared derived datasets.
- D. Incorrect.
Incorrect. Stored procedures are executable program units, but they are not the mechanism used here to provide a shared relational dataset through Secure Data Sharing. Procedures also do not simply replace secure views for this purpose. The scenario requires sharing tabular query results while minimizing metadata exposure, which is what a secure view is intended to address.