ARA-C01 Question 61
Single answerAggregate policiesA healthcare company stores patient encounter data in a Snowflake table named ENCOUNTERS, including sensitive columns such as PATIENT_ID and DIAGNOSIS_CODE. Analysts should be able to query only aggregated results from this dataset, and any query that could expose information about too few underlying rows must be blocked. The architecture team wants this protection enforced centrally in Snowflake so that BI tools and ad hoc SQL users are subject to the same rule without rewriting every report. Which approach best meets this requirement?
- A
Create an aggregate policy that enforces a minimum group size, then assign the policy to the ENCOUNTERS table so Snowflake evaluates aggregate queries against the protected data
- B
Create a masking policy on PATIENT_ID and DIAGNOSIS_CODE so only hashed values are returned; this prevents small-group disclosure in aggregate reports
- C
Create a row access policy that filters rows unless the query contains a GROUP BY clause with at least a specified number of rows
- D
Publish a secure view with COUNT(*) and SUM() columns only, and rely on BI developers to avoid dimensions that would create very small groups
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use an aggregate policy. Aggregate policies are intended for privacy-preserving analytics use cases where consumers should only see aggregated results and where Snowflake should enforce controls such as minimum group size to reduce the risk of re-identification or small-cohort disclosure. This is stronger than relying on BI conventions or custom SQL because the rule is applied centrally to the protected data object and evaluated by Snowflake regardless of the consuming tool.
The distractors reflect common misunderstandings: masking policies protect direct column exposure, not inference from aggregates; row access policies control row visibility, not aggregate result safety; and secure views can narrow exposure but do not inherently provide aggregate privacy guarantees or threshold enforcement. In Snowflake best practices, use the policy type that matches the control objective: masking for column value protection, row access for row-level entitlements, and aggregate policies for privacy controls over aggregate query results.
- A. Correct.
Correct. Aggregate policies are designed to govern queries over protected datasets so users can access only aggregate results and so queries that do not meet privacy thresholds, such as a minimum aggregation group size, can be rejected. Applying the policy centrally at the data object level is the best fit when the requirement is to consistently enforce protection across BI tools, worksheets, and ad hoc SQL without depending on each query author to implement the rule.
- B. Incorrect.
Incorrect. Masking policies protect values at the column level by transforming or hiding returned data, but they do not solve the inference problem of small-group aggregation. Even if PATIENT_ID or DIAGNOSIS_CODE are masked, a query that returns counts for a cohort of one or two patients could still reveal sensitive information through aggregation results.
- C. Incorrect.
Incorrect. Row access policies determine which rows are visible based on role, context, or predicate logic. They are not intended to inspect SQL structure for aggregate semantics or enforce minimum group sizes for aggregate outputs. Someone might choose this because row filtering sounds related to privacy, but it does not address aggregate disclosure control in the way aggregate policies do.
- D. Incorrect.
Incorrect. A secure view can help limit direct table access, but by itself it does not centrally enforce minimum group-size privacy rules. It also relies on report authors to model safe dimensions and can still permit unsafe combinations unless every query path is carefully constrained. The requirement explicitly calls for Snowflake-native centralized enforcement rather than process-based controls.