ARA-C01 Question 217
Single answerViewsA retail company has a shared RAW_SALES table that contains PII such as customer email addresses and loyalty IDs. The architecture team must expose a curated SALES_CONSUMER view to analysts in multiple business units. Requirements are: analysts should only see rows for their own business unit, sensitive columns must be masked based on the analyst's role, and the solution should minimize the risk of downstream users bypassing the controls by querying base tables directly. Which design is the MOST appropriate?
- A
Create a secure view on RAW_SALES that applies a row access policy for business-unit filtering and masking policies on sensitive columns, then grant analysts access only to the secure view and not the base table.
- B
Create a standard view on RAW_SALES with a WHERE clause filtering on CURRENT_ROLE(), and grant analysts SELECT on both the view and RAW_SALES so query optimizer rewrites can improve performance.
- C
Create a materialized view on RAW_SALES for each business unit and rely on object ownership so that masking is inherited automatically from the source table even if analysts also have SELECT on RAW_SALES.
- D
Create a secure materialized view on RAW_SALES and define the masking logic directly inside the materialized view SELECT statement using CASE expressions; this is required because masking policies cannot be used with views.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to expose governed data through a secure view, enforce row-level restrictions with a row access policy, enforce column-level obfuscation with masking policies, and avoid granting consumers direct access to the underlying table. This aligns with Snowflake best practices for layered data access and centralized policy management. Secure views are specifically intended for scenarios where you want stronger data-sharing and governance semantics than standard views. Row access policies provide centralized row filtering, while masking policies provide centralized protection for sensitive columns based on context such as role. A key architectural principle is that if users retain SELECT privileges on the source table, they can bypass the view-based governance layer. Relevant Snowflake documentation includes guidance on secure views, row access policies, masking policies, and the principle of granting access to governed interfaces rather than raw objects.
- A. Correct.
Correct. This design best satisfies all stated requirements. A secure view is appropriate when you want to expose governed data while reducing exposure of underlying logic and limiting certain optimizer behaviors that could reveal sensitive details. Row-level restriction should be implemented with a row access policy, and sensitive columns should be protected with masking policies. Most importantly, analysts should not be granted access to the base table, because access to RAW_SALES would allow them to bypass the curated access path entirely.
- B. Incorrect.
Incorrect. A standard view can encapsulate logic, but granting analysts SELECT on RAW_SALES defeats the governance requirement because users could query the base table directly and bypass the view's filtering. Also, implementing row filtering purely with a WHERE clause based on CURRENT_ROLE() is less robust and maintainable than using a row access policy for centralized row-level governance.
- C. Incorrect.
Incorrect. Materialized views are designed primarily for performance optimization on precomputed query results, not as the primary governance mechanism for role-based masking and row-level security across many consumer groups. In addition, granting access to RAW_SALES still allows bypass of controls. Masking does not become safely enforceable simply because a materialized view exists, and ownership alone does not solve the access-path problem described in the scenario.
- D. Incorrect.
Incorrect. Snowflake supports secure views, but not secure materialized views. Also, masking policies can be applied to columns and are commonly used with tables and views in governed architectures. Implementing masking only with CASE expressions inside the SELECT statement is possible in some cases, but it is not the best governance pattern here because it scatters security logic instead of centralizing it in policies.