ARA-C01 Question 188
Single answerGit integrationA data platform team uses Snowflake Git integration to manage SQL and Snowpark Python code for a shared analytics environment. The repository is hosted on a Git provider with private access, and different branches represent development, test, and production code. The architects want to let developers review files from the repository inside Snowflake and execute version-controlled SQL scripts in a controlled way, but they do not want Snowflake users to be able to push commits back to the remote repository from Snowflake. Which approach best meets these requirements?
- A
Create a Snowflake Git repository clone that connects to the remote repository using a secret and API integration, allow developers to fetch and browse branches in the clone, and execute SQL files from the clone while continuing to perform commits and pushes in the external Git provider.
- B
Create an internal stage, upload the Git working directory to the stage on each release, and configure Snowflake to treat the stage as a bidirectional Git remote so developers can commit and push from Snowsight when needed.
- C
Use a Snowflake Native App to mirror the repository into application packages, because Native Apps provide built-in source control operations including branch merge and push back to Git providers.
- D
Create an external access integration for the Git provider and let developers run shell-based Git commands from Snowpark Python worksheets, including clone, commit, and push, so all source control tasks happen inside Snowflake.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake Git integration as intended: connect Snowflake to a remote Git repository by configuring an API integration and secret, then create a repository clone in Snowflake. This enables teams to fetch repository contents and work with version-controlled files from within Snowflake, including browsing branches and using files in development and deployment workflows. At the same time, source authoring actions such as commit, merge, and push remain the responsibility of the external Git platform and developer tools.
This is the practical architecture for organizations that want governed access to repository contents inside Snowflake without turning Snowflake into a full Git client. It also matches Snowflake best practices for separation of concerns: use Git providers and CI/CD systems for source control operations, and use Snowflake repository clones to consume versioned code within the data platform.
Relevant Snowflake documentation areas include Git integration concepts, creating API integrations and secrets for repository access, and working with repository clones in Snowsight or SQL. These materials consistently describe fetch/read-oriented integration inside Snowflake rather than full commit/push lifecycle management.
- A. Correct.
Correct. Snowflake Git integration is designed to connect Snowflake to a remote Git repository through an API integration and authentication secret, creating a Snowflake repository clone that users can fetch from and browse. Teams can reference version-controlled files, including SQL and handler code, from within Snowflake. However, Snowflake Git integration is not intended to be a full bidirectional Git client for committing or pushing changes back to the remote repository from Snowflake. That aligns with the requirement to allow review and controlled execution inside Snowflake while keeping authoring and push operations in the external Git system.
- B. Incorrect.
Incorrect. A stage is for storing files, not for acting as a Git repository with branch, commit, merge, or push semantics. Uploading release artifacts to a stage may work for deployment packaging, but Snowflake does not turn a stage into a bidirectional Git remote, and developers cannot use Snowsight to commit and push to a Git provider through a stage.
- C. Incorrect.
Incorrect. Snowflake Native Apps are for packaging and distributing application functionality, not for general-purpose source control management. They do not provide built-in Git operations such as branch merge, commit, or push back to external Git providers. This option confuses application packaging with repository integration.
- D. Incorrect.
Incorrect. Snowpark Python worksheets do not provide shell access for running arbitrary Git CLI commands, and external access integration is for controlled outbound network access from supported code execution contexts, not for turning Snowflake into a workstation for full Git workflows. This option reflects a common misconception that external network access enables unrestricted OS-level tooling inside Snowflake.