SnowPro Advanced: Security Engineer Question 118
Single answerUse the External Tokenization functionA healthcare company stores patient records in Snowflake and must ensure that highly sensitive identifiers, such as national ID numbers, are never stored in clear text inside Snowflake. Analysts still need to join records and run reports using protected values. The security team decides to use Snowflake External Tokenization with an external tokenization provider. Which approach best meets this requirement while preserving the ability to work with the protected data in Snowflake?
- A
Configure external tokenization so sensitive values are tokenized by the external provider before or as they are loaded into Snowflake, and only tokens are stored in Snowflake while detokenization remains controlled by the external system.
- B
Use dynamic data masking on the national ID column so analysts see masked values, while clear-text values continue to be stored in Snowflake tables for joins and reporting.
- C
Encrypt the national ID column with Snowflake Tri-Secret Secure so Snowflake can still query the clear-text values internally without needing an external provider.
- D
Create a secure view that hashes the national ID values at query time, allowing the base table to retain clear-text values while meeting the requirement that sensitive data is never stored in Snowflake.
Show answer and explanation
Correct answer: A
Explanation
Snowflake External Tokenization is intended for organizations that must keep sensitive data under the control of an external tokenization system and avoid persisting the original sensitive values in Snowflake. In practice, data is tokenized using an external provider and Snowflake stores only tokens. This is different from masking, secure views, or encryption-at-rest features, all of which can protect access or storage but still leave the original data stored in Snowflake. For regulated workloads, external tokenization is a strong fit when policy requires that detokenization be governed outside Snowflake and that Snowflake operate on tokens instead of raw sensitive data. This aligns with Snowflake security guidance distinguishing tokenization from masking and encryption controls.
- A. Correct.
Correct. External Tokenization is designed for scenarios where the original sensitive data should not reside in Snowflake. An external tokenization provider generates tokens, and Snowflake stores the tokens instead of the original values. This allows many analytics workflows, including joins on tokenized values when the tokenization scheme supports consistent token generation, while keeping detokenization under external control.
- B. Incorrect.
Incorrect. Dynamic data masking protects what users see at query time, but the underlying clear-text data still exists in Snowflake storage unless it was tokenized or otherwise transformed before storage. This does not satisfy the requirement that the identifiers are never stored in clear text inside Snowflake.
- C. Incorrect.
Incorrect. Encryption features such as Tri-Secret Secure protect data at rest through key management controls, but they do not change the fact that the original sensitive values are stored in Snowflake. The requirement is specifically to avoid storing clear-text sensitive identifiers in Snowflake, which external tokenization addresses.
- D. Incorrect.
Incorrect. Hashing values in a secure view only transforms the data at query time. The base table would still contain the original clear-text national ID values, so the requirement is not met. In addition, one-way hashing is not equivalent to external tokenization and does not provide controlled detokenization through an external service.