DEA-C02 Storage and Data Protection Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Storage charges for the clone are zero until the source table is dropped, because shared partitions are billed to the source.

  Why it's wrong here

  Shared micro-partitions are billed once to the account, but the new and modified partitions in the clone are billed normally from the moment they are written. There is no rule that defers clone storage until the source is dropped. The clone's unique partitions exist independently of the source, so they accrue storage immediately after the load and update operations complete.

• ✗

  The clone is billed as a full 5.6 TB copy plus Time Travel, because cloning always materializes a complete physical copy for isolation.

  Why it's wrong here

  Zero-copy cloning never materializes a full physical copy at creation; it shares micro-partitions by metadata reference. Only changed partitions are rewritten, and Time Travel history for the clone begins at clone time rather than inheriting the source's full history. Treating the clone as a 5.6 TB materialized copy misunderstands the storage model and would overestimate both initial and ongoing charges.

• ✓

  Storage charges cover only the newly written and modified micro-partitions in DEV.RAW_CLICKS, while the shared unchanged partitions are billed once.

  Why this is correct

  Cloned tables share micro-partitions with the source, and Snowflake bills each distinct micro-partition once regardless of how many tables reference it. The 500 GB of new loads and 100 GB of updated rows create partitions unique to the clone, which are billed. The unchanged 5 TB remains shared and is charged once across both tables, so the incremental storage attributable to the clone reflects only the changed data.

• ✗

  The clone immediately doubles storage to 10 TB because cloning copies all micro-partitions.

  Why it's wrong here

  Zero-copy cloning does not duplicate micro-partitions; it creates new metadata that points to the same underlying micro-partitions as the source. Storage is shared until either table changes a partition, at which point only the changed partitions are rewritten. Claiming an immediate doubling mischaracterizes the clone as a physical copy, which it is not, and would overstate the initial cost of the operation.