ARA-C01 Question 181
Single answerDeploymentA global software company is standardizing how it deploys Snowflake objects across development, test, and production accounts. The platform team needs a repeatable process to promote databases, schemas, tables, views, tasks, and grants while minimizing manual steps and reducing the risk of environment drift. They also want to version-control changes and support automated validation in CI/CD pipelines. Which approach is the MOST appropriate for this requirement?
- A
Use Snowflake CLI with declarative project definitions to manage Snowflake resources as code, store the project in Git, and execute deployments through CI/CD pipelines.
- B
Create a database clone from development and share it to test and production after each release so that all objects and permissions are promoted together.
- C
Export DDL manually from Snowsight after each sprint and run the scripts directly in production using ACCOUNTADMIN to avoid role-related deployment failures.
- D
Use Time Travel to roll forward changed objects from development into test and production, because Time Travel is designed for cross-environment object promotion.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake CLI with declarative, version-controlled project definitions and integrate deployments into a CI/CD pipeline. For enterprise deployment scenarios, Snowflake best practices favor treating Snowflake resources as code, validating changes before promotion, and automating release workflows to reduce manual error and environment drift. This is especially important when promoting objects across multiple environments or accounts.
Why the other options are weaker:
- Cloning is valuable for environment setup, testing, and rapid duplication, but it is not a substitute for governed promotion of code and configuration across independent environments.
- Manual script execution, especially with ACCOUNTADMIN, is operationally risky and does not scale.
- Time Travel supports recovery and historical access, not deployment.
Relevant Snowflake documentation and best-practice areas include Snowflake CLI, DevOps and CI/CD guidance, access control/least privilege, zero-copy cloning, and Time Travel. An architect should distinguish between features for release automation versus features for data recovery or rapid environment provisioning.
- A. Correct.
Correct. For deployment standardization, Snowflake supports DevOps-style workflows using Snowflake CLI and project-based, declarative definitions to manage resources as code. This aligns with version control, automated validation, and CI/CD execution. It helps reduce configuration drift and avoids ad hoc manual deployments. This approach is the best fit for promoting Snowflake objects in a controlled, repeatable way across environments.
- B. Incorrect.
Incorrect. Zero-copy cloning is useful for creating fast copies of data and objects within the same account, but it is not a general deployment mechanism for promoting releases across separate dev, test, and prod accounts. Data sharing also does not deploy objects as independently managed production assets. This option confuses data/object duplication and sharing with governed software deployment practices.
- C. Incorrect.
Incorrect. Manual DDL export and execution increases the risk of drift, missed dependencies, and inconsistent permissions. Using ACCOUNTADMIN for routine deployments is also a poor practice because it violates least-privilege principles and can mask missing role design in the deployment process. While scripts can be part of deployment, this manual, high-privilege approach is not the most appropriate solution.
- D. Incorrect.
Incorrect. Time Travel is for accessing historical data states and recovering changed or deleted data within retention limits. It is not a deployment framework and does not promote changes across environments. This option reflects a misunderstanding of operational recovery features versus release management capabilities.