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

Answer analysis

Option-by-option breakdown

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

• ✓

  Delete branches after they are merged.

  Why this is correct

  Deleting feature branches immediately after their merge keeps the repository's branch list focused on active work and prevents stale refs from persisting indefinitely. Stale branches can drift from the latest main, causing confusion about which code is still in use and potentially leading to accidental reverts or conflicting fixes.

• ✗

  Allow force pushes to shared branches to clean up history.

  Why it's wrong here

  Force pushing to shared branches rewrites history that other team members have already based their own work on, which can invalidate their local clones and cause them to lose commits. This is especially dangerous when multiple developers are actively pushing, as it can silently discard work that was never merged, so corrections should use revert or a new commit instead.

• ✓

  Use short-lived feature branches that are merged within a day.

  Why this is correct

  Short-lived feature branches, typically merged within a day, minimize the amount of code that diverges from the mainline, which reduces the likelihood of costly merge conflicts and keeps integration risk low. This practice supports continuous integration by ensuring that changes are validated and merged frequently, before the branch can become stale or diverge significantly.

• ✗

  Keep feature branches alive for the entire sprint.

  Why it's wrong here

  Keeping a feature branch alive for an entire sprint allows it to drift far away from main, so when it is finally merged, the integration effort becomes a large, risky batch instead of a series of small, predictable steps. It also means that the team cannot see or validate the combined behavior of the new feature until late in the cycle, which undermines continuous integration and can lead to last-minute blocking problems.

• ✓

  Require build validation on pull requests to the main branch.

  Why this is correct

  Requiring build validation on pull requests to the main branch ensures that every proposed change compiles and passes automated tests before it can be merged, which prevents broken code from entering the shared mainline. In Azure DevOps, this is enforced via branch policies that automatically trigger a pipeline, and the merge is blocked until the build succeeds, keeping the main branch in a continuously deployable state.

Go deeper

Related to this question