COF-C03 Question 184
Single answerPrivacy policiesA healthcare company stores patient contact information in a Snowflake table. Analysts in the SUPPORT role should see full phone numbers only for patients who have explicitly consented to phone outreach. All other roles should see masked values, and the policy should be enforced directly in Snowflake rather than in BI tools. Which solution best meets this requirement?
- A
Create a masking policy on the phone number column that uses conditional logic based on the current role and a consent indicator column.
- B
Create a row access policy on the table so that non-consenting patients are hidden from all roles except SUPPORT.
- C
Use a tag-based masking policy on the table and grant SUPPORT the APPLY privilege so the role can unmask data when needed.
- D
Create a projection policy on the table to return full phone numbers only when the SUPPORT role queries the data.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use a masking policy. In Snowflake, privacy-related policy controls include masking policies for column-level protection and row access policies for row-level filtering. This scenario requires preserving row visibility while conditionally revealing or masking a sensitive column based on both user context and data values. That is exactly the use case for dynamic data masking. A masking policy can evaluate expressions such as the active role and a consent column to determine whether to expose the original phone number or a masked value. Row access policies would be appropriate only if the requirement were to hide entire rows. As a best practice, implement sensitive-data enforcement in Snowflake itself so it applies consistently across worksheets, applications, and downstream tools. Refer to Snowflake documentation on Dynamic Data Masking and Row Access Policies for the distinction between column protection and row filtering.
- A. Correct.
Correct. A masking policy is the Snowflake feature designed to protect sensitive column values while still allowing rows to remain visible. Dynamic data masking can use conditional SQL logic, including context such as CURRENT_ROLE() and other columns in the same row, such as a consent flag, to determine whether to return the original value or a masked representation. This directly satisfies the requirement to show full phone numbers only to the SUPPORT role and only when consent exists, while masking values for everyone else.
- B. Incorrect.
Incorrect. A row access policy controls which rows are visible, not how individual column values are masked. In this scenario, the company wants analysts to continue seeing the records but with masked phone numbers unless both role and consent conditions are met. Hiding entire patient rows would change query results and does not address the need for conditional display of a single sensitive field.
- C. Incorrect.
Incorrect. Tag-based masking can help centrally apply masking policies to columns associated with a tag, but the option is flawed in two ways. First, the requirement is specifically about enforcing logic for one phone number column based on role and consent, which can be solved directly with a masking policy without needing tags. Second, granting APPLY does not let a runtime querying role selectively unmask protected data; APPLY is an administrative privilege related to setting policies, not a mechanism for end users to bypass masking during query execution.
- D. Incorrect.
Incorrect. Projection policies are not the Snowflake feature used for masking sensitive data based on roles and row-level conditions. For SnowPro Core, the correct privacy-control feature for conditional obfuscation of a column value is a masking policy. This option is plausible because it refers to controlling returned data, but it does not match the intended Snowflake privacy policy capability tested here.