COF-C03 Question 185
Single answerPrivacy policiesA healthcare analytics company stores patient contact information in a Snowflake table. Analysts in the SUPPORT role need to view full phone numbers to contact patients, but analysts in the ANALYST role should only see masked values unless they have a documented business need approved later. The security team wants the protection to be enforced centrally at query time and to follow the data even if additional views are created on top of the table. Which Snowflake approach best meets these requirements?
- A
Create a privacy policy that masks the phone number column based on the current role, and attach the policy to the column
- B
Encrypt the phone number column with a customer-managed key and grant the ANALYST role USAGE on the key only when access is approved
- C
Create a row access policy on the table so unauthorized roles cannot see the phone number values in restricted rows
- D
Create a secure view that shows masked phone numbers for ANALYST and full phone numbers for SUPPORT, and require all users to query only that view
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use a privacy policy attached to the sensitive column. In Snowflake, privacy-related policy controls are designed to protect sensitive data at query time based on context such as role. This is preferable to relying only on views because the policy is bound directly to the column and continues to apply when the column is referenced through other objects. Row access policies solve a different problem: filtering rows rather than masking column values. For SnowPro Core, candidates should distinguish clearly between column-level protection for sensitive attributes and row-level filtering for dataset segmentation. Snowflake documentation on data governance and policy-based protection describes applying policies directly to columns so access rules are enforced consistently across queries and derived views.
- A. Correct.
Correct. A Snowflake privacy policy can be applied to a column to protect sensitive data centrally at query time. Policies can evaluate context such as the current role and return masked or unmasked values accordingly. Because the policy is attached to the data column, the protection remains in effect even when the data is queried through views, which matches the requirement for centralized enforcement that follows the data.
- B. Incorrect.
Incorrect. Snowflake supports encryption of data at rest, but that does not provide role-based dynamic masking behavior for query results in the way described here. Granting access to an encryption key is not how Snowflake implements conditional display of sensitive column values to different roles in normal SQL query processing.
- C. Incorrect.
Incorrect. A row access policy controls which rows are visible to a user, not how specific column values are masked within visible rows. In this scenario, both roles may need to access the same rows, but one role should see masked phone numbers. That is a column-level privacy requirement, not a row-filtering requirement.
- D. Incorrect.
Incorrect. A secure view can help limit exposure and protect underlying logic, but it does not satisfy the requirement as well as a column-attached policy. It depends on users consistently querying the view, whereas the requirement calls for protection enforced centrally and following the data even if additional views are created later. A privacy policy attached to the column is the stronger and more direct control.