ARA-C01 Question 178
Single answerDevelopment lifecycle supportA financial services company is modernizing its Snowflake development lifecycle. The architecture team wants database changes, views, and application logic to move consistently from development to test to production, while reducing deployment drift between environments. Individual developers also need isolated workspaces so they can test changes without affecting shared environments. Which approach BEST supports these requirements in Snowflake?
- A
Use zero-copy clones of the relevant databases/schemas for developer isolation, manage SQL objects in version control, and promote changes through environment-specific deployment pipelines
- B
Have each developer create objects directly in the shared development database, then use Time Travel to restore previous versions if conflicts occur before manually recreating changes in test and production
- C
Replicate the production database into development for each release cycle, allow developers to modify replicated objects, and then fail over the changes into test and production after validation
- D
Store DDL scripts in individual developer worksheets, use database roles to separate environments, and rely on object tags to identify which definitions should be recreated in higher environments
Show answer and explanation
Correct answer: A
Explanation
The best answer is to combine Snowflake zero-copy cloning with external version control and automated deployment pipelines. For development lifecycle support, Snowflake best practices emphasize separating environments, using repeatable deployment processes, and minimizing manual recreation of objects. Zero-copy cloning enables fast, storage-efficient creation of dev/test environments from existing databases or schemas, which is especially useful for isolated developer workspaces and realistic testing. Source control systems and CI/CD tooling help manage DDL, views, procedures, and other code artifacts consistently across development, test, and production.
The distractors reflect common misconceptions. Time Travel is valuable for recovery but does not replace SDLC controls. Replication and failover are for cross-region/cross-account resilience and disaster recovery, not routine promotion of application changes. Worksheets, roles, and tags are helpful operational features, but they do not provide end-to-end lifecycle management without versioning and deployment automation.
Relevant Snowflake documentation and guidance include zero-copy cloning for creating isolated environments, Time Travel for object/data recovery, and replication/failover for business continuity rather than release promotion. In practice, Snowflake architects typically pair these native platform capabilities with a formal DevOps process to support reliable lifecycle management.
- A. Correct.
Correct. Zero-copy cloning is a Snowflake-native way to create isolated development or test copies quickly without duplicating storage for unchanged data. Combined with source control and CI/CD-style deployment pipelines, this supports consistent promotion across environments and reduces configuration drift. This aligns with Snowflake best practices for lifecycle support: use separate environments, automate deployments, and leverage cloning for safe testing and development.
- B. Incorrect.
Incorrect. Although Time Travel can help recover data or objects to a prior state within retention limits, it is not a deployment or change-management strategy. Having all developers work directly in a shared development database increases collisions and makes it harder to isolate and validate changes. Manually recreating changes across environments also increases drift and operational risk.
- C. Incorrect.
Incorrect. Database replication/failover is intended for disaster recovery and business continuity scenarios, not as a software development promotion mechanism. Replicated databases are generally read-only in the target account until failover, and failover is not designed to selectively promote developer-tested schema or code changes through SDLC environments.
- D. Incorrect.
Incorrect. Keeping DDL only in personal worksheets is not adequate source control and does not provide reliable collaboration, review, or repeatable deployment. Roles and tags are useful for security and governance, but tags do not manage object definition promotion. This approach lacks controlled versioning and automated deployment, making drift and missed dependencies likely.