DAA-C01 Question 14
Single answerSynthetic Data GenerationA healthcare analytics team needs to provide analysts with a large, shareable dataset for dashboard development and workload testing. The source table contains protected health information (PHI), so the team cannot clone or share the original data. They need a repeatable way to generate millions of realistic test rows directly in Snowflake, while preserving useful patterns such as age ranges, visit dates, and category distributions without exposing real patient records. Which approach is the MOST appropriate?
- A
Use the GENERATOR table function with expressions such as UNIFORM(), NORMAL(), RANDOM(), and date functions to create synthetic rows, then shape columns to approximate the required distributions.
- B
Create a zero-copy clone of the production schema and share it securely, because cloned data does not duplicate storage and therefore is safe for PHI.
- C
Export the production data, remove direct identifiers such as names and IDs, and reload it into Snowflake as synthetic data because de-identified data is equivalent to synthetic data.
- D
Use SAMPLE on the production table to create a subset for analysts, because sampling changes the dataset enough to avoid disclosure risk while preserving realistic relationships.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to generate synthetic data directly in Snowflake using the GENERATOR table function combined with SQL-based randomization and shaping logic. This aligns with Snowflake best practices for creating non-production datasets when teams need scale, repeatability, and privacy protection without copying sensitive source records. In practice, teams commonly use TABLE(GENERATOR(ROWCOUNT => ...)) together with functions such as RANDOM(), UNIFORM(), NORMAL(), SEQ* functions, CASE expressions, and date arithmetic to create realistic values and distributions.
The other options confuse data-copying or data-reduction techniques with synthetic data generation. Zero-copy cloning is valuable for Dev/Test efficiency but does not protect sensitive content. Sampling and simple de-identification still rely on real underlying records and may not satisfy privacy requirements, especially for PHI. Snowflake documentation for table functions and data generation patterns supports using GENERATOR and SQL functions to create large synthetic datasets for testing and analytics development.
- A. Correct.
Correct. In Snowflake, a practical native approach for synthetic data generation is to use the GENERATOR table function to produce rows and then derive column values with SQL expressions and random/distribution functions such as RANDOM, UNIFORM, and NORMAL, along with date/time functions and CASE logic for categories. This supports repeatable, scalable generation of large non-production datasets without exposing original records. It is well suited for testing dashboards, performance, and development workflows when approximate distributions are sufficient.
- B. Incorrect.
Incorrect. Zero-copy cloning is efficient for creating copies of Snowflake objects, but a clone still represents the same underlying sensitive data. It does not anonymize or synthesize PHI. Storage efficiency is unrelated to privacy protection, so cloning production PHI would not meet the requirement to avoid exposing real patient records.
- C. Incorrect.
Incorrect. Removing direct identifiers is a common misconception, but de-identified or pseudonymized data is not the same as synthetic data. Real rows may still contain quasi-identifiers or combinations of attributes that can create re-identification risk. The scenario explicitly requires data that does not expose real patient records, making generated synthetic data the better fit.
- D. Incorrect.
Incorrect. Sampling preserves real records from the source table, just fewer of them. That means PHI or re-identification risk may still remain. Sampling can help with testing data volume or query behavior, but it is not an appropriate method for creating a safe synthetic dataset from protected healthcare data.