ARA-C01 Question 48
Single answerSecure viewsA healthcare company stores PHI in a base table SALES_DB.PATIENT_DATA.CLAIMS. Multiple analyst roles need access to only a subset of columns and rows, and the security team is concerned that exposing the view definition could reveal masking logic and sensitive filtering criteria. The company also wants to share the curated dataset with a third party through Secure Data Sharing without exposing underlying implementation details. Which approach best meets these requirements?
- A
Create a standard view on CLAIMS with the required row and column filters, and grant SELECT on the view to analysts and to the share.
- B
Create a secure view on CLAIMS with the required row and column filters, and grant SELECT on the secure view to analysts and to the share.
- C
Create a materialized view on CLAIMS with the required row and column filters, because materialized views automatically hide the underlying SQL definition from consumers.
- D
Create a standard view on CLAIMS and use RESULT_SCAN to prevent consumers from seeing the view text while querying shared data.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use a secure view. In Snowflake, secure views are intended for cases where exposing the underlying view text, table structure relationships, or filtering logic would create a security risk. This is especially relevant when sharing data with external parties using Secure Data Sharing. A secure view allows the architect to expose only approved rows and columns while helping prevent consumers from accessing the underlying implementation details that can be visible with standard views. Standard views may be sufficient for internal abstraction, but they are not the right choice when definition protection and secure sharing are explicit requirements. Materialized views are a performance feature, not a replacement for secure views in data-governance scenarios. Snowflake documentation and architecture guidance consistently position secure views as the recommended mechanism for sharing protected derived datasets and limiting metadata exposure.
- A. Incorrect.
Incorrect. A standard view can enforce row and column restrictions, but it does not provide the metadata and definition-protection properties required here. For secure data sharing scenarios, secure views are the appropriate construct when the provider must prevent consumers from accessing underlying implementation details. This option addresses filtering but not the requirement to protect the view definition and sensitive logic.
- B. Correct.
Correct. A secure view is designed for scenarios where the query logic and underlying structures should not be exposed to consumers. It can be used to present only the permitted subset of rows and columns, and it is the appropriate type of view for Secure Data Sharing when the provider wants to share derived data without revealing the underlying SQL text or implementation details. This aligns with Snowflake best practices for protecting sensitive business logic and limiting metadata exposure.
- C. Incorrect.
Incorrect. Materialized views are primarily for performance optimization, not for protecting view definitions in sharing scenarios. They do not replace secure views when the requirement is to hide implementation details from consumers. Choosing this option reflects a common misconception that persistence or optimization features imply stronger metadata security.
- D. Incorrect.
Incorrect. RESULT_SCAN is used to query a previous query result set within a session context; it is not a security mechanism for hiding a view definition or controlling metadata exposure in shared datasets. A standard view combined with RESULT_SCAN does not meet the requirement to securely share filtered data while protecting underlying logic.