ADA-C01 Question 176
Single answerCompare row access policies to secure viewsA financial services company stores all regional customer records in a single table named PROD.SALES.CUSTOMERS. Analysts in each region should see only rows for their own region, while external auditors should be allowed to query a curated subset of columns without exposing the underlying query logic. The Snowflake administrator wants a design that minimizes duplication of row-filtering logic across many BI tools and ad hoc queries, while also protecting the definition of the exposed object from being visible to consumers. Which approach best meets these requirements?
- A
Create a row access policy on PROD.SALES.CUSTOMERS to enforce region-based row filtering, and expose auditor access through a secure view that selects only the approved columns.
- B
Create a standard view for auditors and rely on BI tool filters for regional analysts, because row access policies apply only to views and not to base tables.
- C
Create separate secure views for each region and for auditors, because secure views are the only Snowflake feature that can hide filtering logic from query users and enforce row-level restrictions everywhere.
- D
Create a masking policy on the REGION column in PROD.SALES.CUSTOMERS and grant auditors access directly to the table, because masking policies can replace row access policies for row-level security.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to combine a row access policy with a secure view. In Snowflake, row access policies are intended for row-level security and can be attached to tables or views, allowing administrators to centralize filtering logic so that all queries against the protected object consistently enforce access rules. This is typically preferable to creating many separate views with embedded WHERE clauses, especially in environments with multiple tools and ad hoc SQL usage. Secure views serve a different purpose: they are useful when administrators need to expose a curated interface while limiting visibility into the view definition and underlying objects compared with standard views. They do not replace row access policies for centralized row-level enforcement. Snowflake documentation and best practices distinguish these features clearly: use row access policies for row filtering, masking policies for column-value protection, and secure views when you need stronger control over exposed metadata and query logic.
- A. Correct.
Correct. A row access policy is the native Snowflake feature for centrally enforcing row-level filtering on a table or view, so it is the best fit for ensuring regional analysts only see rows they are entitled to access across many tools and query patterns. A secure view is appropriate for the auditor use case because it can expose only approved columns and prevents consumers from seeing underlying view definition details in the same way a standard view can expose metadata. This combination addresses both requirements: centralized row-level enforcement and protected presentation logic.
- B. Incorrect.
Incorrect. This reflects two misconceptions. First, row access policies can be applied to tables as well as views; they are not limited to views. Second, relying on BI tool filters is not a secure or centralized enforcement mechanism because users or tools may bypass or alter those filters. Standard views also do not provide the metadata protection of secure views.
- C. Incorrect.
Incorrect. Separate secure views per region could work functionally, but this approach duplicates row-filtering logic and becomes difficult to maintain at scale. Secure views are not the only feature for row-level restrictions; row access policies are specifically designed for centralized row-level security. Using many region-specific views is typically less maintainable than attaching a single policy to the base table.
- D. Incorrect.
Incorrect. Masking policies protect column values, not row visibility. Masking a REGION column would not prevent users from accessing rows they should not see. Granting auditors direct table access would also fail the requirement to expose only a curated subset of columns and to shield the exposed object definition appropriately.