AZ-400 Question 4
Single answerYour team is building a new cloud-native microservices application and wants to implement a simple, collaborative workflow using GitHub Flow. The team requires that each new feature or bug fix be developed and tested in isolation, with code reviews performed before merging changes into the main branch. Which approach best satisfies these requirements?
- A
Allow all developers to commit directly into the main branch after local testing.
- B
Create a short-lived branch for each feature or fix, push changes, open a pull request, and only merge it into the main branch after reviews pass and automated checks succeed.
- C
Use separate branches for each environment (development, test, production) to isolate changes until they are deemed ready for production.
- D
Adopt a single shared developer branch that merges into the main branch monthly to reduce merge conflicts.
Show answer and explanation
Correct answer: B
Explanation
GitHub Flow emphasizes a lightweight branching model with each change developed on a dedicated short-lived branch. Pull requests, reviews, and automated tests help ensure quality before merging into the main branch, supporting continuous integration and frequent deployments. This model is documented in GitHub's own workflow best practices: https://docs.github.com/en/get-started/quickstart/github-flow.
- A. Incorrect.
Option 1 is incorrect because allowing developers to commit directly into main bypasses formal code reviews and can introduce broken changes without adequate checks.
- B. Correct.
Option 2 is correct. This is the classic GitHub Flow approach: each feature or fix is worked on in its own branch, then merged back into main through a pull request once it passes review and testing.
- C. Incorrect.
Option 3 is incorrect because juggling multiple long-lived environment branches is more aligned with GitFlow or release flow patterns, not simple GitHub Flow. GitHub Flow typically relies on a single main branch for deployment and uses short-lived branches for changes.
- D. Incorrect.
Option 4 is incorrect because merging changes only once a month can block early feedback and continuous integration. It delays finding defects and complicates merges.