SnowPro Advanced: Security Engineer Question 139
Single answerApply advanced privacy controls for shared data:A healthcare analytics company shares a Snowflake database with several external research partners. The shared table contains patient-level records, including quasi-identifiers and a sensitive DIAGNOSIS_CODE column. The provider must let each partner query the shared data, but only approved analysts at the consumer accounts should be able to see unmasked diagnosis values. All other shared-data users must see masked values, and the provider wants to manage this centrally without copying data into each consumer account. Which approach best meets these requirements?
- A
Create a secure view on the provider side and use CURRENT_ROLE() in the view definition to show or hide DIAGNOSIS_CODE based on the consumer's role name.
- B
Apply a masking policy to DIAGNOSIS_CODE on the provider side and use INVOKER_SHARE plus IS_ROLE_IN_SESSION() checks so approved consumer-side roles can see unmasked values while other shared-data users receive masked values.
- C
Replicate the database into each consumer account and use local row access policies and masking policies in each consumer account to control DIAGNOSIS_CODE visibility.
- D
Use a network policy on the provider account to allow only approved consumer IP addresses to query the shared table without masking.
- E
Encrypt DIAGNOSIS_CODE with a customer-managed key before sharing, and give the key only to approved analysts in the consumer accounts.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use a provider-managed masking policy on the shared column and write the policy to handle shared-access context appropriately. For advanced privacy controls on shared data, Snowflake allows providers to centrally enforce masking on data exposed through shares, secure views, and related shared objects. In these scenarios, policy logic can use share-aware constructs such as INVOKER_SHARE and supported context functions like IS_ROLE_IN_SESSION() to determine whether a consumer-side role should receive unmasked data. This is the key capability that satisfies all requirements: centralized management, no data duplication, and selective unmasking for approved analysts in consumer accounts. By contrast, secure views alone are not sufficient if they depend on the wrong session context; replication violates the no-copy requirement; network policies address connectivity rather than data privacy; and external encryption/key distribution bypasses Snowflake's native governance model. Refer to Snowflake documentation on Dynamic Data Masking, data sharing considerations for masking policies, and context functions supported in policy expressions for shared data.
- A. Incorrect.
Incorrect. Secure views are commonly used for data sharing, but using CURRENT_ROLE() to evaluate consumer roles is not the right mechanism for centrally enforcing consumer-specific masking logic in a share. In a data-sharing context, provider-side role context is not the same as consumer account role context. Snowflake supports privacy controls for shared data through policies designed to evaluate conditions in shared scenarios, including use of INVOKER_SHARE and supported role-checking functions. Relying on CURRENT_ROLE() in a secure view is a common misconception because it seems like a simple role-based filter, but it does not correctly solve cross-account shared-data role evaluation.
- B. Correct.
Correct. Snowflake supports applying masking policies to shared data on the provider side so the provider can centrally govern privacy controls without copying data. For data sharing scenarios, INVOKER_SHARE can be used in policy logic to distinguish share access, and Snowflake supports evaluating whether a consumer role is active in session with functions such as IS_ROLE_IN_SESSION() in supported policy contexts. This lets the provider define a masking policy on DIAGNOSIS_CODE that returns cleartext only for approved consumer roles and masked values otherwise. This approach aligns with Snowflake best practices for advanced privacy controls over shared data.
- C. Incorrect.
Incorrect. Replicating the database into each consumer account would undermine the requirement to manage controls centrally and avoid copying data. It also increases operational complexity and weakens the governance model because each consumer account would manage its own controls. While local policies can work technically after data is copied, that is not the best solution for secure centralized governance of shared data.
- D. Incorrect.
Incorrect. Network policies restrict access based on network locations, not on whether a user should see masked or unmasked column values. Even if approved analysts connected from known IP addresses, network policies do not provide column-level privacy controls for shared data. This option confuses perimeter access controls with data-centric access controls.
- E. Incorrect.
Incorrect. Encrypting data before sharing and distributing keys to individual analysts is not how Snowflake shared-data privacy controls are normally implemented. Snowflake provides native masking policies and secure data-sharing features specifically so providers can enforce privacy controls centrally without forcing consumers to manage decryption keys. This option also creates substantial key-distribution and usability challenges and does not align with standard Snowflake governance patterns for shared data.