Courseiva
Design and implement a source control strategyeasyMultiple ChoiceObjective-mapped

AZ-400 Practice Question: Design and implement a source control strategy

Your organization is adopting a trunk-based development strategy with short-lived feature branches. Which branch policy should you enforce to ensure that code is integrated frequently and conflicts are minimized?

⚠ Common exam trap

Test-takers frequently confuse trunk-based development with GitFlow and choose option C (release branches), or they mistakenly think fast-forward-only merges (option D) are required for trunk-based strategies, when in fact squash merges are the recommended approach to maintain a clean, linear history.

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

Require a minimum number of reviewers and enforce a squash merge strategy

In a trunk-based development strategy with short-lived feature branches, the goal is to integrate code frequently and minimize merge conflicts. Requiring a minimum number of reviewers ensures code quality and team awareness, while enforcing a squash merge strategy collapses all feature branch commits into a single commit on the main branch, keeping the history linear and clean. This approach reduces the risk of complex merge conflicts and supports continuous integration by encouraging small, frequent merges.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Allow direct pushes to main branch for senior developers

    Why it's wrong here

    Even senior developers can introduce regressions; bypassing branch protection removes the safety net of mandatory pull request reviews and CI validation, leading to unreviewed changes entering the shared trunk. This violates trunk-based development quality gates and increases integration risk.

  • Require a minimum number of reviewers and enforce a squash merge strategy

    Why this is correct

    Requiring a minimum number of reviewers ensures every change is verified before merging to main, while squash merging compresses the feature branch's commit history into a single linear commit on the trunk. This maintains a coherent, reversible history and avoids merge noise, making main always deployable.

  • Create release branches for each production deployment

    Why it's wrong here

    Trunk-based development emphasizes keeping main always deployable and using feature flags for release packaging; creating long-lived release branches duplicates fixes, often leads to merge conflicts and divergence, and is contrary to the single-source-of-truth model. This practice is more suited to GitFlow than trunk-based development.

  • Require all merges to be fast-forward only

    Why it's wrong here

    Enforcing fast-forward-only merges forces every integration to be strictly linear but prohibits merge commits and requires constant rebasing, which can disrupt in-flight work and create unnecessary overhead. Trunk-based development relies on short-lived branches and squash merges, not rigid linear histories, so this restriction is too brittle.

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 →

How Courseiva writes practice questions · Editorial policy

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.