SnowPro Associate: Platform Question 344
Single answer● CloningA data engineering team needs to create a QA copy of the PROD_DB database so testers can validate a new release without affecting production. The team wants the copy to be created quickly, avoid duplicating storage for unchanged data, and allow QA to make independent changes to tables after the copy is created. Which Snowflake feature should they use?
- A
Create a zero-copy clone of PROD_DB for QA
- B
Use Time Travel to query PROD_DB directly from the past for QA testing
- C
Export PROD_DB data to stage files and reload it into a new QA database
- D
Create a secure data share from PROD_DB to the QA team
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use a zero-copy clone. Snowflake cloning is designed for exactly this scenario: quickly creating independent databases, schemas, or tables for development, testing, or QA. At clone creation time, Snowflake does not duplicate all underlying data files; instead, the source and clone initially reference the same micro-partitions. As either object changes, Snowflake maintains independence through copy-on-write behavior, so subsequent changes in QA do not affect production. This makes cloning both fast and storage-efficient compared with exporting and reloading data. Time Travel is related because Snowflake can clone objects from a historical point in time if needed, but Time Travel alone is not the answer here. Secure data sharing is also not appropriate because it provides access to shared data rather than a writable, isolated copy. These behaviors are documented in Snowflake guidance for zero-copy cloning and Time Travel.
- A. Correct.
Correct. Zero-copy cloning creates a new database, schema, or table almost instantly by initially referencing the same underlying micro-partitions as the source object. This avoids copying unchanged data at creation time and allows the clone to diverge independently as changes are made. This is the standard Snowflake approach for quickly creating dev/test/QA environments from production data.
- B. Incorrect.
Incorrect. Time Travel allows querying, cloning, or restoring historical data within the retention period, but it does not by itself create an independent QA environment. Querying production data from the past would not give testers a separate database where they can safely make changes.
- C. Incorrect.
Incorrect. Exporting and reloading would create a full physical copy, which is slower, more operationally complex, and typically less storage-efficient than cloning. While this could produce an independent environment, it does not meet the requirement to create the copy quickly and avoid duplicating unchanged storage.
- D. Incorrect.
Incorrect. Secure data sharing is designed for sharing live data across accounts without copying it, not for creating an independently modifiable QA copy. Recipients of shared data cannot directly modify the shared objects, so this would not satisfy the testing requirement.