ARA-C01 Question 212
Single answerDatabasesA global company uses a Snowflake database named SALES_DB with multiple schemas for finance, operations, and analytics. Developers frequently clone SALES_DB into development environments for testing. Recently, the architecture team discovered that cloned databases continue to reference micro-partitions in the source database, which prevents some storage from being released after large table rebuilds in production. The team needs a design that minimizes this retention impact while still allowing teams to clone only the objects they need for development. What is the best architectural recommendation?
- A
Replace the single SALES_DB database with separate databases by domain so development teams can clone only the required database instead of the entire shared database
- B
Keep a single SALES_DB database, but convert all permanent tables to transient tables so cloned objects do not retain references to source storage
- C
Disable Time Travel on SALES_DB so cloned databases no longer retain references to the production micro-partitions
- D
Move all development clones into separate virtual warehouses because warehouse isolation reduces shared storage dependencies between cloned and source objects
Show answer and explanation
Correct answer: A
Explanation
The key architectural issue is the interaction between zero-copy cloning and Snowflake storage. When a database, schema, or table is cloned, the clone initially references the same micro-partitions as the source object. If the source object is heavily modified or rebuilt, Snowflake cannot fully reclaim storage for old partitions while they are still referenced by clones. In a design where many teams clone a large shared database, unnecessary cloned objects can increase storage retention side effects and administrative complexity.
The best practice is to align database boundaries to isolation and cloning needs. By separating domains into multiple databases, teams can clone only the relevant database rather than an oversized shared database. This improves environment portability, limits shared lineage scope, and better supports least-privilege administration. Snowflake documentation on zero-copy cloning and database design emphasizes that clones are metadata-based and storage-efficient initially, but retained references remain relevant until data diverges or clones are dropped. Warehouses are unrelated because they govern compute, not storage. Likewise, transient tables and Time Travel settings do not remove clone storage lineage behavior.
- A. Correct.
Correct. Zero-copy cloning operates at the object level and initially shares underlying micro-partitions with the source object. If a large monolithic database is cloned for development, many unnecessary objects may be included, and retained references can delay full storage reclamation after source data changes. Splitting the environment into multiple databases by domain is a practical architectural pattern because teams can clone only the database they need, reducing the blast radius of shared storage references and improving administrative isolation.
- B. Incorrect.
Incorrect. Transient tables reduce or eliminate Fail-safe costs, but they do not change the fundamental behavior of zero-copy cloning. Clones of transient tables still initially share underlying storage with the source objects. This option reflects a common misconception that transient objects avoid clone lineage effects; they do not.
- C. Incorrect.
Incorrect. Time Travel settings affect historical data retention, but disabling or reducing Time Travel does not eliminate the fact that clones reference the same underlying micro-partitions until data diverges. Clone relationships can still prevent immediate storage reclamation for replaced data. Also, removing Time Travel broadly from a production database may conflict with recovery requirements.
- D. Incorrect.
Incorrect. Virtual warehouses provide compute isolation only. They do not affect how databases, schemas, and tables store data or how zero-copy cloning references micro-partitions. This distractor targets the misconception that warehouse separation can solve storage architecture issues.