ARA-C01 Question 167
Select 3Support of DevOps/DataOps principlesA company is introducing DevOps/DataOps practices for its Snowflake platform. Development teams build database changes in isolated environments and promote them through test to production using CI/CD. Recently, several production incidents occurred because DDL changes were applied manually, some deployments were not reproducible, and one rollback required restoring dropped objects under time pressure. The lead architect wants an approach that improves release consistency, supports automated validation, and reduces risk during rollback. Which TWO actions best align with Snowflake-supported DevOps/DataOps best practices for this situation?
- A
Store Snowflake SQL DDL, task/stream definitions, and access-control scripts in version control, then deploy them through automated CI/CD pipelines using role-based service principals or service users.
- B
Promote changes by cloning the production database directly into production schemas before each deployment so teams can compare objects manually and decide what to recreate.
- C
Use zero-copy cloning to create ephemeral test environments from a production-like source for pre-deployment validation, and rely on Time Travel for rapid recovery of accidentally changed or dropped objects when appropriate.
- D
Allow developers to run schema changes manually in production as long as they document the SQL afterward in a shared repository to preserve an audit trail.
- E
Package repeatable deployment logic so that environment-specific values are parameterized, reducing hard-coded differences between dev, test, and production.
Show answer and explanation
Correct answers: A, C, E
Explanation
The best answers are 1, 3, and 5 because they directly address the core failures in the scenario: manual production changes, lack of reproducibility, weak validation, and difficult rollback. In Snowflake, strong DevOps/DataOps practices include managing SQL and object definitions as code, promoting changes through automated CI/CD pipelines, and using Snowflake-native features such as zero-copy cloning and Time Travel to support fast testing and operational recovery. Zero-copy cloning helps create realistic ephemeral environments without full data duplication, which is valuable for pre-release validation. Time Travel helps recover dropped or modified objects within configured retention periods, reducing rollback risk. Parameterization of environment-specific values supports repeatable deployments across dev, test, and prod. These practices are consistent with Snowflake guidance around automation, access control via roles, separation of duties, and use of native data lifecycle features rather than manual change processes.
- A. Correct.
Correct. Treating Snowflake objects and security configuration as code is a core DevOps/DataOps practice. Storing DDL and related deployment artifacts in version control enables peer review, traceability, reproducibility, and automated promotion through environments. Using automation accounts with least-privilege roles is preferred over ad hoc personal execution because it standardizes deployments and improves auditability.
- B. Incorrect.
Incorrect. Zero-copy cloning is useful for creating isolated lower environments quickly, but cloning production directly 'into production schemas' for manual comparison is not a sound promotion strategy. It increases operational risk, keeps the process manual, and does not address reproducibility or controlled CI/CD. Promotions should come from versioned deployment artifacts, not manual object comparison in production.
- C. Correct.
Correct. Zero-copy cloning is well suited for creating temporary validation environments that closely resemble production without duplicating storage. Time Travel can support operational recovery for dropped or changed objects within retention limits, which directly helps with rollback risk reduction. This aligns with Snowflake-native capabilities that support safer release validation and recovery.
- D. Incorrect.
Incorrect. Post-facto documentation does not make manual production changes reproducible or controlled. This approach preserves drift between environments and undermines CI/CD discipline. A common misconception is that documenting manual SQL is enough for DevOps maturity, but best practice is to make the pipeline the authoritative path for change promotion.
- E. Correct.
Correct. Parameterizing environment-specific settings is a standard release-engineering practice. It allows the same tested deployment logic to move across environments while minimizing hard-coded warehouse names, database names, integration references, or resource settings. This improves consistency and reduces deployment errors caused by maintaining separate scripts per environment.