DP-750: Databricks Asset Bundles, Git, and ALM Explained and with Real Exam Questions

When preparing for DP-750: Microsoft Certified: Azure Databricks Data Engineer Associate, you need to understand how Azure Databricks projects are deployed and managed across environments.

This article focuses on:

• Declarative Automation Bundles, also known in many exam-style questions as Databricks Asset Bundles
• databricks.yml
• bundle targets
• Databricks CLI deployment
• Git folders
• Git merge
• merge conflicts
• application lifecycle management, ALM

The related questions in your DP-750 question bank are Q12, Q62, Q66, Q67, Q73, Q80, and Q81.

---

1. Why ALM matters in Azure Databricks

In real data engineering projects, you do not want to manually copy notebooks, jobs, pipelines, and configuration from development to production.

You need a repeatable process for:

• source control
• deployment
• environment-specific configuration
• promotion from development to production
• CI/CD automation
• rollback
• team collaboration

This is called application lifecycle management, or ALM.

For DP-750, the common ALM pattern is:

Use Git for source control.
Use Declarative Automation Bundles for deployable Databricks resources.
Use Databricks CLI to validate, deploy, and run bundles.
Use targets to parameterize environments such as dev, test, and prod.

Microsoft documentation describes Declarative Automation Bundles as the recommended approach to CI/CD on Databricks. Bundles describe resources such as jobs and pipelines as source files, can be source controlled, and can be deployed through external CI/CD automation.

---

2. What are Declarative Automation Bundles?

Declarative Automation Bundles are a way to define a Databricks project as files.

They were formerly known as Databricks Asset Bundles, and many exam questions still use the older name.

A bundle can include:

• jobs
• pipelines
• apps
• notebooks
• Python files
• SQL files
• configuration
• environment-specific targets

A bundle is usually defined with a YAML file named:

databricks.yml

Microsoft documentation says bundle metadata is defined using YAML files that specify the artifacts, resources, and configuration of a Databricks project. The Databricks CLI can then validate, deploy, and run bundles using these YAML files.

For DP-750, remember:

Declarative Automation Bundles = repeatable deployment of Databricks resources

---

3. Why use bundles instead of manual workspace export/import?

Manual export and import can work for simple cases, but it is not a strong ALM process.

It is weak because:

• it is manual
• it is hard to repeat consistently
• environment parameters are difficult to manage
• promotion between dev/test/prod is error-prone
• source control is weaker
• CI/CD integration is harder

Bundles are better because the project is defined as code.

For example, a bundle can define:

Job A
Job B
Pipeline C
App D
dev target
prod target

Then the same project can be deployed repeatedly.

For DP-750, if the requirement says:

Deploy notebooks, workflows, and jobs in a consistent and repeatable way.
Parameterize the target deployment environment.
Provide source control.

the answer should point to:

Declarative Automation Bundles in Git

---

4. databricks.yml

The main configuration file for a bundle is usually:

databricks.yml

A very small example looks like this:

bundle:
  name: my_bundle

targets:
  dev:
    default: true

Microsoft documentation says the simplest databricks.yml defines the bundle name and a target deployment.

In real projects, databricks.yml often contains:

bundle:
  name: dp750_project

resources:
  jobs:
    ingestion_job:
      name: ingestion_job
      tasks:
        - task_key: ingest
          notebook_task:
            notebook_path: ./src/ingest.py

targets:
  dev:
    default: true
    workspace:
      host: https://adb-dev.azuredatabricks.net

  prod:
    mode: production
    workspace:
      host: https://adb-prod.azuredatabricks.net

For DP-750, you usually do not need to memorize every YAML property. You need to know what each major node is for.

---

5. Important bundle nodes

The most important nodes for DP-750 are:

|Node|Purpose| |---|---| |bundle|Defines bundle metadata, such as the bundle name| |resources|Defines deployable resources, such as jobs, pipelines, and apps| |targets|Defines deployment environments such as dev and prod| |variables|Defines reusable parameters| |workspace|Defines target workspace settings| |artifacts|Defines build artifacts such as Python packages|

For exam questions, the most important one is usually:

targets

---

6. What are targets?

A target is an environment-specific deployment configuration.

Common examples:

dev
test
prod

Targets let you deploy the same bundle to different environments with different settings.

For example:

targets:
  dev:
    default: true
    workspace:
      host: https://adb-dev.azuredatabricks.net

  prod:
    mode: production
    workspace:
      host: https://adb-prod.azuredatabricks.net

Microsoft documentation explains that target workspaces are defined in the targets mapping of the bundle’s databricks.yml.

For DP-750:

Deploy same bundle to dev and prod = use targets

---

7. Targets for selective deployment

Some exam questions ask something like:

You have two jobs and an app.
You need to deploy the app to both environments.
You need to deploy only one job to development.
Minimize administrative effort.

This points to target-specific configuration.

The answer is:

Use a targets node in databricks.yml.

Why?

Because targets lets you define different deployment behavior for different environments.

A simplified example:

