SnowPro Advanced: Security Engineer Question 140
Single answerUse synthetic data to support privacyA healthcare analytics team stores PHI in Snowflake and wants to give an external development vendor a dataset for application testing. The vendor must preserve realistic data patterns, distributions, and table relationships, but must not receive any original patient values or any data that can be traced back to an individual. The security engineer recommends generating synthetic data inside Snowflake rather than masking or tokenizing the production tables. Which approach best meets the requirement?
- A
Create a synthetic dataset generated from the statistical characteristics of the source data, then provide the vendor access only to the synthetic tables in a separate environment.
- B
Apply dynamic data masking to PHI columns in the production tables and give the vendor direct access, because masked columns are equivalent to synthetic data.
- C
Tokenize direct identifiers such as patient_id and SSN, then share the tokenized production tables with the vendor because indirect identifiers will no longer present privacy risk.
- D
Use row access policies to restrict the vendor to a subset of real patient records, because limiting the number of rows eliminates re-identification concerns.
Show answer and explanation
Correct answer: A
Explanation
The key requirement is to support realistic testing while ensuring the external vendor receives no original patient values and no data traceable to real individuals. In Snowflake security design, masking policies, tokenization, and row access policies are controls for restricting or obfuscating access to real data, but they do not create synthetic data. Synthetic data generation is the appropriate privacy-preserving approach when the goal is to share realistic but non-authentic records for development or testing. Best practice is to keep production data protected, generate a separate synthetic dataset, and expose only that dataset to external users in a segregated environment or account. This aligns with the general security principle of data minimization and reduces re-identification risk more effectively than policy-based controls on live PHI.
- A. Correct.
Correct. Synthetic data is intended to preserve useful characteristics of the original data without exposing actual records. Generating new values based on the source data's patterns, distributions, and relationships is the best fit when the requirement explicitly states that the vendor must not receive original patient values and the data must not be traceable to individuals. Isolating the synthetic dataset in a separate environment further reduces the risk of accidental access to production PHI.
- B. Incorrect.
Incorrect. Dynamic data masking protects specific column values at query time, but the underlying data is still the original production data. Masking does not transform the dataset into synthetic data, and other attributes, joins, or quasi-identifiers can still create privacy and re-identification concerns. It is useful for controlled internal access, not as a substitute for synthetic data when sharing broadly with external parties.
- C. Incorrect.
Incorrect. Tokenization of direct identifiers reduces some risk, but the dataset still contains original records and potentially sensitive indirect identifiers such as dates, diagnoses, geography, or utilization patterns. That means the data can still be linkable or re-identifiable. Tokenized production data is therefore not equivalent to synthetic data for this requirement.
- D. Incorrect.
Incorrect. Row access policies control which rows a role can see, but they do not remove the fact that the visible rows are real patient records. Showing only a subset of production data does not eliminate privacy risk, especially in healthcare scenarios where even a small sample may contain unique or identifiable individuals.