What you will be able to do
- Set up a production Git folder with a service principal, its own Git credential, and the right permissions
- Keep a production Git folder in sync with external CI/CD or a scheduled job that calls the Repos API
- Choose between production Git folders, Git with jobs, and Declarative Automation Bundles for a given deployment need
1.Setting up a production Git folder with a service principal
A production Git folder is a Git folder that an admin creates outside the user folders. It is checked out on a deployment branch, and only automation updates it. That automation needs an identity of its own. Databricks recommends a service principal, a non-human identity, for automated or shared workflows such as CI/CD pipelines and scheduled jobs. The service principal needs its own Git credentials to reach your Git provider. An admin can link them in the UI: Settings > Identity and access > Service principals > Manage, then the Git integration tab and Add Git credential. You can also do this from the Databricks CLI by authenticating as the service principal with OAuth and running:
databricks git-credentials create <git-provider> \ --personal-access-token <git-pat> \ --git-email <git-email>Credential defaults are why the service principal matters. Each Git provider allows one default credential per user, and jobs and Repos API calls use that default. A job that needs a non-default credential for a provider must run as a service principal. Once the credential exists, you create the Git folder for the deployment branch in a subfolder under Workspace, organised by project, team or stage. Then you share it. Give Can Run to project users who run workflows and to any service principal that runs automation against the folder. You can optionally give Can View to all workspace users so they can find it.
Checkpoint 1 of 5· Put it in order
Put the steps for creating a production Git folder in order.
- 1.Create a Databricks Git folder for the repo and branch in a subfolder under Workspace
- 2.Create or use a service principal and configure a Git credential so it can access that repository
- 3.Assign permission levels, such as Can Run for project users and service principals, then click Add
- 4.Select the folder, then Share
- 5.Choose the Git repository and branch for deployment
The documented sequence goes from repository and branch, to identity and credential, to creating the folder, and then to sharing and permissions.
“Create or use a service principal and configure a Git credential so it can access that repository.”Source: docs.databricks.com
Teams that manage the workspace with Terraform can automate the same setup with the Databricks Terraform provider. Because of how Terraform evaluates providers, the setup is split into two configurations. The first creates the service principal and an on-behalf-of token. The second authenticates as the service principal, adds its Git credential and creates the Git folder:
resource "databricks_repo" "this" {
provider = databricks.sp
url = var.repo_url
depends_on = [databricks_git_credential.sp]
}2.Keeping the production Git folder in sync
A Git folder doesn't follow its remote branch by itself, so something has to pull. Databricks documents two options. The first is external CI/CD: a tool such as GitHub Actions pulls the latest commits whenever a PR is merged into the deployment branch. The Databricks GitHub Actions page has an example YAML file that updates a workspace Git folder when a remote branch updates. That example authenticates with workload identity federation for GitHub Actions. The second is a scheduled job: if you have no external CI/CD, a notebook runs on a schedule and calls the Repos API through the Databricks SDK's WorkspaceClient. The call looks up the folder's object ID from its workspace path and updates it to the branch you name:
w.repos.update(w.workspace.get_status(path="<git-folder-workspace-full-path>").object_id, branch="<branch-name>")Checkpoint 2 of 5· Fill the gap
Which Repos API method does the scheduled-job notebook call to bring the production Git folder up to date?
w.repos. ? (w.workspace.get_status(path="<git-folder-workspace-full-path>").object_id, branch="<branch-name>")The SDK calls repos.update with the folder's object ID and the branch name. There is no repos.pull method in this sample.
Source: docs.databricks.comCheckpoint 3 of 5· Exam question
A platform team is setting up the production Git folder `/Workspace/Production/reporting` that scheduled jobs read from. Data engineers on the team should be able to trigger job runs against the code in this folder but must not be able to edit files there directly, while a dedicated service principal used by the CI/CD pipeline needs to pull new commits into the folder after each deployment approval. Which two access assignments correctly satisfy these requirements?(Select 2)
Correct answers: A, B — Grant the data engineers group "Can Run" permission on the production Git folder so they can execute jobs without modifying its contents.; Grant the CI/CD service principal "Can Edit" permission on the production Git folder so it can update the checked-out branch via the Repos API.
- A. Assigning run-only access to the engineers group matches the stated requirement of letting them trigger job runs without being able to change the checked-out code, which is the standard split recommended for production Git folders.
- B. The service principal that pulls new commits through the Repos API needs edit-level access to the folder, because run-only permission is not sufficient to change which branch or commit the folder is checked out to.
- C. Granting broad edit access to the engineers group defeats the purpose of separating production code changes from routine job execution, and it lets production notebooks be modified directly instead of through a reviewed pull request.
- D. Run-only permission lets a principal execute jobs against the current checkout but does not grant the write access the Repos API needs to change the folder's branch or commit, so the pipeline's update call would fail with a permission error.
- E. Applying manage-level access to unrelated personal folders has nothing to do with controlling who can run or edit the production folder, and it unnecessarily widens admin reach into individual developers' own workspaces.
- F. Removing all access from the engineers group would also block their ability to run jobs against the folder, which directly contradicts the requirement that they be able to trigger runs.
3.When a production Git folder is the right tool
For full CI/CD, Databricks recommends Declarative Automation Bundles (formerly Databricks Asset Bundles). The Git integration setup page puts it plainly: use Git folders for interactive development, and use bundles with versioned artifacts for production deployments. A production Git folder is the lighter option when you only want to deploy code into the workspace. The main limit is what it keeps under source control. Notebooks and dashboard drafts are versioned. The configuration of the jobs and pipelines that run them is not, and neither is the configuration for publishing dashboards. External orchestrators such as Airflow can still use this approach. A third option, Git with jobs, points some job types at a remote repository. When a run starts, Databricks snapshots the repository and runs every task against that version. It supports only a limited set of task types, and job configuration stays out of source control there too.
Checkpoint 4 of 5· Match them up
Match each deployment approach to what it gives you.
Tap a term, then the definition that fits it.
Both the production Git folder and Git with jobs source-control only code. Bundles are the recommended route for full CI/CD, where resource definitions live in source as well.
“Configurations for jobs or pipelines that run assets in the Git folder and configurations for publishing dashboards are not in source control.”Source: docs.databricks.com
Checkpoint 5 of 5· Exam question
A team without access to an external CI/CD platform like GitHub Actions wants to keep a production Git folder synchronized with the `main` branch as commits are merged. Which two approaches are valid ways to achieve this synchronization for Git-based CI/CD with Databricks Git folders?(Select 2)
Correct answers: A, B — Schedule a Databricks job that runs a notebook on a recurring interval to call the Repos API and pull the latest `main` commit into the folder.; Configure an external CI/CD tool to call the Repos API's update endpoint automatically whenever a pull request merges into the deployment branch.
- A. This is a documented fallback pattern: running a scheduled notebook that calls the Repos API gives teams without an external CI/CD tool a way to pull the latest commit into the production folder on a recurring basis.
- B. This is the primary recommended pattern: an external CI/CD tool detects the merge event and calls the Repos API's update endpoint to synchronize the production folder, which is faster and more event-driven than a fixed schedule.
- C. Git folders do not silently poll the remote repository and self-update; a commit lands on GitHub, but nothing pulls it into the folder unless a job, pipeline step, or manual action explicitly calls the Repos API.
- D. Manually clicking through the UI in response to informal notifications is not an automated or recommended CI/CD pattern; it does not scale and is prone to missed or delayed updates.
- E. Sparse checkout narrows which paths are checked out from the repository, but it does not create any automatic redeployment behavior triggered by new commits.
- F. Scheduled production jobs should read from a single, access-controlled production folder; pointing them at whichever personal folder happened to update most recently removes any predictable, auditable deployment path.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.With a production Git folder, the whole deployment is under source control, job definitions included.Why is that wrong?
Only code files such as notebooks and dashboard drafts are versioned. Job and pipeline configuration, and dashboard publishing configuration, stay outside Git. Use Declarative Automation Bundles when those need versioning too.
2.A service principal that updates a Git folder can reuse the Git credentials of the admin who set it up.Why is that wrong?
The service principal needs its own linked Git credential. Jobs that need a non-default credential for a provider must use a service principal.
Covered in Setting up a production Git folder with a service principal
3.A production Git folder picks up merged commits automatically, because it tracks its remote branch.Why is that wrong?
Something has to pull. That can be an external CI/CD tool such as GitHub Actions when a PR merges, or a scheduled job that calls the Repos API.
Covered in Keeping the production Git folder in sync
Practise it for real
Set up a production Git folder that a scheduled job keeps in sync with the deployment branch
1.As a workspace admin, add a Git credential to a service principal: Settings > Identity and access > Service principals > Manage, then the Git integration tab and Add Git credential.
Why: The automation runs as the service principal, and the service principal needs its own access to the Git provider.
You should see: The service principal shows a linked Git credential for your provider.
2.Create a Git folder for the deployment branch in a subfolder under Workspace, outside /Workspace/Users/, for example a folder named for the project or stage.
Why: Production Git folders sit outside user folders and hold the deployment branch.
You should see: A Git folder checked out on the deployment branch, in a non-user location.
3.Share the folder: give Can Run to project users and to the service principal, and optionally Can View to all workspace users.
Why: Most users should have run-only access to production Git folders.
You should see: Project users can run notebooks in the folder but can't edit them.
4.Create a notebook that calls w.repos.update(...) with the folder's full workspace path and the deployment branch, and schedule it as a job that runs as the service principal.
Why: Without external CI/CD, a scheduled job is the documented way to keep the folder in sync.
You should see: After a PR merges into the deployment branch, the next scheduled run brings the folder up to the latest commit.
Stuck? Get a nudge
If the job fails to authenticate to Git, check which identity it runs as and whether that identity has a default credential for the provider.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Use a service principal for automated or shared workflows like CI/CD pipelines and scheduled jobs.”
↩︎ Setting up a production Git folder with a service principal“the service principal needs its own Git credentials to access your Git provider.”
↩︎ Exam trap 2 - 2.https://docs.databricks.com/aws/en/repos/repos-setupOfficial docs
“Jobs that require a non-default Git credential for a provider must use a service principal.”
↩︎ Setting up a production Git folder with a service principal“Use Git folders for interactive development. For CI/CD and production deployments, use Declarative Automation Bundles with versioned artifacts and workload identity federation.”
↩︎ When a production Git folder is the right tool - 3.https://docs.databricks.com/aws/en/repos/ci-cdOfficial docs
“Can Run for project users who need to run workflows.”
↩︎ Setting up a production Git folder with a service principal“External CI/CD: Use tools such as GitHub Actions to pull the latest commits when a PR is merged into the deployment branch.”
↩︎ Keeping the production Git folder in sync“If you prefer to deploy only code into the workspace, you can use a production Git folder instead.”
↩︎ When a production Git folder is the right tool“External CI/CD: Use tools such as GitHub Actions to pull the latest commits when a PR is merged into the deployment branch.”
↩︎ Exam trap 3“Create or use a service principal and configure a Git credential so it can access that repository.”
↩︎ Checkpoint“Scheduled job: If external CI/CD isn't available, run a scheduled job that updates the Git folder.”
↩︎ Prediction - 4.
“The following example GitHub Actions YAML file updates a workspace Git folder when a remote branch updates.”
↩︎ Keeping the production Git folder in sync - 5.https://docs.databricks.com/aws/en/dev-tools/ci-cdOfficial docs
“When a job run begins, Databricks takes a snapshot of the repository and runs all tasks against that version.”
↩︎ When a production Git folder is the right tool“Configurations for jobs or pipelines that run assets in the Git folder and configurations for publishing dashboards are not in source control.”
↩︎ Exam trap 1“Configurations for jobs or pipelines that run assets in the Git folder and configurations for publishing dashboards are not in source control.”
↩︎ Checkpoint