resources:
  jobs:
    job_a:
      name: job_a

    job_b:
      name: job_b

  apps:
    my_app:
      name: my_app

targets:
  dev:
    resources:
      jobs:
        job_a:
          name: job_a_dev

  prod:
    resources:
      jobs:
        job_a:
          name: job_a_prod
        job_b:
          name: job_b_prod
      apps:
        my_app:
          name: my_app_prod

The exact syntax depends on the project, but the concept is:

targets control environment-specific deployment behavior.

---

8. Databricks CLI and bundles

The Databricks CLI is the standard tool used to work with bundles.

Common commands include:

databricks bundle validate

databricks bundle deploy --target dev

databricks bundle run <job-name> --target dev

Microsoft documentation says you use Databricks CLI bundle commands to create, validate, deploy, run, and destroy bundles.

For DP-750:

Deploy Declarative Automation Bundles = Databricks CLI

not:

Jobs UI
Git folders only
Databricks SDK for Python
Azure CLI

Those tools may be useful in other scenarios, but the standard bundle deployment tool is the Databricks CLI.

---

9. databricks bundle deploy --target dev

One common exam question asks how to complete the command for deploying a bundle to the dev environment.

The correct command is:

databricks bundle deploy --target dev

The Databricks CLI bundle command documentation says that to deploy a bundle to a specific target, you can use the -t or --target option.

For DP-750:

|Requirement|Command| |---|---| |Deploy bundle to dev|databricks bundle deploy --target dev| |Validate bundle|databricks bundle validate| |Run bundle workflow|databricks bundle run|

---

10. Git folders in Azure Databricks

Azure Databricks Git folders integrate notebooks and source files with Git repositories.

They allow teams to:

• clone repositories
• create branches
• commit changes
• push changes
• pull changes
• merge branches
• resolve conflicts

Microsoft documentation describes Git folders as supporting repository cloning, branch management, commits, merge conflict resolution, and Git CLI commands.

For DP-750, Git folders are often tested through basic Git operations:

• merge
• pull
• push
• rebase
• conflict resolution

---

11. Merge vs rebase vs pull vs push

A common DP-750 question asks:

From the main branch, you create Branch1 and commit changes to Branch1.
You need to incorporate the changes from Branch1 into main.
The solution must preserve commit history.
Which Git operation should you use?

The correct answer is:

merge

Microsoft documentation says the merge function in Azure Databricks Git folders uses git merge to combine the commit history from one branch into another. It also recommends merge instead of rebase for Git beginners because merge does not rewrite commit history.

For DP-750:

|Git operation|Meaning| |---|---| |merge|Combine changes from one branch into another while preserving history| |rebase|Replay commits on top of another branch; can rewrite history| |pull|Fetch and integrate remote changes into current branch| |push|Send local commits to remote repository|

If the question says:

preserve commit history

choose:

merge

---

12. Merge conflicts

A merge conflict happens when Git cannot automatically combine changes.

For example:

• You changed Notebook1 in Branch1.
• Another user changed the same part of Notebook1 in main.
• You try to merge Branch1 into main.
• Git cannot decide which version to keep.

In this case, you must resolve the conflict manually.

Databricks documentation says that to manually resolve conflicts, you edit the file contents, select the lines you want to preserve, remove merge conflict markers, and mark the conflict as resolved.

For DP-750, the best answer pattern is:

Apply the main branch changes to Branch1 and resolve the conflicts.

This lets you include all changes from both branches before merging.

---

13. Why not clone a new repository?

Some wrong answers suggest cloning the main branch or feature branch as a new repository.

That does not solve the merge conflict.

A conflict is about combining changes in the same repository history.

Creating a new clone may give you another working copy, but it does not automatically integrate both sets of changes into main.

For DP-750:

Merge conflict = resolve conflict

not:

clone a new repository

---

14. Git folders vs Declarative Automation Bundles

Git folders and bundles are related, but they are not the same.

|Feature|Purpose| |---|---| |Git folders|Source control and collaboration| |Declarative Automation Bundles|Define and deploy Databricks resources| |Databricks CLI|Execute bundle commands such as validate/deploy/run| |Targets|Environment-specific deployment configuration|

A strong production ALM pattern usually combines them:

Code and bundle files stored in Git.
Bundle defines jobs, pipelines, apps, and configuration.
Databricks CLI deploys the bundle to dev/test/prod.
CI/CD system automates the deployment.

For DP-750:

Git alone is not enough for repeatable environment deployment.
Bundles alone without Git are weaker for source control.
Bundles in Git is the best ALM pattern.

---

15. Declarative Automation Bundles vs Terraform

Terraform can manage Databricks resources, and it can be useful for infrastructure-as-code scenarios.

However, DP-750 questions about notebooks, workflows, jobs, target environment parameterization, and repeatable project deployment often expect:

Declarative Automation Bundles in Git

This is because bundles are specifically designed for Databricks project deployment and CI/CD.

For DP-750:

