SnowPro Advanced: Security Engineer Question 119
Single answerUse the External Tokenization functionA healthcare company stores patient records in Snowflake and must allow analysts to join and aggregate data without exposing raw Social Security numbers (SSNs) to Snowflake. The security team decides to use external tokenization so that SSNs are tokenized before storage and detokenized only through a controlled external service when strictly required. Which implementation best meets this requirement while keeping Snowflake from storing the original SSN values?
- A
Create an external access integration to call the company’s tokenization service from a user-defined function, store only the returned tokens in Snowflake, and use a separate detokenization function with tightly restricted privileges for approved users.
- B
Create a masking policy that replaces SSNs with random values at query time, and allow privileged users to bypass the policy when they need the original SSN.
- C
Encrypt the SSN column with Snowflake Tri-Secret Secure so Snowflake cannot access the plaintext, then use standard SQL functions to detokenize values for authorized analysts.
- D
Use dynamic data masking together with row access policies so that Snowflake stores the raw SSNs but only displays partially masked values except for a privileged role.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use external tokenization so that token generation and detokenization occur outside Snowflake, with Snowflake storing only tokenized values. In Snowflake, this is typically implemented using a user-defined function that communicates with an external tokenization service through an external access integration. This design is appropriate when organizations must reduce exposure of highly sensitive data such as SSNs, PANs, or healthcare identifiers, while preserving the ability to join, group, and analyze records using stable tokens. By contrast, masking policies and row access policies protect display and access within Snowflake but do not prevent storage of the original data. Similarly, Tri-Secret Secure improves encryption key control but is not a substitute for tokenization. Snowflake documentation and best practices distinguish tokenization from masking and encryption: tokenization removes sensitive values from Snowflake storage, whereas masking and encryption protect data already stored in Snowflake.
- A. Correct.
Correct. External tokenization is designed for scenarios where sensitive values should not be stored in Snowflake in their original form. A common pattern is to use a UDF that calls an external tokenization provider through an external access integration, returning a token that is stored instead of the plaintext value. If detokenization is needed, it should be performed through a separate, tightly controlled function and limited to approved roles. This approach aligns with the requirement that Snowflake not store the original SSNs while still supporting analytics on tokenized values.
- B. Incorrect.
Incorrect. Dynamic masking or masking policies only affect how data is presented at query time; they do not prevent Snowflake from storing the original SSN values. This option fails the core requirement that raw SSNs must not be exposed to Snowflake storage. It reflects a common misconception that masking is equivalent to tokenization or data minimization.
- C. Incorrect.
Incorrect. Tri-Secret Secure strengthens key management and encryption controls, but it does not provide external tokenization and does not mean Snowflake stores only tokens. Snowflake still stores the underlying data encrypted at rest, and there is no standard SQL detokenization feature for values protected this way. This confuses encryption-at-rest controls with tokenization.
- D. Incorrect.
Incorrect. Row access policies and dynamic data masking are governance controls for restricting visibility in queries, not for replacing sensitive values before storage. In this design, Snowflake would still store the raw SSNs, which violates the stated security requirement. This is a plausible distractor because these features are often used for PII protection, but they address access control rather than external tokenization.