ADA-C01 Question 134
Single answerDomain 2.0: Account Management and Data Governance (18%)A financial services company stores customer PII in a shared analytics database. The security team wants to let analysts query the CUSTOMER table, but they must only see masked values for SSN and EMAIL unless they are in a privileged role. The company also wants the masking logic to follow the columns automatically if the table is cloned or copied into another schema within the same account. Which approach should the Snowflake administrator implement?
- A
Create dynamic data masking policies on the SSN and EMAIL columns and use role-based conditions in the policy body to return unmasked values only to privileged roles.
- B
Create row access policies on the CUSTOMER table to hide the SSN and EMAIL values from non-privileged users while allowing full rows for privileged roles.
- C
Create a secure view over the CUSTOMER table that uses CASE expressions based on CURRENT_ROLE() and require analysts to query only the view.
- D
Encrypt the SSN and EMAIL columns with Tri-Secret Secure so analysts can query the table directly while Snowflake automatically reveals plaintext only to privileged roles.
Show answer and explanation
Correct answer: A
Explanation
The best solution is to use dynamic data masking policies for the sensitive columns. In Snowflake, masking policies are purpose-built for column-level protection and can evaluate session context, including roles, to return different values to different users. This is more appropriate than row access policies, which govern row visibility, or secure views, which can implement similar logic but are less maintainable and do not attach governance directly to the data element. Encryption features such as Tri-Secret Secure protect stored data and keys, but they are not substitutes for runtime authorization and masking. Snowflake documentation on Dynamic Data Masking and Access Control describes using masking policies with role-aware logic and highlights that policy bindings are part of object metadata, which is why they are suitable for governance scenarios involving cloning and internal data movement.
- A. Correct.
Correct. Dynamic data masking is the Snowflake feature designed to protect sensitive column values based on context such as the active role. A masking policy can be attached directly to SSN and EMAIL and can use conditional logic, for example checking CURRENT_ROLE() or IS_ROLE_IN_SESSION(), to determine whether to return the original value or a masked value. Because the policy is bound to the column metadata, it remains associated with the column when supported operations such as cloning are performed within the account, which aligns with the requirement for the masking behavior to follow the data.
- B. Incorrect.
Incorrect. Row access policies control which rows are visible to a query, not how individual column values are redacted. Someone might choose this option because both row access policies and masking policies are governance features, but row access policies are for row-level filtering and do not solve a column-masking requirement for SSN and EMAIL.
- C. Incorrect.
Incorrect. A secure view can be used to implement custom masking logic and is a common workaround in some environments, but it does not meet the requirement as directly or robustly as a masking policy attached to the columns themselves. The masking logic would apply only when users query the view, and it would not automatically follow the underlying columns if the table were cloned or copied elsewhere. It also introduces an operational dependency on forcing all access through the view.
- D. Incorrect.
Incorrect. Tri-Secret Secure is related to encryption key management and protection of data at rest, not query-time conditional masking based on roles. It does not selectively reveal plaintext to some roles and masked values to others. This option reflects a common misconception that encryption-at-rest features replace fine-grained data governance controls.