What you will be able to do
- Choose the right authentication method and objects to connect Snowflake to a remote Git repository for automated ML deployment
- Fetch from the remote and address files by branch, tag or commit in a Git repository clone
- Run deployment scripts from a repository with EXECUTE IMMEDIATE FROM, including templating, dry runs and partial-failure behaviour
- Trace the object and privilege dependencies a Git-driven deployment relies on
Key concept
Git repository clone — A Snowflake object that mirrors a remote Git repository (its branches, tags and commits). Snowflake code reads files through it the way it reads files from a stage, so deployments can run straight from version control.
1.Connecting Snowflake to a remote repository
To deploy ML code from version control, the code first has to be visible inside Snowflake. When you integrate a remote repository hosted on GitHub, GitLab, BitBucket, Azure DevOps or AWS CodeCommit, Snowflake creates a Git repository clone that holds all of the remote's branches, tags and commits. From that clone you can fetch updates, browse files, execute .sql files, and import files into procedures and UDFs. Your local development workflow stays the same: Snowflake is simply one more client of the repository.
Setup involves two decisions. The first is the network path. A public route goes over the internet, with optional stable egress IPs for allowlisting. A private route goes through an outbound private link connection when you need full network isolation. The second decision is the authentication method, and that choice decides which Snowflake objects you have to create.
| Method | What you configure | Documented use case |
|---|---|---|
| No authentication | An API integration with details about the Git server; no credentials | Quick start with a public repository, including Snowflake Labs |
| Token (such as a personal access token) | A secret holding the username and token, plus an API integration allowed to use that secret | Automated pipelines or ML projects |
| OAuth | An API integration that supports OAuth2; no secret needed | Interactive development in Workspaces |
The final step is to create the clone with CREATE GIT REPOSITORY. Its API_INTEGRATION must point to an integration whose API_PROVIDER is git_https_api. If you supply GIT_CREDENTIALS, that secret must already be listed in the integration's ALLOWED_AUTHENTICATION_SECRETS, because the integration acts as the allowlist for credentials.
Checkpoint 1 of 8· Check yourself
An ML team wants a scheduled deployment script to pull from a private repository with no person signing in. Which authentication method does the Snowflake setup guidance point to?
Unattended processes need credentials they can use without a person signing in, so Snowflake recommends tokens for pipelines and ML projects. Private link decides the network path, not how you authenticate.
“Automated pipelines or ML projects: configure token-based authentication so that scripted processes can access the repository without manual sign-in.”Source: docs.snowflake.com
2.Fetching and addressing branches, tags and commits
The clone does not update itself. A pipeline brings it up to date with ALTER GIT REPOSITORY ... FETCH (or with the Fetch button in Snowsight). Fetching pulls in every branch, tag and commit, and it also prunes anything that has been removed from the remote. SHOW GIT BRANCHES and SHOW GIT TAGS list what the clone currently contains.
Checkpoint 2 of 8· Fill the gap
Which keyword updates the clone with the remote repository's latest contents?
ALTER GIT REPOSITORY snowflake_extensions ? ;ALTER GIT REPOSITORY ... FETCH synchronizes the clone, bringing in new commits and pruning ones that were removed upstream.
Source: docs.snowflake.comYou address files in the clone as you would files in a stage, and the path segment decides which version of the code you get. A branches/ path follows that branch as fetches bring in new commits. A commits/ path names a single commit hash. For a production deployment, the choice between them decides whether a later fetch can change what you run.
| Reference by | Path form |
|---|---|
| Branch name | @repository_name/branches/branch_name |
| Tag name | @repository_name/tags/tag_name |
| Commit hash | @repository_name/commits/commit_hash |
Checkpoint 3 of 8· Check yourself
Which path form names a single, specific commit, not whatever a branch currently points to?
The commits/ form takes a commit hash. A branches/ path resolves to the branch as last fetched, and the other two are not documented forms.
“LS @repository_name/commits/commit_hash;”Source: docs.snowflake.com
Checkpoint 4 of 8· Exam question
What does Snowflake create when you run `CREATE GIT REPOSITORY` against a remote origin, and how does its content stay current?
Correct answer: A — A read-only snapshot of the remote's branches, tags, and commits inside Snowflake that changes only when a fetch is run
- A. Correct. The Git repository object holds a read-only clone of the remote; its content is refreshed only by an explicit `ALTER GIT REPOSITORY ... FETCH` (or `snow git fetch`), never automatically.
- B. Incorrect. Snowflake does not poll the remote, and the repository clone is read-only; commits are pushed only from tools such as Workspaces with write credentials.
- C. Incorrect. The object is not a webhook-fed stage; Snowflake pulls content only on an explicit fetch and exposes it under branch, tag, and commit paths.
- D. Incorrect. The object stores repository files, not database objects; SQL files must be executed (for example with `EXECUTE IMMEDIATE FROM`) to create anything.
Sources3
3.Running deployment scripts with EXECUTE IMMEDIATE FROM
After the clone is fetched, a deployment can run SQL straight from it. EXECUTE IMMEDIATE FROM runs the statements in a staged file, and a Git repository clone counts as a stage for this purpose. The file can hold plain SQL or Snowflake Scripting blocks.
EXECUTE IMMEDIATE FROM @snowflake_extensions/branches/main/sql/create-database.sql;The same script can target different environments. If the file begins with the --!jinja directive, or if you add a USING clause, Snowflake renders it as a Jinja2 template before running it. That lets one script choose its deployment target from variables. DRY_RUN = TRUE returns the rendered text without executing anything. It defaults to FALSE.
EXECUTE IMMEDIATE
FROM { absoluteFilePath | relativeFilePath }
[ USING ( <key> => <value> [ , <key> => <value> [ , ... ] ] ) ]
[ DRY_RUN = { TRUE | FALSE } ]When every statement succeeds, the command returns the result of the last one. When a statement fails, the command fails and returns that statement's error message. However, the statements that ran before it are not undone. A rerun therefore starts from a partly deployed state, so release scripts have to be written to cope with that.
Checkpoint 5 of 8· Check yourself
A release file with ten statements fails on statement six. What is the state of the account?
EXECUTE IMMEDIATE FROM stops at the failing statement and returns its error. The statements before it have already completed.
“any statements in the file prior to the failed statement have successfully completed.”Source: docs.snowflake.com
Checkpoint 6 of 8· Exam question
A team keeps ML pipeline code in a private GitHub repository and authenticates with a personal access token. Which set of Snowflake objects lets them create a Git repository object for it?
Correct answer: B — A password-type secret holding the username and token, plus a `git_https_api` API integration allowing that prefix and secret
- A. Incorrect. External access integrations are for outbound calls from UDFs and procedures; a Git repository object is bound to an API integration instead.
- B. Correct. The repository object needs an API integration with `API_PROVIDER = git_https_api`, `API_ALLOWED_PREFIXES`, and `ALLOWED_AUTHENTICATION_SECRETS`, and `GIT_CREDENTIALS` pointing at the secret.
- C. Incorrect. Storage integrations and external stages target cloud object storage, not Git hosting, and cannot back a Git repository object.
- D. Incorrect. OAuth security integrations authenticate clients to Snowflake, and notification integrations deliver messages; neither supplies Git credentials to the repository object.
Sources4
4.The object and privilege chain behind a Git deployment
A Git-driven deployment depends on a chain of objects, and every link has to exist and be usable. The secret comes first. Next is the API integration that allows that secret. The repository clone references the integration, and the scripts run from the clone. Privileges follow the same chain. If neither the current role nor the repository's owning role has USAGE on the API integration, Git operations fail with insufficient privileges. The role running EXECUTE IMMEDIATE FROM needs READ (internal stage) or USAGE (external stage) on the stage that holds the file. It can also only run the statements in the file that it has privileges for, so a CREATE TABLE fails if the role cannot create tables.
Checkpoint 7 of 8· Put it in order
Put the setup for token-authenticated Git deployment in order
- 1.Create a secret holding the username and token
- 2.Fetch, then run a script from the clone with EXECUTE IMMEDIATE FROM
- 3.Create the Git repository clone that references the API integration
- 4.Create an API integration that allows Snowflake to use that secret
The integration must be allowed to use the secret, and the clone references the integration. Each object depends on the one before it.
“Configure a secret containing the username and token to use, then configure an API integration that allows Snowflake to use the secret when authenticating.”Source: docs.snowflake.com
Checkpoint 8 of 8· Check yourself
A deployment role owns the Git repository clone, but FETCH fails with an insufficient-privileges error. What is the most likely missing grant?
Git operations need USAGE on the API integration, held by either the current role or the role that owns the clone.
“if neither the current role nor the role that owns the Git repository has USAGE on the API integration used by the repository.”Source: docs.snowflake.com
Sources4
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A failed EXECUTE IMMEDIATE FROM rolls back everything, so rerunning it starts from a clean slate.Why is that wrong?
The command stops at the failing statement, and every statement before it has already completed. A rerun has to cope with objects that already exist.
Covered in Running deployment scripts with EXECUTE IMMEDIATE FROM
2.Fetching only adds new commits, so branches deleted upstream stay available in Snowflake.Why is that wrong?
Fetch also prunes branches and commits that no longer exist in the remote.
Covered in Fetching and addressing branches, tags and commits
3.Owning the Git repository clone is enough to run Git operations on it.Why is that wrong?
Either the current role or the owning role also needs USAGE on the API integration the repository uses.
Covered in The object and privilege chain behind a Git deployment
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“The clone includes all branches, tags, and commits from the remote repository.”
↩︎ Connecting Snowflake to a remote repository“Through the Git repository clone, Snowflake becomes another client of your repository separate from your local repository.”
↩︎ Key concept - 2.
“The API integration you specify here must have an API_PROVIDER parameter whose value is set to git_https_api.”
↩︎ Connecting Snowflake to a remote repository“The secret you specify here must be a secret specified by the ALLOWED_AUTHENTICATION_SECRETS parameter of the API integration”
↩︎ Connecting Snowflake to a remote repository - 3.
“ALTER GIT REPOSITORY snowflake_extensions FETCH;”
↩︎ Fetching and addressing branches, tags and commits“you also prune branches and commits that were fetched earlier but no longer exist in the remote repository.”
↩︎ Exam trap 2“Git operations can fail with an insufficient-privileges error”
↩︎ Exam trap 3“When you do so, you also prune branches and commits that were fetched earlier but no longer exist in the remote repository.”
↩︎ Prediction“LS @repository_name/commits/commit_hash;”
↩︎ Checkpoint“if neither the current role nor the role that owns the Git repository has USAGE on the API integration used by the repository.”
↩︎ Checkpoint - 4.
“TRUE returns the rendered file contents without executing the SQL statements.”
↩︎ Running deployment scripts with EXECUTE IMMEDIATE FROM“For example, you can use a template to dynamically choose the deployment target of the objects defined in the script.”
↩︎ Running deployment scripts with EXECUTE IMMEDIATE FROM“The role used to execute the file can only execute the statements in the file for which it has privileges.”
↩︎ The object and privilege chain behind a Git deployment“any statements in the file prior to the failed statement have successfully completed.”
↩︎ Exam trap 1“any statements in the file prior to the failed statement have successfully completed.”
↩︎ Checkpoint
Also cited
“Automated pipelines or ML projects: configure token-based authentication so that scripted processes can access the repository without manual sign-in.”
↩︎ Checkpoint“Configure a secret containing the username and token to use, then configure an API integration that allows Snowflake to use the secret when authenticating.”
↩︎ Checkpoint