ARA-C01 Question 63
Single answerProjection policiesA healthcare analytics company stores a PATIENT table in Snowflake with columns including PATIENT_ID, FULL_NAME, DATE_OF_BIRTH, EMAIL, and SSN. Analysts in different business units need access to the table, but the security team wants to prevent users from projecting highly sensitive columns such as SSN in ad hoc queries unless they are in an approved compliance role. The team also wants to avoid creating multiple secured views for every consumer group. Which solution best meets this requirement?
- A
Apply a projection policy to the SSN column that evaluates the current role context and blocks unauthorized queries when SSN is included in the SELECT list.
- B
Apply a masking policy to the SSN column, because masking policies prevent a column from being selected by unauthorized users.
- C
Create a row access policy on the PATIENT table, because row access policies can stop unauthorized users from projecting specific columns.
- D
Use object tags on the SSN column and rely on tag-based classification alone to prevent users from selecting the column.
Show answer and explanation
Correct answer: A
Explanation
The key requirement is to prevent a sensitive column from appearing in query results for unauthorized users without managing many separate views. Projection policies address this exact use case by controlling whether a column may be projected in the result set. This differs from masking policies, which return transformed or obfuscated values while still allowing the column to be selected, and from row access policies, which govern row visibility rather than column projection. In Snowflake best practices, architects should choose the control that matches the security objective: masking for redaction, row access for row filtering, and projection policies for restricting whether a column can be selected at all. Snowflake documentation on projection policies and policy-based governance describes this separation of responsibilities.
- A. Correct.
Correct. Projection policies are designed to govern whether a column can be projected in query results. In this scenario, the requirement is specifically to stop unauthorized users from including SSN in the SELECT list while still allowing broad access to the table. A projection policy can evaluate role context and enforce whether the protected column is allowed to appear in query output, which avoids proliferating secured views for different audiences.
- B. Incorrect.
Incorrect. Masking policies control how data values are transformed or redacted at query time, but they do not prevent a column from being referenced or projected. An unauthorized user could still select the SSN column and receive a masked value. That does not satisfy the requirement to block projection of the column altogether.
- C. Incorrect.
Incorrect. Row access policies filter which rows are visible based on conditions, user context, or role context. They do not provide column-level projection control. Someone might choose this option because row access policies are also dynamic security controls, but they address row visibility, not whether a specific column can appear in the query result.
- D. Incorrect.
Incorrect. Tags and data classification metadata are useful for governance, discovery, and for driving automation, but tags alone do not enforce query-time prevention of selecting a column. They can support policy administration patterns, but a tag by itself does not stop projection of SSN.