ARA-C01 Question 75
Single answerPersonal Identifiable Information (PII)/ Personal Health Information (PHI)A healthcare analytics company stores claim records in Snowflake, including member names, addresses, dates of birth, diagnosis codes, and treatment details. Data engineers, actuaries, and customer support analysts all query the same core table. The company must reduce exposure of PII/PHI while still allowing different roles to query the data they legitimately need. Which Snowflake design provides the MOST appropriate protection with the LEAST operational overhead?
- A
Create secure views for each consumer group and apply masking policies to sensitive columns plus row access policies where subset restrictions are needed
- B
Encrypt the database with Tri-Secret Secure and allow all users to query the base tables directly because encryption protects PII/PHI at rest and in use
- C
Replicate the claims table into separate databases for each team and permanently remove sensitive columns from the copies that should not contain PHI
- D
Rely on object privileges alone by granting SELECT on the core table only to approved roles, since role-based access control is sufficient for column- and row-level privacy requirements
Show answer and explanation
Correct answer: A
Explanation
For PII/PHI in Snowflake, the recommended architectural pattern is to combine RBAC with fine-grained governance features rather than rely on table-level permissions or data duplication. Dynamic data masking is designed to protect sensitive column values such as name, address, and date of birth based on context such as current role. Row access policies are used when specific users or roles should only see permitted records. Secure views can provide an additional governed interface and help avoid exposing underlying table structure or sensitive logic. Encryption features, including customer-managed key options and Tri-Secret Secure, are important for key control and compliance posture, but they do not replace masking and row-level controls. This question reflects Snowflake best practices for centralized policy enforcement, least privilege, and reduced operational overhead when handling regulated data such as PII and PHI.
- A. Correct.
Correct. This is the most appropriate Snowflake-native design for protecting sensitive data while minimizing duplication and administrative overhead. Dynamic data masking can protect PII/PHI at the column level based on the querying role, and row access policies can restrict which records are visible to certain users or groups. Secure views further help present only the intended subset or transformed representation of the data and are commonly used to encapsulate sensitive logic. This approach aligns with best practices for centralized governance without copying data into multiple physical tables.
- B. Incorrect.
Incorrect. Tri-Secret Secure strengthens key management and encryption control, but it does not replace logical access controls for PII/PHI. Encryption at rest does not decide which columns a given role may see in clear text, nor does it restrict rows by user entitlement. Users querying base tables directly would still see sensitive data if granted access. A common misconception is that encryption alone satisfies privacy and least-privilege requirements.
- C. Incorrect.
Incorrect. Creating separate physical copies for each team can work functionally, but it increases storage, pipeline complexity, synchronization effort, and governance risk. It also makes policy enforcement harder to maintain consistently over time. Snowflake provides policy-based controls such as masking and row access specifically to avoid unnecessary data duplication for this use case.
- D. Incorrect.
Incorrect. RBAC is foundational, but granting or withholding SELECT on a table is too coarse for this scenario. The requirement is to let multiple roles query the same core dataset while seeing different levels of sensitive information. Standard object privileges do not by themselves provide column-level masking or row-level filtering. Candidates often overestimate RBAC and overlook the need for policy-based controls.