ARA-C01 Question 41
Single answerData AccessA healthcare company stores patient encounter data in a shared Snowflake table used by multiple analytics teams. The Security team must ensure that analysts can query only rows for the hospitals assigned to their region, while certain sensitive columns such as PATIENT_SSN and DIAGNOSIS_NOTES must be hidden from most users. The company also wants the controls to continue working if analysts query through secure views rather than directly from the base table. Which approach best meets these requirements with the least ongoing administrative effort?
- A
Create separate copies of the table for each region and grant SELECT only on the appropriate copy to each analyst role.
- B
Implement a row access policy on the table for regional filtering and masking policies on sensitive columns, using role- or mapping-table-based logic as needed.
- C
Grant access only through secure views and embed both row filtering and column redaction logic in each view definition.
- D
Use object tags on the sensitive columns and rely on tag values alone to prevent unauthorized users from seeing those columns.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use Snowflake's policy-based data access features directly on the underlying objects: a row access policy for row-level security and masking policies for column-level protection. This design is preferable because it centralizes enforcement, scales better than maintaining many views or table copies, and remains effective when users access data through views. In Snowflake, row access policies evaluate a Boolean expression to determine which rows are visible to the querying context, and masking policies control what value is returned for protected columns based on role, entitlement logic, or other conditions. Secure views are useful for controlled sharing and abstraction, but they are not the lowest-maintenance primary mechanism for broad row- and column-level governance when native policies are available. Tags support governance and classification but do not independently enforce data access. This aligns with Snowflake best practices for fine-grained access control using row access policies and dynamic data masking.
- A. Incorrect.
This is incorrect because creating separate physical copies by region increases storage and operational overhead, introduces data synchronization risk, and does not address column-level protection elegantly. It can work technically, but it is not the least administrative effort and is not the preferred Snowflake design for centralized, policy-based data access control.
- B. Correct.
This is correct. Row access policies are designed to filter rows dynamically at query time based on context such as CURRENT_ROLE or a mapping table. Masking policies are designed to protect sensitive columns by returning masked values to unauthorized users. Applying these policies at the table/column level centralizes enforcement so the controls continue to apply even when users query through views, including secure views, because the underlying policies are still evaluated. This is the most maintainable approach for scalable, fine-grained access control in Snowflake.
- C. Incorrect.
This is incorrect because secure views can restrict exposed data, but embedding all access logic in view definitions creates duplicated logic and higher maintenance when many views or consuming teams exist. Also, if someone is later granted access to the base table, the protections in the view are bypassed. Policy-based controls on the underlying table and columns are the stronger, centralized design.
- D. Incorrect.
This is incorrect because tags by themselves do not enforce access restrictions. In Snowflake, tags are metadata that can be used for governance, classification, and in some cases as inputs to policy automation, but a tag alone does not mask or deny access to data. Enforcement requires an actual masking policy, row access policy, or other supported governance control.