ADA-C01 Question 173
Single answerEvaluate the use of data masking versus external tokenization based on business requirementsA healthcare company is migrating claims data to Snowflake. The CLAIMS table contains member names, dates of birth, and national ID numbers. Internal analysts must be able to run joins and aggregations on the national ID field inside Snowflake, but most users should only see a protected representation of that value. The company's compliance team also requires that a small subset of applications be able to detokenize the national ID outside Snowflake using an existing enterprise tokenization service, and they do not want Snowflake to store the original sensitive value for those application workflows. Which approach best meets these business requirements?
- A
Store the original national ID in Snowflake and apply a masking policy to all roles; this satisfies both protected display and external detokenization requirements.
- B
Use external tokenization before loading the data into Snowflake so only tokens are stored there, and use Snowflake masking policies only if additional role-based obfuscation of the tokenized column is needed.
- C
Use row access policies on the CLAIMS table because row-level filtering is the recommended way to protect individual sensitive column values while preserving joins on those values.
- D
Encrypt the national ID column with Tri-Secret Secure keys and allow approved applications to decrypt it outside Snowflake when needed.
Show answer and explanation
Correct answer: B
Explanation
The key design decision is based on whether Snowflake should store the original sensitive value or only a protected surrogate. Dynamic data masking is appropriate when sensitive data remains in Snowflake and visibility must vary by role, but it does not replace external tokenization when the requirement is to avoid storing the original value in Snowflake and to support detokenization through an external system. External tokenization is commonly used when organizations already have enterprise token vaults, format-preserving tokenization requirements, or regulatory mandates that limit where cleartext sensitive data may reside. In contrast, Snowflake masking policies are policy-based controls for query-time obfuscation of stored data. Snowflake documentation and best practices distinguish these approaches: masking policies govern role/context-based exposure of column data in Snowflake, while external tokenization is an architectural choice for keeping sensitive cleartext outside Snowflake and working with tokens instead.
- A. Incorrect.
Incorrect. Dynamic data masking in Snowflake is useful when Snowflake stores the original sensitive data and needs to present different views of that data based on role or context. However, this option does not meet the stated requirement that Snowflake should not store the original sensitive value for certain application workflows. It also does not provide external detokenization through the company's existing enterprise tokenization service. A common misconception is to treat masking as a substitute for tokenization; masking controls display/access in Snowflake, while tokenization changes what is stored.
- B. Correct.
Correct. External tokenization is the better fit when the business requires Snowflake to store tokens instead of the original sensitive values and when detokenization must occur through an external enterprise tokenization system. This approach also preserves the ability to join and aggregate on the tokenized value, assuming the tokenization method is consistent and deterministic for the same input where business use cases require equality matching. Snowflake masking policies can still be layered on top if role-based presentation controls are needed for the token values themselves or for other columns.
- C. Incorrect.
Incorrect. Row access policies control which rows are visible to a user, not how a specific sensitive column value is transformed or hidden. They do not address the requirement to protect the national ID representation while still allowing joins and aggregations on the field. This distractor reflects a common confusion between row-level security and column-level protection mechanisms such as masking or tokenization.
- D. Incorrect.
Incorrect. Encryption, including customer-managed key approaches such as Tri-Secret Secure, protects data at rest and helps meet key-management and governance requirements, but it does not provide application-level tokenization semantics or external detokenization by an enterprise tokenization service. Approved applications do not directly decrypt Snowflake column values outside Snowflake in the manner described here. This option confuses storage encryption with tokenization and data access design.