ARA-C01 Question 69
Single answerComplianceA multinational healthcare company uses Snowflake to store protected health information (PHI) and personal data for customers in the US and EU. The security team must ensure that support engineers and data analysts can troubleshoot data quality issues without seeing raw sensitive values, while a small compliance team retains access to original values for approved investigations. The company also wants the protection to remain in effect even if analysts query through BI tools or share secure views internally. Which design best meets these compliance requirements with the LEAST operational overhead?
- A
Create dynamic data masking policies on sensitive columns and use role-based conditions so only the compliance role can view unmasked values.
- B
Encrypt the sensitive columns in application code before loading them into Snowflake and give analysts the decryption keys only when needed.
- C
Create separate masked copies of the tables for analysts using scheduled ETL jobs, and keep the original tables in a restricted schema for the compliance team.
- D
Use row access policies to hide the sensitive columns from analysts and grant the compliance team direct access to the base tables.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use dynamic data masking policies on the sensitive columns. In Snowflake, masking policies provide column-level protection that is enforced at query time and can be made conditional based on the current role or other session context. This aligns well with compliance requirements such as limiting exposure of PHI or personal data while allowing approved personnel to access original values. Because the policy is attached to the column, protection remains consistent for users querying through worksheets, drivers, BI tools, and objects such as views. Compared with creating duplicate masked tables, policy-based masking significantly reduces operational overhead and governance drift. Row access policies are complementary for row-level restrictions but do not solve column masking requirements. Relevant Snowflake best practices and documentation include Dynamic Data Masking, Access Control and role-based design, and Data Governance features for protecting sensitive data.
- A. Correct.
Correct. Dynamic data masking is designed to protect sensitive column values at query time based on the active role or other context. This approach centralizes enforcement in Snowflake, applies consistently across SQL clients and BI tools, and reduces operational overhead because you do not need to maintain duplicate datasets. It is well suited for compliance scenarios involving PHI or personal data where a limited set of roles must see cleartext while most users should see masked values.
- B. Incorrect.
Incorrect. Client-side or application-layer encryption can protect data, but giving analysts decryption keys when needed undermines the requirement that they troubleshoot without seeing raw sensitive values. It also increases operational complexity around key distribution, application changes, and selective access control. This is not the least-overhead approach for role-based selective visibility within Snowflake.
- C. Incorrect.
Incorrect. Maintaining separate masked copies through ETL is a common but suboptimal pattern. It creates data duplication, increases storage and pipeline maintenance, and introduces risk of stale or inconsistent masking if jobs fail or schemas change. Snowflake governance features are intended to avoid this kind of operational burden.
- D. Incorrect.
Incorrect. Row access policies control which rows are visible, not how individual column values are displayed. They are useful for restricting access by row, such as region or business unit, but they do not mask sensitive columns. This option reflects a common misconception between row-level and column-level governance controls.