SnowPro Advanced: Security Engineer Question 138
Single answerApply advanced privacy controls for shared data:A data provider shares a secure view of patient claims data with multiple consumer accounts through a Snowflake data share. The provider must ensure that each consumer only sees rows for its own business unit, while direct identifiers such as member names are irreversibly hidden. The provider also wants to avoid creating and maintaining separate physical tables for each consumer. Which approach best meets these requirements?
- A
Create a secure view over the base table that masks direct identifier columns with a masking policy, and filter rows in the view using CURRENT_ACCOUNT() so each consumer account only sees its own business unit.
- B
Create a standard view over the base table, apply a row access policy to the shared base table, and rely on the consumer's role hierarchy to enforce which rows are visible after the share is created.
- C
Share the base table directly and ask each consumer to create its own masking policies and row filters in its account to protect sensitive columns and business-unit data.
- D
Create separate secure shares for each consumer, but include the full unfiltered patient table in each share and depend on object tagging to hide direct identifiers automatically.
Show answer and explanation
Correct answer: A
Explanation
The best practice for advanced privacy controls in Snowflake data sharing is to enforce protections in the provider account before data is exposed. For row-level segmentation across multiple consumers, providers commonly publish a secure view that filters rows based on the consumer account, often using CURRENT_ACCOUNT() with a provider-managed entitlement mapping. For sensitive columns, dynamic data masking via masking policies protects direct identifiers without duplicating underlying data. This pattern is well aligned with Snowflake guidance for secure data sharing: use secure views to share filtered results and preserve definition confidentiality, and use masking policies where sensitive columns must be protected. By contrast, sharing raw tables and expecting consumers to self-restrict is not a valid privacy control because the provider has already disclosed the underlying data.
- A. Correct.
Correct. For shared data, Snowflake supports using secure views to expose only approved logic to consumers. A secure view can filter rows dynamically based on the consumer account, commonly using CURRENT_ACCOUNT() in the view definition or a mapping table maintained by the provider. To hide direct identifiers, the provider can apply a masking policy to the relevant columns so the shared object exposes masked values rather than raw PII. This satisfies the requirement to avoid duplicating physical data while enforcing provider-controlled privacy protections.
- B. Incorrect.
Incorrect. Standard views are not appropriate for data sharing scenarios where query details and underlying logic must be protected; secure views are the correct construct for sharing filtered datasets. Also, consumer role hierarchy does not control which provider rows are exposed through a share. Access decisions for shared data must be enforced by the provider's shared object definitions and supported policies, not by roles inside the consumer account.
- C. Incorrect.
Incorrect. A consumer cannot be relied on to implement the provider's privacy obligations after receiving broad access to the shared table. If the provider shares the full base table directly, the sensitive data has already been exposed to the consumer account. Privacy controls for shared data should be enforced by the provider before or as part of the shared object, such as with secure views and masking policies.
- D. Incorrect.
Incorrect. Separate shares per consumer may be used in some designs, but including the full unfiltered patient table in each share does not meet the row-isolation requirement. In addition, object tags do not by themselves automatically hide or redact data in shares. Tags are metadata and can be used with governance features, but they do not replace masking policies or secure-view filtering.