AZ-400 Practice Question: Design and implement a source control strategy
Your team uses Git for source control. You want to maintain a clean commit history on the main branch by avoiding merge commits. Which TWO merge strategies in a pull request achieve this?
⚠ Common exam trap
Test-takers frequently confuse 'fast-forward merge' with a clean history strategy, but fast-forward merges only avoid merge commits when the branches haven't diverged; they do not rewrite or consolidate commits, so they fail to maintain a clean history in the general case.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Rebase merge
A rebase merge (option A) rewrites the commit history of the feature branch onto the tip of the target branch, creating a linear sequence of commits without any merge commits. This maintains a clean, linear history on the main branch. A squash merge (option C) combines all commits from the feature branch into a single new commit on the target branch, also avoiding merge commits and keeping the history clean.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Rebase merge
Why this is correct
Rebase merge is the correct choice when you want linear history: it takes each commit from the source branch and applies it onto the latest target branch tip, creating a straight-line history with no merge commit while preserving individual commits.
- ✗
Merge commit
Why it's wrong here
Merge commit is wrong because completing a pull request with a merge commit creates a two-parent merge commit and retains the divergent branch structure, producing non-linear history that defeats the goal of maintaining a clean, straight-line commit sequence.
- ✓
Squash merge
Why this is correct
Squash merge can also avoid a merge commit, but it isn't correct if you want to preserve the individual commits: it collapses all source-branch changes into a single new commit on the target branch, losing per-commit history and granular traceability.
- ✗
Three-way merge
Why it's wrong here
Three-way merge is wrong because it is a merge algorithm—used internally by Git to combine two branch tips using a common ancestor—not a selectable pull request completion option in Azure DevOps, so it cannot be chosen to maintain a specific commit history.
- ✗
Fast-forward merge
Why it's wrong here
Fast-forward merge is wrong: while it can move the target branch pointer forward with no merge commit when the source is strictly ahead, it is not a PR completion option in Azure DevOps and, once branches have diverged, it would require a merge commit, breaking linearity.
Go deeper
Related to this question
Learn chapter
Source Control Strategy Design
Key term
Feature
A feature is a distinct unit of functionality that delivers value to the user, often managed and tracked throughout the software development lifecycle.
Key term
Pull request
A pull request is a way for a developer to propose changes to a codebase and ask other team members to review and merge them into the main project.
About these practice questions
Courseiva writes every AZ-400 question from scratch — 823 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.