SnowPro Advanced: Security Engineer Question 141
Single answerUse synthetic data to support privacyA healthcare analytics company stores PHI in Snowflake and wants to give a third-party development team a dataset for application testing. The security engineer must minimize privacy risk while preserving realistic data patterns such as diagnosis distributions, seasonal claim volumes, and common field relationships. The third party must not be able to reverse the data back to real patients. Which approach BEST meets these requirements?
- A
Create a dynamic data masking policy on the production tables and share those masked tables directly with the third party.
- B
Generate a synthetic dataset from the production data that preserves statistical properties and referential patterns, validate utility, and provide the synthetic dataset instead of the original records.
- C
Clone the production database, remove direct identifiers such as patient name and SSN, and provide the clone because the remaining records no longer contain PHI.
- D
Tokenize only the patient identifier column and share the remaining original tables because tokenization of the primary key prevents re-identification.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to provide synthetic data rather than masked, tokenized, or lightly de-identified production data. In Snowflake security practice, synthetic data is appropriate when teams need realistic datasets for development, testing, training, or analytics without exposing actual sensitive records. The key distinction is that synthetic data consists of artificial records designed to preserve useful statistical characteristics and relationships, while masking, tokenization, and identifier removal generally still operate on real underlying data. For external sharing scenarios, relying only on masking or pseudonymization can leave residual re-identification risk through quasi-identifiers and attribute linkage. Best practice is to generate synthetic data from sensitive sources, validate that it maintains the required utility for the use case, and share only the synthetic dataset with the third party. This aligns with privacy-preserving design principles and common Snowflake guidance to minimize exposure of production sensitive data whenever possible.
- A. Incorrect.
Incorrect. Dynamic data masking helps obscure sensitive values at query time, but it does not create new artificial records. Sharing masked production tables still exposes underlying real records, distributions, and quasi-identifiers that could allow inference or re-identification. This approach is useful for controlled internal access, but it is not the best choice when a third party needs privacy-preserving test data.
- B. Correct.
Correct. Synthetic data is specifically intended to support privacy by generating artificial records that reflect important statistical characteristics and relationships of the source data without exposing actual individuals. For third-party testing, this is the strongest option among the choices because it balances privacy protection with data utility. Validation is also important to confirm the synthetic data still supports testing needs such as realistic volume patterns and field correlations.
- C. Incorrect.
Incorrect. Removing direct identifiers is only de-identification at a basic level and does not eliminate privacy risk. Healthcare data often contains quasi-identifiers and sensitive combinations that can still be linked back to individuals. A cloned production dataset with identifiers removed is still derived from real patients and may remain regulated or re-identifiable.
- D. Incorrect.
Incorrect. Tokenizing a single identifier column protects that specific field but leaves all other original attributes untouched. The dataset would still contain real patient-level records and potentially identifiable combinations of diagnosis, dates, geography, and utilization patterns. This does not meet the requirement to prevent reversal to real patients.