AZ-400 - Design and Implement a Source Control Strategy (13% of the exam) - Section 2.1

Design a branching strategy for source code, including trunk-based, feature branch, and release branch models.

Compare trunk-based development, feature branching, and release branch models, and understand the trade-offs each makes between integration frequency, stability, and parallel delivery. Choose a Git workflow and merge strategy that fits the team's release cadence and risk tolerance.

trunk-based developmentfeature branchingrelease branchesGit workflowmerge strategy

Practice question for this objective

Free sampleDesign and Implement a Source Control Strategymedium

A team currently uses GitFlow with develop, feature, release, and hotfix branches, but its delivery goal is continuous delivery with small, frequent production releases. They find that work sits on the develop branch for weeks and that release branches cause painful late integration. Which change to the branching model most directly supports their continuous delivery goal?

AKeep GitFlow but shorten each release branch lifetime to a single day, merging release branches into both develop and main as soon as the nightly stabilisation build passes.
BReplace the central repository with a forking workflow so each developer integrates on their own fork first, reducing churn on the shared develop branch before promotion.
CMove to trunk-based development with short-lived branches merged to main daily, releasing directly from main and using feature flags to hide work that is not yet ready. Correct
DAdopt a release branch per environment, promoting commits through dev, test, and production branches in sequence so each environment has its own stable long-lived line.

Shift from GitFlow to trunk-based development with feature flags to enable small, frequent continuous delivery releases. Continuous delivery depends on short integration cycles, which GitFlow undermines through a long-lived develop branch and late-merging release branches. Trunk-based development collapses work onto one frequently integrated line and uses feature flags to keep unfinished code inert, so releases become small, frequent, and free of late integration shocks.

Why A is wrong: Compressing GitFlow timings is tempting, but the develop branch and dual-merge ceremony remain, so late integration and weeks-long develop divergence are only partly reduced, not removed.

Why B is wrong: A forking workflow adds cross-fork integration steps for an internal team and does nothing to shorten the long-lived develop branch, so it works against frequent shared releases.

Why C is correct: Trunk-based development with short branches and feature flags removes the long-lived develop and release branches, enabling the small, frequent, low-integration-pain releases continuous delivery requires.

Why D is wrong: Per-environment long-lived branches multiply the very long-lived branches causing late integration pain, so this increases divergence rather than enabling continuous delivery.

See more AZ-400 practice questions, answers explained.

Exam traps in Design and Implement a Source Control Strategy

Answers that look right on this material and are not. Each one is a distractor from a different question in the AZ-400 bank for this domain.

A release branch model, where each version gets a dedicated long-lived branch that stabilises independently of the main line before any code is shipped to customers.
Why it is wrong: Release branches suit stabilising a specific version in parallel with ongoing work, but their long-lived nature is the opposite of the frequent small integrations the team wants, so it does not fit.
Keep the work on a long-lived feature branch for the full three weeks and merge it to main only once the feature is entirely complete and ready to expose to users.
Why it is wrong: A three-week feature branch abandons continuous integration to main and reintroduces the merge debt trunk-based development avoids, so it conflicts with the stated way of working.
Merge the latest main into the feature branch, resolve any conflicts in the resulting merge commit, and open the pull request once the merge commit is in place on the feature branch.
Why it is wrong: Merging main into the feature branch does bring it current, but it records a merge commit on the feature branch, which is exactly the extra commit the team wants to avoid for a clean linear history.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.