Courseiva
Design and implement a source control strategyhardMultiple ChoiceObjective-mapped

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

You are designing a branching strategy for a microservices application with independent deployment cadences. The team wants to support continuous deployment to production from the main branch while allowing feature work to be isolated and tested. Which branching strategy best meets these requirements?

⚠ Common exam trap

It's easy for candidates to confuse GitHub Flow with trunk-based development, but GitHub Flow lacks the strict short-lived branch discipline and feature toggle support required for true continuous deployment from main in a microservices context.

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

Trunk-based development with short-lived feature branches

Trunk-based development with short-lived feature branches (C) is correct because it enables continuous deployment from the main branch while isolating feature work in branches that are merged back to main within hours or a day. This approach minimizes merge conflicts and supports independent deployment cadences for microservices, as each service can be deployed from main independently without waiting for release branches.

Answer analysis

Option-by-option breakdown

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

  • One branch per environment (dev, test, prod)

    Why it's wrong here

    This pattern conflates code promotion with environment configuration, so feature development is not isolated; all changes merge sequentially into a single environment branch, causing integration conflicts and making it impossible to selectively promote a feature without dragging along unrelated changes, which disrupts continuous delivery.

  • GitHub Flow with feature branches merging to main

    Why it's wrong here

    GitHub Flow allows feature branches of any duration, but without a strict requirement to merge to main frequently and delete branches immediately, it can lead to long-lived branches, integration conflicts, and delayed feedback, which undermines continuous integration and delivery for microservices.

  • Trunk-based development with short-lived feature branches

    Why this is correct

    Trunk-based development with short-lived feature branches (typically less than a day) ensures that all developers integrate into main frequently, which minimizes merge conflicts, enables continuous integration, and supports rapid, automated deployment of microservices while still isolating work in progress via feature branches that are merged and deleted quickly.

  • Git Flow with develop, release, and hotfix branches

    Why it's wrong here

    Git Flow's multiple long-lived branches (develop, release, hotfix) introduce process overhead and staging delays, making it unsuitable for microservices that require frequent, often independent, deployments; the release branch cycle slows down the delivery pipeline and creates additional merge complexity.

About these practice questions

This AZ-400 question is part of Courseiva's 823-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.