ARA-C01 Question 53
Single answerExternal tokenizationA healthcare company stores patient data in Snowflake and must protect Social Security numbers (SSNs) so that the original values are never persisted in Snowflake. Analysts still need to join patient records across internal tables using a consistent surrogate value, and a small claims-processing application must be able to retrieve the original SSN when required. The security team already operates an external tokenization service. Which design best meets these requirements?
- A
Load the clear-text SSNs into Snowflake, encrypt the column with a masking policy, and allow the claims application to decrypt the values when needed.
- B
Replace SSNs with externally generated tokens before loading data into Snowflake, store only the tokens in Snowflake, and let the claims application call the external tokenization service to detokenize outside Snowflake when authorized.
- C
Hash SSNs with SHA-256 during ingestion, store the hashes in Snowflake, and let the claims application reverse the hash using a secure key when needed.
- D
Use Snowflake external functions to detokenize SSNs on demand inside SQL queries so analysts can see the original values only for approved sessions.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to tokenize SSNs outside Snowflake and store only the externally generated tokens in Snowflake. This aligns with Snowflake's external tokenization pattern, which is designed for customers who need Snowflake to process tokenized values while ensuring the original sensitive data remains with an external tokenization provider. A key benefit is that deterministic or consistent tokens can still support joins and analytics across datasets without exposing the source sensitive values. Masking policies protect display access but do not prevent Snowflake from storing the original values. Hashing is not appropriate when later recovery of the original value is required. And while external functions can call outside services, architecturally they are not the recommended mechanism for broadly exposing detokenized values in Snowflake when the security goal is to keep the original sensitive data outside Snowflake entirely. This reflects Snowflake best practices for sensitive-data protection and the documented purpose of external tokenization.
- A. Incorrect.
Incorrect. Dynamic data masking can obscure values from certain roles, but the original clear-text SSNs would still be stored in Snowflake. That violates the requirement that original values are never persisted in Snowflake. Masking is an access-control feature, not a substitute for keeping sensitive raw values out of the platform.
- B. Correct.
Correct. External tokenization is specifically intended for scenarios where sensitive values must remain outside Snowflake while tokenized surrogates are stored and used for analytics. If the tokenization service produces consistent tokens, analysts can still join records across tables. Detokenization is handled by the external service, not by storing or revealing raw SSNs in Snowflake.
- C. Incorrect.
Incorrect. A cryptographic hash is one-way and cannot be reversed to recover the original SSN. While hashing may support deterministic joins in some use cases, it does not satisfy the requirement that a claims-processing application must retrieve the original value later. The phrase 'reverse the hash using a secure key' reflects a common misconception; hashes are not decrypted.
- D. Incorrect.
Incorrect. External functions can integrate Snowflake with external services, but using them to detokenize sensitive values inside SQL would expose original SSNs within Snowflake query processing and results, which conflicts with the requirement that original values are never persisted in Snowflake and should remain outside Snowflake's data plane. External tokenization patterns are intended to keep sensitive clear-text data external.