SnowPro Advanced: Security Engineer Question 103
Single answerDomain 2.0: Data Protection, Data Privacy, and Data Governance (30%)A healthcare company stores patient records in Snowflake. A SECURITYADMIN needs to let an external research partner query a de-identified view of the data, while ensuring that users from the partner can only see rows for studies assigned to their organization and cannot view direct identifiers such as patient name, email, or SSN. The company wants the controls to be enforced centrally so that analysts do not need to rewrite filters in every query. Which combination of Snowflake features should be implemented to meet these requirements?
- A
Create a secure view for the shared dataset, apply a row access policy to restrict rows by the partner organization, and apply a masking policy to direct identifier columns before exposing the data.
- B
Use object tags on the patient table to mark sensitive columns and rely on tag inheritance to automatically hide identifiers and restrict rows for each partner organization.
- C
Grant the partner role SELECT on the base patient table and require analysts to add WHERE clauses for their organization in each query, while using client-side encryption to protect identifiers.
- D
Create a materialized view that excludes direct identifiers and grant the partner role access to it, because materialized views automatically enforce per-organization row filtering for downstream consumers.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to combine a secure view, a row access policy, and a masking policy. In Snowflake, row access policies are designed for centralized row-level security, allowing access decisions to be evaluated at query time based on execution context. Masking policies are designed for centralized column-level protection of sensitive fields such as PII. Secure views are commonly used when sharing governed subsets of data because they help protect business logic and provide a cleaner abstraction layer over protected objects. Tags are valuable for data classification and can support governance programs, but they are not by themselves an enforcement mechanism for row-level security. Likewise, relying on analysts to manually filter rows is not a strong security design. This aligns with Snowflake best practices for layered data protection and privacy controls in regulated environments.
- A. Correct.
Correct. This combines the right Snowflake governance controls for the scenario. A secure view is appropriate when exposing governed data to external consumers because it helps protect underlying logic and limits certain metadata exposure. A row access policy centrally enforces row-level filtering based on the querying context, such as the partner organization mapped to the current role or user. A masking policy de-identifies or redacts direct identifiers like patient name, email, and SSN. Together, these controls meet the requirement for centralized enforcement without depending on analysts to manually add filters.
- B. Incorrect.
Incorrect. Tags are useful for classification, discovery, and governance workflows, and Snowflake supports tag-based masking in some governance designs. However, tags by themselves do not automatically hide data or enforce row-level restrictions. Tag inheritance does not implement dynamic row filtering. You still need explicit enforcement mechanisms such as masking policies and row access policies.
- C. Incorrect.
Incorrect. Granting access to the base table and relying on analysts to write WHERE clauses does not provide centralized enforcement and is error-prone. It violates the requirement that controls should not depend on users remembering to filter correctly. Client-side encryption also does not solve the need for governed, query-time de-identification and row-level restriction within Snowflake.
- D. Incorrect.
Incorrect. A materialized view can precompute results for performance, but it does not automatically enforce per-organization row-level security. If row-level restrictions are needed, they must be implemented through supported policy mechanisms such as row access policies. Excluding identifier columns from a materialized view helps reduce exposure, but it does not satisfy the requirement to centrally enforce access by organization.