ARA-C01 Question 45
Single answerData SecurityA healthcare company stores PHI in Snowflake and shares a subset of records with several external research partners using Secure Data Sharing. The security team requires that partner users see only de-identified data by default, while a small internal compliance group must retain access to the original values. The company also wants to minimize data duplication and avoid maintaining separate partner-specific copies of the tables. Which solution best meets these requirements?
- A
Create separate physical tables for each partner with masked values precomputed during ETL, and grant partners SELECT on only their table copies.
- B
Apply a masking policy to sensitive columns and use role-based conditional logic in the policy so internal compliance roles can see original values while partner-facing roles see masked values, then share a secure view built on the base table.
- C
Encrypt the PHI columns with Tri-Secret Secure and share the base table directly; external partners will be unable to decrypt the sensitive columns unless explicitly granted key access.
- D
Use row access policies to replace sensitive column values with hashed strings for external partners while allowing internal users to see the original column values.
Show answer and explanation
Correct answer: B
Explanation
The key requirement is differentiated visibility of sensitive column values without duplicating datasets. In Snowflake, dynamic data masking is the appropriate control for column-level protection. A masking policy can evaluate context such as CURRENT_ROLE and return original values for authorized internal roles while returning masked, nullified, or tokenized values for all others. For external sharing, exposing data through a secure view is a strong architectural choice because it lets the provider define exactly what consumers can access and apply additional projection or filtering logic as needed.
This design aligns with Snowflake security best practices: use masking policies for column-level obfuscation, row access policies for row filtering, and secure views for controlled data sharing and protection of underlying logic. Encryption features such as Snowflake-managed encryption or Tri-Secret Secure protect data at rest and support key-management requirements, but they do not replace fine-grained query-time access controls. Relevant Snowflake documentation includes topics on Dynamic Data Masking, Row Access Policies, Secure Views, and Secure Data Sharing.
- A. Incorrect.
This approach can work functionally, but it does not meet the requirement to minimize data duplication and operational overhead. Creating separate physical copies per partner increases storage, ETL complexity, and governance burden. Snowflake data security best practices generally favor policy-based controls such as dynamic data masking and secure views over duplicating protected datasets when the goal is differentiated access to the same underlying data.
- B. Correct.
This is the best answer. Dynamic data masking is designed to protect sensitive column values based on the querying role or other context, allowing authorized internal roles to see cleartext while other roles see masked or tokenized values. Combining the masking policy with a secure view is a common pattern for data sharing because secure views let the provider expose only the intended columns/rows/logic while preventing certain forms of query optimization that could expose underlying details. This satisfies the requirement for de-identified access by default, preserves access for the compliance team, and avoids maintaining separate partner-specific table copies.
- C. Incorrect.
This is incorrect because Tri-Secret Secure is related to key management and control of encryption keys for Snowflake account data protection at rest; it is not a mechanism for role-based presentation of cleartext versus masked values to different users in query results. Secure Data Sharing does not rely on partners having direct key access to selectively decrypt specific shared columns. This option confuses encryption at rest with fine-grained access control and data masking.
- D. Incorrect.
This is incorrect because row access policies govern which rows are visible to a role, not how specific column values are transformed or masked. They are appropriate for filtering records, such as restricting a partner to patients in a particular region, but not for replacing PHI values in a column while returning the same rows. The misconception is treating row-level security as a substitute for column-level masking.