SnowPro Advanced: Security Engineer Question 134
Select 3Utilize aggregation policies, differential privacy policies, and budgetsA healthcare analytics team in Snowflake must let external researchers run aggregate studies on patient claims data without exposing individual patients. The security engineer has already de-identified direct identifiers, but leadership now requires technical controls so that: (1) researchers can only query approved aggregate results, (2) repeated querying cannot gradually reveal sensitive information, and (3) privacy loss can be monitored and limited over time. Which combination of actions should the security engineer implement?
- A
Apply an aggregation policy to the protected table or view so queries must satisfy aggregation requirements before returning results.
- B
Apply a differential privacy policy to the dataset and configure privacy budgets so privacy loss is consumed and tracked across queries.
- C
Create a masking policy on all quasi-identifier columns and rely on the masking policy alone to prevent reconstruction through repeated aggregate queries.
- D
Use a row access policy to restrict each researcher to a subset of rows; this by itself satisfies the requirement to allow only approved aggregate studies and limit cumulative privacy leakage.
- E
Define and manage differential privacy budgets for researchers or workloads so repeated differentially private queries are governed by an allowed privacy-loss limit.
Show answer and explanation
Correct answers: A, B, E
Explanation
The best solution combines aggregation policies with differential privacy policies and privacy-budget management. Aggregation policies help ensure only aggregate results are returned under approved conditions. Differential privacy policies help protect against inference from repeated aggregate queries by injecting statistically calibrated noise. Budgets are essential because differential privacy relies on a finite privacy-loss allowance that must be tracked and constrained over time. Masking policies and row access policies are useful security features in Snowflake, but they solve different problems: masking obfuscates values in result sets, and row access policies filter row visibility. Neither one alone provides the aggregate-only enforcement plus cumulative privacy-loss controls required here. This aligns with Snowflake best practices for protecting sensitive analytical workloads using aggregation policies, differential privacy policies, and privacy budgets together.
- A. Correct.
Correct. Aggregation policies are designed to protect sensitive data by enforcing that queries return aggregated results only when policy conditions are met. In this scenario, they address the requirement that researchers can only access approved aggregate outputs instead of row-level detail.
- B. Correct.
Correct. Differential privacy policies add calibrated noise to aggregate query results and are intended to reduce the risk that repeated queries can be used to infer information about specific individuals. This directly addresses the requirement to mitigate disclosure through query differencing or repeated analysis. Configuring privacy budgets is also necessary because differential privacy is based on a measurable privacy-loss model.
- C. Incorrect.
Incorrect. Masking policies protect column values in query results, but they do not by themselves provide differential privacy guarantees or control cumulative privacy leakage from repeated aggregate queries. A candidate might choose this because quasi-identifiers are often masked in privacy programs, but masking alone does not satisfy the stated requirements.
- D. Incorrect.
Incorrect. Row access policies filter which rows a user can see, but they do not inherently enforce aggregate-only access, add differential privacy protections, or track privacy loss over time. This is a common misconception because row-level restriction sounds like stronger control, but the scenario specifically requires aggregate controls and privacy-budget management.
- E. Correct.
Correct. Differential privacy budgets are a key operational control for limiting and tracking cumulative privacy loss. Without budget management, even properly configured differentially private queries could exceed the organization's acceptable privacy-loss threshold over time. This option complements the differential privacy policy requirement.