ADA-C01 Question 170
Single answerUse external tokenizationA healthcare company stores claims data in Snowflake and must ensure that sensitive member identifiers are never stored in clear text inside Snowflake. The security team already operates an external tokenization service that issues tokens and can detokenize values only for approved applications outside Snowflake. Analysts still need to join claims records on the tokenized member identifier and run standard SQL queries in Snowflake, but Snowflake users should not be able to reverse the tokenized values. Which approach best meets these requirements?
- A
Use external tokenization so the tokenization and detokenization occur outside Snowflake, and store only externally generated tokens in Snowflake tables.
- B
Use Dynamic Data Masking on the member identifier column so analysts see masked values while administrators can still query the original values in Snowflake.
- C
Use a tag-based masking policy together with row access policies so only authorized roles can view the original member identifiers in Snowflake.
- D
Use Tri-Secret Secure so the member identifiers remain inaccessible to Snowflake users, while still allowing detokenization for joins inside Snowflake.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use external tokenization and store only tokens in Snowflake. This pattern is appropriate when regulatory or organizational requirements state that the original sensitive values must not reside in Snowflake in readable form. In Snowflake, externally tokenized values can still be used for common analytics patterns such as filtering and joins, as long as the tokenization scheme preserves the needed referential consistency. By contrast, Dynamic Data Masking and tag-based masking policies protect query results but do not remove the underlying sensitive values from Snowflake storage. Tri-Secret Secure strengthens encryption key control for data at rest, but it is not a substitute for tokenization. This aligns with Snowflake best practices for external tokenization, where token generation and detokenization are handled by an external provider or service, and Snowflake operates only on tokenized values.
- A. Correct.
Correct. External tokenization is designed for cases where sensitive data must not be stored in clear text within Snowflake. The external tokenization service generates the token before data is loaded into Snowflake, and detokenization remains outside Snowflake under the customer-controlled service. Snowflake can store and query the token values, including joins on those tokens, without exposing the original identifiers to Snowflake users.
- B. Incorrect.
Incorrect. Dynamic Data Masking hides data at query time based on role or policy, but the original plaintext value is still stored in Snowflake. That does not satisfy the requirement that sensitive member identifiers are never stored in clear text inside Snowflake. This is a common misconception because masking protects display, not storage.
- C. Incorrect.
Incorrect. Tag-based masking and row access policies are governance controls for limiting visibility and access, but they do not prevent the original sensitive values from being stored in Snowflake. They are useful when Snowflake may hold the sensitive data and access must be controlled, but not when the requirement is to avoid storing clear text in Snowflake entirely.
- D. Incorrect.
Incorrect. Tri-Secret Secure adds customer control over encryption key management for data at rest, but it does not replace tokenization and does not prevent Snowflake from storing the underlying plaintext data logically within tables. It also does not provide an external detokenization workflow. This option confuses encryption-at-rest controls with tokenization.