ARA-C01 Question 76
Single answerPersonal Identifiable Information (PII)/ Personal Health Information (PHI)A healthcare analytics company stores claims data in Snowflake, including member names, addresses, dates of birth, diagnosis codes, and free-text care notes. Data scientists need broad access to analyze trends, but only a small compliance team should be able to view direct identifiers and unstructured notes that may contain PHI. The company also wants to minimize the risk of sensitive values appearing in query results for most users without creating separate copies of the data. Which approach best meets these requirements?
- A
Create a secure view that excludes the sensitive columns, and require all users to query only the view instead of the base table.
- B
Apply masking policies to direct identifier columns and use a projection policy to prevent most roles from selecting the free-text notes column, while granting an authorized role access to the unmasked data.
- C
Encrypt the database with Tri-Secret Secure so that only the compliance team can query PHI columns.
- D
Use row access policies to hide rows containing PHI from non-compliance users, while allowing all columns to remain visible.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use Snowflake’s fine-grained, policy-based governance capabilities for sensitive data. Dynamic data masking is the standard control for PII/PHI columns when the same underlying table must serve different user groups with different entitlements. For especially sensitive columns that should not even appear in most query projections, a projection policy is a strong fit because it controls whether a column can be selected. This design avoids creating duplicate datasets and aligns with least-privilege principles. Secure views can help but are not as robust as attaching governance directly to the sensitive columns, especially in larger environments where base-table access may evolve over time. Row access policies are intended for row-level entitlements, not column-level PHI control. Encryption features such as customer-managed keys or Tri-Secret Secure address key custody and data protection objectives, but they do not replace role-based masking and projection controls for query-time data minimization. These recommendations align with Snowflake best practices for sensitive data protection using dynamic data masking, projection policies, and role-based access control.
- A. Incorrect.
This is only a partial solution. A secure view can hide selected columns, but it relies on all consumers using that view and does not protect the base table itself if privileges are granted elsewhere. It also does not provide dynamic role-based masking of the same columns for different users. In this scenario, the company wants broad access to the same dataset while minimizing exposure of PHI without duplicating data, which is better handled with policy-based controls at the column level.
- B. Correct.
This is correct. Masking policies are designed to dynamically redact sensitive column values such as names, addresses, and dates of birth based on the querying role or context. Projection policies can restrict whether specific columns can be projected in query results, which is appropriate for especially sensitive unstructured notes that may contain PHI. This combination lets data scientists use the same table for analytics while limiting exposure of sensitive values and allowing a small authorized role to access full data when needed.
- C. Incorrect.
This is incorrect. Tri-Secret Secure strengthens key management and encryption control, but it does not provide fine-grained authorization to make PHI columns visible only to one team. Encryption protects data at rest and in certain operational contexts, not the selective display of column values in query results to different Snowflake roles.
- D. Incorrect.
This is incorrect. Row access policies govern which rows are visible based on conditions, not which columns are visible or masked. In this case, the problem is that all users may need the same claim records for aggregate analytics, but only some users should see direct identifiers and free-text notes. Hiding rows would remove needed analytical data and would not solve the column-level PHI exposure issue.