ADA-C01 Question 172
Single answerEvaluate the use of data masking versus external tokenization based on business requirementsA healthcare analytics company is migrating a claims-processing workload to Snowflake. The CLAIMS table contains member names, dates of birth, and a national identifier that is regulated and must not be stored in its original form inside Snowflake. Analysts still need to run joins and trend analysis on the identifier across multiple datasets, while a small downstream application outside Snowflake must be able to recover the original value when legally authorized. The security team is deciding between implementing Snowflake dynamic data masking policies or using an external tokenization service before loading data into Snowflake. Which approach best meets the business and compliance requirements?
- A
Use Snowflake dynamic data masking on the national identifier column, because masking prevents any user from accessing the original value stored in Snowflake while still allowing authorized external applications to detokenize it.
- B
Use external tokenization before loading the data into Snowflake, because the original regulated identifier should not reside in Snowflake and authorized systems can recover it through the external tokenization service.
- C
Use Snowflake external functions to call a masking service at query time, because this ensures the original regulated identifier is never persisted anywhere and still supports native Snowflake joins on the clear-text identifier.
- D
Use a row access policy together with secure views, because row-level controls are designed to replace tokenization when legal requirements prohibit storing original sensitive values.
Show answer and explanation
Correct answer: B
Explanation
The key distinction is that Snowflake data masking protects how data is exposed to users at query time, while external tokenization changes what is stored by replacing sensitive values with tokens before or as data enters Snowflake. If the requirement is that the original sensitive value must not be stored in Snowflake, masking alone is insufficient because the clear-text data still exists in Snowflake storage and can potentially be accessed by highly privileged processes or roles depending on governance design. External tokenization is the better fit when organizations need to keep sensitive regulated identifiers out of Snowflake entirely while retaining reversibility through an external service. In practice, teams often use tokenization for the most strictly regulated fields and masking for fields that may remain in Snowflake but should be hidden from most users. This aligns with Snowflake best practices that distinguish dynamic data masking as a policy-based query-time protection mechanism and external tokenization as a pattern for protecting data before storage when business or regulatory requirements demand it.
- A. Incorrect.
Incorrect. Dynamic data masking in Snowflake obfuscates data at query time based on the querying role, but the underlying original value still remains stored in the table. That does not satisfy a requirement stating the regulated identifier must not be stored in its original form inside Snowflake. This option reflects a common misconception that masking changes storage format rather than presentation at query time.
- B. Correct.
Correct. External tokenization is appropriate when the business requirement is to avoid storing the original sensitive value in Snowflake altogether. A token can be stored instead of the real identifier, preserving the ability to join and analyze data consistently if the tokenization scheme is deterministic or consistently applied across datasets. Authorized downstream systems can recover the original value through the external tokenization provider under controlled processes, which aligns with the requirement for reversible access outside Snowflake.
- C. Incorrect.
Incorrect. External functions can integrate Snowflake with remote services, but they do not inherently provide native masking semantics or guarantee that clear-text values are never persisted elsewhere. More importantly, this option claims Snowflake can still perform native joins on the clear-text identifier while the original value is not stored, which is misleading. If clear text is not stored, joins would need to be performed on the tokenized value or another derived key, not the original identifier stored nowhere in Snowflake.
- D. Incorrect.
Incorrect. Row access policies and secure views control which rows or results users can see, but they do not replace tokenization for storage-level protection of sensitive values. If legal or compliance requirements prohibit storing the original identifier in Snowflake, row-level filtering does not address that requirement because the original data would still exist in the underlying storage.