AZ-400 Practice Question: Design and implement a source control strategy
Network Topology
Refer to the exhibit. A developer runs 'git log --oneline --graph --decorate' and sees the output. Which Git workflow does this history most closely represent?
⚠ Common exam trap
The trap here is that candidates see a graph with multiple branches and assume it represents GitHub Flow or trunk-based development, but the presence of both `develop` and `release` branches specifically indicates Git Flow, not simpler workflows.
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
✓
Git Flow
The output of `git log --oneline --graph --decorate` shows multiple long-lived branches (e.g., `develop`, `feature/*`, `release/*`, `hotfix/*`) with periodic merges back to `develop` and `main`. This branching structure with dedicated branches for features, releases, and hotfixes is the hallmark of Git Flow, which uses a strict branching model to manage releases and maintenance in parallel.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
GitLab Flow
Why it's wrong here
GitLab Flow uses environment branches such as production and staging, but it typically integrates feature branches via merge requests that can be rebased or squashed, avoiding the dense, non-linear merge-commit graph shown here. The exhibit's many simultaneous merge commits are more indicative of a branch-per-feature strategy that never linearizes history.
- ✗
Trunk-based development
Why it's wrong here
Trunk-based development encourages short-lived feature branches that are either rebased onto main before merging or merged directly via single commits, producing a strictly linear history. The exhibited history with multiple merge commits fanning out and converging violates that principle, so it cannot be trunk-based.
- ✗
GitHub Flow
Why it's wrong here
GitHub Flow uses feature branches off main and merges them via squash or rebase merges by default, which flattens each feature into a single commit and keeps the main branch history linear. The visible merge commits with branched topology contradict GitHub Flow's typical clean history, making it the wrong choice.
- ✓
Git Flow
Why this is correct
Git Flow explicitly uses feature branches cut from a development branch and merges them with `--no-ff` (no fast-forward) merge commits to preserve the feature branch context. This produces a non-linear history with multiple merge points and a visible branch structure, precisely matching the exhibit. That characteristic merge-commit topology is the definitive signature of Git Flow.
Visual reference
Go deeper
Related to this question
Learn chapter
Designing a Release Pipeline
Key term
Git
Git is a version control system that tracks changes to files so multiple people can work on the same project without overwriting each other's work.
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.
About these practice questions
One of 823 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.