|Requirement|Best answer pattern| |---|---| |Deploy notebooks, workflows, and jobs as a project|Declarative Automation Bundles| |Source control project files|Git| |Parameterize target environment|Bundle targets| |Deploy bundle|Databricks CLI| |Manage lower-level cloud infrastructure|Terraform may be relevant, but not usually the DP-750 bundle answer|

---

16. DP-750 decision table for bundles, Git, and ALM

|Scenario in the question|Best answer pattern| |---|---| |Repeatable deployment of notebooks, workflows, and jobs|Declarative Automation Bundles| |Source control for Databricks project|Git| |Parameterize dev/test/prod|targets in databricks.yml| |Deploy bundle to dev|databricks bundle deploy --target dev| |Tool used to deploy bundles|Databricks CLI| |Bundle contains two jobs and an app with environment-specific deployment|targets node| |Preserve commit history when combining branches|Merge| |Merge fails because of conflicts|Apply main changes to branch and resolve conflicts| |Clone new repository to solve conflict|Wrong| |Manual workspace export/import for ALM|Weak / not preferred|

---

Real Exam Questions

Question 12

You have an Azure Databricks solution that was developed by multiple engineers and deployed to development, test, and production environments.

You need to implement an application lifecycle management, ALM, process that meets the following requirements:

• Deploys and provides source control for Databricks notebooks, workflows, and jobs in a consistent and repeatable way.

• Parameterizes the target deployment environment.

What should you include in the solution?

A. the export and import of Databricks workspaces

B. Databricks resources managed by using the Databricks Terraform provider

C. Git folders and manual promotion

D. Declarative Automation Bundles in Git ✅ Correct Answer

---

Question 62

You use Databricks Asset Bundles to manage two jobs and an app.

You need to deploy the bundle to development and production environments.

The solution must meet the following requirements:

• Deploy the app to both environments.

• Deploy only one job to development.

• Minimize administrative effort.

What should you use?

A. separate databricks.yml files for each environment

B. a variables node in a databricks.yml file

C. a resources node in a databricks.yml file

D. a targets node in a databricks.yml file ✅ Correct Answer

---

Question 66

You have an Azure Databricks workspace that contains a Git folder and uses an Azure Repos Git repository.

From the main branch, you create a branch named Branch1 and commit changes to Branch1.

You need to incorporate the changes from Branch1 into main. The solution must preserve the commit history in the repository.

Which Git operation should you use?

A. rebase

B. pull

C. merge ✅ Correct Answer

D. push

---

Question 67

You have an Azure Databricks workspace named Workspace1 that uses a Git repository. The repository contains a Databricks notebook named Notebook1.

From the main branch, you create a feature branch named Branch1 and commit changes to Notebook1. Another user commits changes to Notebook1 in main.

When you attempt to merge Branch1 into main, the merge fails due to conflicts.

You need to merge Branch1 into the main branch. The solution must ensure that Notebook1 includes all the changes from both the branches.

What should you do?

A. From Workspace1, clone the main branch as a new repository.

B. Apply the main branch changes to Branch1 and resolve the conflicts. ✅ Correct Answer

C. From Workspace1, clone Branch1 as a new repository.

D. Apply the changes directly to the main branch.

---

Question 73

You need to deploy Databricks Asset Bundles to a development environment. The solution must support automated and repeatable deployments across environments.

What should you use?

A. Git folders

B. the Databricks CLI ✅ Correct Answer

C. the Databricks SDK for Python

D. the Jobs UI

---

Question 80

You have a Declarative Automation Bundle.

You plan to use the Databricks CLI to deploy the bundle to an environment named dev.

How should you complete the CLI command?

|Area|Answer| |---|---| |Dropdown 1|databricks bundle ✅ Correct Answer| |Dropdown 2|deploy --target dev ✅ Correct Answer|

Completed command:

databricks bundle deploy --target dev

---

Question 81

You need to deploy Declarative Automation Bundles to a development environment. The solution must support automated and repeatable deployments across environments.

What should you use?

A. the Databricks CLI ✅ Correct Answer

B. Git folders

C. the Azure Developer CLI, azd

D. the Azure Command-Line Interface, CLI

---

Key takeaways

For DP-750, Databricks Asset Bundles, Git, and ALM questions usually test whether you know how to deploy Databricks projects repeatably across environments.

Remember these patterns:

• Declarative Automation Bundles are the modern Databricks project deployment mechanism.

• Many exam questions still call them Databricks Asset Bundles.

• Bundle configuration is usually stored in databricks.yml.

• resources define deployable objects such as jobs, pipelines, and apps.

• targets define environment-specific deployment settings.

• The Databricks CLI is used to validate, deploy, and run bundles.

• To deploy to dev, use databricks bundle deploy --target dev.

• Git folders provide source control and collaboration.

• Use merge to incorporate one branch into another while preserving commit history.

• If a merge conflict happens, apply the latest main branch changes to the feature branch and resolve the conflict.

• Git folders alone are not the same as a full ALM deployment strategy.

• Bundles in Git provide source-controlled, repeatable, environment-aware Databricks deployment.

If you can separate source control, deployment configuration, environment targets, and Git branch operations, these DP-750 ALM questions become much easier.