Databricks Certified Data Engineer - Professional

Get started today

Ultimate access to all questions.

Explanation:

Correct Answer: C

In Databricks Repos, if a specific remote branch (like dev-2.3.9) does not appear in the branch selection dropdown, it is usually because the local workspace clone has not yet fetched the latest metadata from the remote Git provider.

Why this works:

The Pull button in the Git dialog performs a fetch operation, retrieving all new branches and commits from the remote repository.
Once the fetch completes, the branch dropdown menu is automatically updated. The developer can then simply select (checkout) the dev-2.3.9 branch to inspect the code.
This method is the most efficient and follows Git best practices as it avoids unnecessary merges, API calls, or time-consuming re-cloning.

Analysis of incorrect options:

A: You cannot checkout a branch that hasn't been fetched to the workspace yet. Furthermore, Databricks Repos does not offer an 'auto-resolve' toggle during a checkout operation; conflict resolution occurs during merges or rebases.
B: Using the REST API and Pull Requests is over-engineered for simply viewing code and often requires additional tokens and permissions that a junior developer may not possess.
D: Merging potentially broken code into main just to see code on a feature branch risks polluting production and is unnecessary when a simple 'Pull' suffices.
E: This reverses the intent by pushing outdated logic into the target branch. The goal is to view the current logic, not to mutate the target branch.

Explanation:

Correct Answer: C

Why this works:

The Pull button in the Git dialog performs a fetch operation, retrieving all new branches and commits from the remote repository.
Once the fetch completes, the branch dropdown menu is automatically updated. The developer can then simply select (checkout) the dev-2.3.9 branch to inspect the code.
This method is the most efficient and follows Git best practices as it avoids unnecessary merges, API calls, or time-consuming re-cloning.

Analysis of incorrect options:

A: You cannot checkout a branch that hasn't been fetched to the workspace yet. Furthermore, Databricks Repos does not offer an 'auto-resolve' toggle during a checkout operation; conflict resolution occurs during merges or rebases.
B: Using the REST API and Pull Requests is over-engineered for simply viewing code and often requires additional tokens and permissions that a junior developer may not possess.
D: Merging potentially broken code into main just to see code on a feature branch risks polluting production and is unnecessary when a simple 'Pull' suffices.
E: This reverses the intent by pushing outdated logic into the target branch. The goal is to view the current logic, not to mutate the target branch.

Comments (0)

No comments yet.

A junior developer is experiencing unexpected results in a Databricks Repos notebook. Upon investigation, they realize they are working on a personal branch with outdated code. They need to switch to the `dev-2.3.9` branch to review the correct logic, but this branch is currently missing from the branch selection menu.

What is the most direct and lowest-risk way for the developer to access the code on the `dev-2.3.9` branch?

Real Exam

Last updated: January 6, 2026 at 15:41

Select the option to checkout the dev-2.3.9 branch via the Repos UI and use the 'auto-resolve conflicts' toggle to handle discrepancies with the current branch.

0.0%

Initiate a pull request through the Repos interface and execute a Databricks REST API call to force the workspace branch to dev-2.3.9.

10.0%

Use the 'Pull' button in the Repos Git dialog to fetch latest updates from the remote repository, then select dev-2.3.9 from the refreshed branch dropdown.