ARA-C01 Question 187
Select 3Git integrationA data platform team uses Snowflake Git integration to manage SQL and Snowpark code for deployment across development, test, and production environments. The team wants developers to work from feature branches, validate code in Snowflake before merging, and ensure production deployments are promoted only from the main branch in the remote Git repository. Which TWO actions should the architect recommend to meet these requirements?
- A
Create a Snowflake Git repository clone that points to the remote repository, fetch branches and commits into Snowflake, and have developers explicitly switch to the required branch before executing files from that clone.
- B
Use Snowflake Git integration to commit changes directly from worksheets back to the remote repository so that validated SQL in Snowflake becomes the system of record.
- C
Reference files from the cloned repository in Snowflake for validation, then deploy to production only after refreshing the clone and executing content from the main branch path.
- D
Create separate internal stages for each Git branch and rely on stage directory listings as the authoritative branch state for promotion decisions.
- E
Configure branch-based workflows in the remote Git provider and use Snowflake only to fetch and read repository content; merges and branch protection remain managed outside Snowflake.
Show answer and explanation
Correct answers: A, C, E
Explanation
Snowflake Git integration is intended to connect Snowflake to a remote Git repository so code and artifacts can be fetched and referenced inside Snowflake. It is not a full Git client for creating commits, pushing branches, or managing merge workflows from within Snowflake. Therefore, architects should preserve the remote Git provider as the system of record and use its native controls for pull requests, approvals, and branch protection. Inside Snowflake, teams create a Git repository clone, fetch updates from the remote repository, and execute versioned files from the appropriate branch, tag, or commit. For production promotion, a common best practice is to validate feature-branch content in non-production environments, then deploy only from the main branch after the approved merge is completed remotely and the Snowflake clone is refreshed. This approach aligns with Snowflake documentation on Git repository clone objects and Git integration behavior, as well as standard DevOps branch-governance practices.
- A. Correct.
Correct. In Snowflake, a Git repository clone object is created to integrate with a remote repository. Snowflake fetches repository metadata and content from the remote source, and users can work against specific branches, tags, or commits exposed through the clone. For branch-based validation, developers should intentionally use the desired branch context before running SQL or Snowpark artifacts stored in the repository clone.
- B. Incorrect.
Incorrect. Snowflake Git integration is designed for reading repository content from a remote Git provider into Snowflake, not for authoring commits and pushing changes back from worksheets. The remote Git system remains the source of truth for commits, merges, and history. This option reflects a common misconception that Snowflake acts as a bidirectional Git client.
- C. Correct.
Correct. This aligns with a practical promotion model. Teams can validate code in Snowflake using files from a feature branch or other non-production branch, then refresh the repository clone to ensure Snowflake has the latest remote state and execute only content from the main branch for production deployment. This supports controlled promotion from the remote repository's approved branch.
- D. Incorrect.
Incorrect. Internal stages are not a substitute for Git branch management. While stages can store files, they do not preserve Git semantics such as branch lineage, merge history, or protected branch workflows. Using stage listings as branch state introduces governance and traceability gaps compared with using the remote Git repository as the authority.
- E. Correct.
Correct. Snowflake Git integration does not replace the governance capabilities of the Git provider. Best practice is to keep branch protection, pull requests, approvals, and merge policies in the remote platform such as GitHub, GitLab, or Azure DevOps. Snowflake then consumes repository content for execution and validation after fetching updates.