ARA-C01 Question 47
Single answerSecure viewsA healthcare company stores patient encounter data in a shared database. The base table contains direct identifiers, quasi-identifiers, and billing details. The data architecture team must expose a subset of columns to an internal analytics role and later share the same curated dataset with an external partner. Security leadership is concerned that users could infer sensitive values by examining underlying query structures or optimization details. Which design best meets these requirements while preserving the ability to grant access to a curated result set?
- A
Create a secure view that selects only the approved columns from the base table, then grant the analytics role access to the secure view and use the secure view for data sharing.
- B
Create a standard view on the base table, because column projection alone prevents exposure of underlying logic and is sufficient for secure data sharing.
- C
Create a materialized view on the base table, because materialized views automatically hide the underlying query plan and are the recommended object for secure external sharing.
- D
Create a masking policy on the base table and share the base table directly, because masking policies remove the need for secure views when exposing curated subsets.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use a secure view. In Snowflake, secure views are intended for cases where architects need stronger protection around exposed data representations than standard views provide. They are commonly used to publish curated datasets internally and through Secure Data Sharing while reducing exposure of sensitive underlying details. This makes them a strong design choice when sharing data with external parties or when security teams want tighter controls over how derived data is exposed. Standard views are useful for abstraction but do not provide the same level of protection. Materialized views address performance, not this security requirement. Masking policies are valuable for dynamic protection of sensitive fields, but they do not replace the need for a secure shared projection when only specific columns should be exposed. Snowflake documentation on secure views and Secure Data Sharing aligns with this approach as a best practice for controlled external data access.
- A. Correct.
Correct. A secure view is specifically designed to limit exposure of underlying implementation details compared with a standard view. It is appropriate when the goal is to present a curated subset of data while preventing users from seeing certain internal details that could otherwise be exposed through view definitions or query behavior. Secure views are also supported for Secure Data Sharing, making this the best fit for both internal consumption and external sharing of the curated dataset.
- B. Incorrect.
Incorrect. A standard view can project only selected columns, but it does not provide the additional protections of a secure view. In scenarios where security teams want to reduce the possibility of exposing underlying logic or optimization details, a standard view is not the best choice. This option reflects the common misconception that column filtering alone is equivalent to using secure objects.
- C. Incorrect.
Incorrect. Materialized views are intended for performance optimization by storing precomputed results, not for replacing secure views as a data-sharing security boundary. While they may improve query performance for certain workloads, they are not the recommended answer to concerns about exposing underlying query structures in a shared curated dataset. The misconception here is confusing performance-focused design with security-focused design.
- D. Incorrect.
Incorrect. Masking policies can protect sensitive values at query time, but they do not inherently replace the need for a curated shared object when the requirement is to expose only a subset of columns and reduce exposure of underlying implementation details. Sharing the base table directly would typically expose more structure than necessary. Masking and secure views can complement each other, but a masking policy alone does not satisfy the stated design goal as well as a secure view.