Hi @DineshOjha,

Given your constraints (per‑application service principals, isolation at the volume/schema level, and not wanting to use /Workspace/Shared), the flow you described aligns with how Bundles are meant to be used in production. Bundles are the recommended CI/CD mechanism, and using service principals as run identities in non‑dev targets is explicitly encouraged.

A couple of clarifications and direct answers to your questions:

1. Do you think this is a good approach for notebook based implementation or do you suggest anything else?

Yes, this is a solid pattern for notebook‑based implementations... Git serves as the source of truth, with personal workspaces intended solely for development purposes. Bundles are responsible for deploying notebooks and job definitions into the workspace. In non-development targets, the run_as parameter is configured to use the per-application service principal, ensuring that all production runs utilise that principal’s permissions. This setup includes access to the appropriate volume/schema, which is critical for maintaining consistency and security throughout the deployment process.

The only design choice you still need is where in the workspace Bundles deploy to. You don’t have to use /Workspace/Shared. You can pick any isolated path, for example /Workspace/.bundle/prod/${bundle.name} or /Workspace/Projects/<app_name>/... and lock that path down so only the application service principal, a small operator group, and optionally CI/CD deployer principals have access. The path naming is up to you. Bundles just need a root_path per target, and you control the permissions there.

So I would keep your 4‑step approach and add a per‑app workspace root (instead of /Shared), with ACLs granting access only to the relevant SP and operators.

2. The service principal exists only in Databricks, so what email and PAT should be provided to enable GIT access? 

With the Bundles‑from‑Azure‑DevOps pattern you described, the important nuance is that your Databricks service principal does not need to talk directly to Git to make this work. In a typical Azure DevOps setup.. Azure DevOps pipelines clone the Git repo themselves using the identity configured in DevOps (service connection, PAT, or Microsoft Entra–backed principal). Once the code is on the build agent, the pipeline calls databricks bundle validate/deploy/run using the Databricks service principal to authenticate to Databricks, not to Git.

In that model, you do not need to configure a Git email/PAT on the Databricks SP at all. Git credentials live entirely in Azure DevOps (for checking out the repo).The Databricks SP is only used for workspace authentication (via OAuth M2M, workload identity federation, or an ARM service connection). You only need Git credentials on the Databricks SP if you also want it to use Git folders / Repos in the workspace, or run Git‑backed jobs directly from Databricks (using Git‑with‑jobs / Git folders).

In that case, the email/PAT would belong to a non‑human Azure DevOps identity (service principal or technical user) that has access to the repo. You then link those Git credentials to the Databricks SP via the Git integration tab in the workspace.

3. How will service principal get access to the Azure GIT repo (ADO repository)? 

In a two-layer setup, the first layer involves Azure DevOps and a Git repository. In this configuration, you create a service principal or technical user with at least Basic access and repository permissions in Azure DevOps. This identity is utilised for your pipelines to check out the code, and it is managed within Azure DevOps, not in Databricks.

The second layer connects Azure DevOps to Databricks through a Databricks service principal. To set this up, you configure an Azure DevOps service connection that authenticates to Databricks using methods such as OAuth M2M, Azure Resource Manager connection, or the recommended workload identity federation (which avoids long-lived secrets). Your pipeline steps will involve commands like `databricks bundle validate -t prod`, `databricks bundle deploy -t prod`, and `databricks bundle run -t prod <job_name>`, with the Databricks CLI already authenticated as the service principal.

For a Bundles-only flow, the Databricks service principal does not require direct Git access. It simply needs to support CLI/API calls from the pipeline. However, if you want the Databricks service principal to operate on Git folders within the workspace, you must grant the DevOps identity access to the repository (Basic + repo permissions) and link its Git credentials to your Databricks service principal under the settings for Git integration with Azure DevOps (using PAT or Entra-based authentication).

4. Is there any other access that the service principal needs for this approach, for bundles etc ?

For the exact permission model and how to wire this up, the official docs cover it in more detail..

• CI/CD on Azure Databricks (incl. Bundles + service principals)
• Service principals for CI/CD (what entitlements/permissions they need)
• Authorize a Microsoft Entra service principal to access Git folders (if you decide the SP should access Git folders directly)
• Authenticate with Azure DevOps on Azure Databricks (how the DevOps pipeline authenticates as the SP)
• Bundles run_as configuration (how to set the SP as the run identity in targets)

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.