ADA-C01 Question 177
Single answerCompare row access policies to secure viewsA healthcare company stores patient claim records in a shared CLAIMS table. Internal analysts in different business units should see only rows for their assigned REGION, while an external auditor should be able to query a curated object without seeing the underlying table definition in query plans or metadata exposed through object definitions. The Snowflake administrator wants the solution to minimize duplicated logic for row-level filtering across multiple consuming objects while also meeting the auditor's metadata-protection requirement. Which approach best meets these requirements?
- A
Create a row access policy on CLAIMS for REGION-based filtering, and expose the auditor-facing dataset through a secure view built on the protected table.
- B
Create a standard view on CLAIMS with a WHERE REGION = CURRENT_ROLE() filter, because standard views hide the base table definition from consumers and remove the need for policies.
- C
Create only a secure view on CLAIMS with all REGION filtering logic embedded in the view definition, because secure views can be attached directly to multiple tables and centrally reused.
- D
Create a masking policy on the REGION column and a standard view for the auditor, because masking policies enforce row-level visibility and standard views provide the same metadata protection as secure views.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use both features for what each is designed to do: a row access policy for reusable, centralized row-level security, and a secure view when stronger protection of the exposed object definition is required. In Snowflake, row access policies are intended to determine which rows are visible in query results based on context, such as the current role or mapping-table logic. Because the policy is attached to the table or view, it helps avoid repeating the same WHERE-clause logic in every consumer-facing view. Secure views, by contrast, are primarily about securely exposing data while providing stronger protection around the view definition and execution details than standard views, which is especially relevant for external consumers and data sharing scenarios. Best practice is to use policies for governance controls and secure views for controlled data exposure when metadata protection is needed. See Snowflake documentation on row access policies, secure views, and the distinction between row-level security and column-level masking.
- A. Correct.
Correct. Row access policies are designed for row-level security and can be applied to a table so that filtering is enforced regardless of which query or view accesses the protected object. This helps centralize reusable row-filtering logic across multiple consuming objects. Secure views are a separate feature used when stronger data-sharing and metadata-protection behavior is needed; they limit exposure of underlying implementation details compared to standard views. Combining a row access policy on the base table with a secure view for the auditor satisfies both the row-level filtering and metadata-protection requirements.
- B. Incorrect.
Incorrect. A standard view can implement row filtering logic, but it does not provide the stronger metadata and optimization protections associated with secure views. Also, using a standard view to embed filtering logic can lead to duplicated logic if multiple views or consuming objects require the same rule set. The reference to CURRENT_ROLE() as a direct REGION filter is also simplistic and may not reflect a maintainable entitlement model.
- C. Incorrect.
Incorrect. A secure view can encapsulate filtering logic, but secure views are view objects, not centrally attachable policy objects that can be reused across multiple base tables in the same way as row access policies. If the goal is to minimize duplicated row-level security logic across multiple consuming objects, a row access policy is the better fit. Secure views address secure data exposure, not reusable row-level governance by themselves.
- D. Incorrect.
Incorrect. Masking policies protect column values, not row visibility. They can redact or transform data in specific columns but do not remove rows from a result set. In addition, standard views do not provide the same metadata-protection characteristics as secure views. This option combines two common misconceptions: confusing masking with row-level security and equating standard views with secure views.