AZ-400 Practice Question: Design and implement a source control strategy
Your company is a startup developing a mobile application with a small team of 5 developers. You use GitHub Free and want to implement a simple but effective branching strategy that supports continuous delivery. The team wants to release new features every week and be able to hotfix critical bugs quickly. They currently have a main branch and feature branches, but sometimes features are merged to main before they are fully tested, causing issues. You need to recommend a strategy that minimizes risk while keeping the process lightweight. The team does not want to use long-lived branches. What should you recommend?
⚠ Common exam trap
The trap here is that candidates often overcomplicate branching strategies for small teams, mistakenly choosing GitFlow (Option D) or release branches (Option A) when GitHub Flow's simplicity and built-in CI/review gates perfectly address the need for risk mitigation without long-lived branches.
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
✓
Use GitHub Flow: developers create feature branches from main, open pull requests with required CI and at least one review, then merge to main. Hotfixes follow the same process.
GitHub Flow is the simplest and most effective strategy for a small team using GitHub Free that wants continuous delivery without long-lived branches. By requiring feature branches, pull requests with CI checks, and at least one review before merging to main, it ensures that all code is tested and reviewed before integration, preventing untested features from breaking main. Hotfixes follow the same lightweight process, allowing quick, safe patches without additional branch overhead.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use a single main branch and create release branches for each weekly release; features are merged to release branches, then release branches are merged to main after testing.
Why it's wrong here
This model introduces release branches as an extra integration layer, but for a startup with weekly releases the added merge/back-merge overhead and branch management burden outweigh any benefit; it also delays feature integration on main, making CI feedback and hotfix delivery slower.
- ✓
Use GitHub Flow: developers create feature branches from main, open pull requests with required CI and at least one review, then merge to main. Hotfixes follow the same process.
Why this is correct
GitHub Flow is a lightweight, trunk-based model where main is always releasable: short-lived feature branches, mandatory CI and pull-request reviews enforce quality before integration, and hotfixes follow the identical pull-request path so fixes reach production quickly without long-lived branches or complex release processes.
- ✗
Allow developers to commit directly to main but require all commits to pass CI and be reviewed by at least one other developer after the fact.
Why it's wrong here
Direct commits to main bypass gatekeeping at integration time; even if CI passes and a post-commit review occurs, broken or unreviewed code can already affect all developers and trigger releases, and post-hoc review is less effective than requiring an approved pull request before the change enters the shared branch.
- ✗
Adopt GitFlow with develop and release branches.
Why it's wrong here
GitFlow's long-lived develop and release branches add ceremony, frequent merges/back-merges, and release coordination that a small startup with a mobile app does not need; it slows CI feedback and makes hotfixes more complex, whereas a simpler trunk-based flow is faster and safer for weekly releases.
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
Continuous delivery
Continuous delivery is a software engineering practice where code changes are automatically built, tested, and prepared for a release to production, with every change being deployable at the push of a button.
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.