AZ-400 Configure processes and communications Practice Question
Your team follows trunk-based development. The main branch should always be deployable. Which two practices must you implement? (Choose two.)
⚠ Common exam trap
Many exam-takers confuse trunk-based development with GitFlow or other branching strategies, leading them to select release branches (D) or long-lived feature branches (E) as valid practices, when in fact trunk-based development explicitly avoids these in favor of short-lived branches and feature flags.
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 feature flags to manage incomplete work.
In trunk-based development, the main branch must always be deployable. Feature flags (B) allow incomplete or work-in-progress code to be merged into the main branch without affecting production behavior, because the new functionality is toggled off until ready. Keeping branches short-lived (C) (typically less than a day) minimizes merge conflicts and ensures that changes are integrated quickly, reducing the risk of long-lived divergence that could break the main branch.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Require manual approval for every pull request.
Why it's wrong here
Requiring manual approval for every pull request adds unnecessary human gatekeeping to all changes, increasing lead time and contradicting the automated continuous integration/continuous delivery (CI/CD) practices that trunk-based development depends on. Manual approval should be reserved for high-risk or compliance-sensitive changes, not every merge to main.
- ✓
Use feature flags to manage incomplete work.
Why this is correct
Feature flags (also called toggles) let teams merge incomplete or experimental code into main behind a runtime switch, decoupling deployment from feature release and enabling continuous integration. This keeps main always in a releasable state while incomplete work remains safely hidden from users until the flag is turned on.
- ✓
Keep branches short-lived (less than a day).
Why this is correct
Keeping branches short-lived, ideally less than a day, minimizes divergence between a developer's work and main, reducing merge conflicts and ensuring changes are integrated incrementally multiple times per day. This aligns with trunk-based development's core practice of frequently merging small, verified updates directly to main rather than letting branches drift for extended periods.
- ✗
Create release branches for each deployment.
Why it's wrong here
Creating release branches for each deployment is a git-flow practice that promotes long-lived parallel branches, fragments the codebase, and delays integration back to main; trunk-based development instead deploys directly from main using automated build and release gates. Each new release branch reintroduces the merge, hotfix, and backport overhead that trunk-based development is designed to eliminate.
- ✗
Use long-lived feature branches for each feature.
Why it's wrong here
Long-lived feature branches isolate work for days or weeks, causing the branch to diverge significantly from main, creating complex merge conflicts, and postponing integration until the feature is 'complete'. This directly violates trunk-based development's principle that all developers share the same main branch and integrate small changes continuously to get early feedback.
Go deeper
Related to this question
Learn chapter
Managing Infrastructure as Code Using Azure
Key term
Branch
A branch is a pointer to a specific commit in a version control system that allows you to work on features or fixes in isolation from the main codebase.
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.