Courseiva
Design and implement build and release pipelineseasyMultiple ChoiceObjective-mapped

AZ-400 Practice Question: Design and implement build and release pipelines

Your organization uses Azure Repos for source control and Azure Pipelines for CI/CD. You need to implement a policy that ensures every commit to the main branch is built and passes all tests before it can be merged. The team uses feature branches for development. What is the most efficient way to enforce this?

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

Configure a branch policy on the main branch that requires a successful build from a pull request trigger.

Configuring a branch policy on the main branch that requires a successful build from a pull request trigger ensures that every commit to main must be built and pass tests before merging. This is the most efficient automated enforcement. Option A is incorrect because relying on manual builds does not enforce the policy automatically. Option B is incorrect because a pre-merge validation that does not block merging fails to prevent unvalidated commits. Option D is incorrect because a CI trigger on main runs after merge, not before, so it does not enforce pre-merge validation.

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 developers to manually run the pipeline before merging.

    Why it's wrong here

    A manual process depends on developer compliance and is not enforced by the server; nothing prevents a merge if the developer forgets to run the build, skips it, or runs it against a different commit than the one being merged.

  • Use a pre-merge validation pipeline that runs on pull requests but does not block merging.

    Why it's wrong here

    If the pre-merge validation pipeline runs on pull requests but is optional, Azure Repos displays the build results without blocking the merge button; a failing build can be ignored, so broken code can still be merged unless a required branch policy is configured.

  • Configure a branch policy on the main branch that requires a successful build from a pull request trigger.

    Why this is correct

    A build validation branch policy on main requires a pull request trigger build to complete successfully before merging; if the build fails or has not yet finished, the merge is blocked by server-side enforcement, providing a true quality gate.

  • Set up a CI trigger on the main branch to run the pipeline on every commit.

    Why it's wrong here

    A CI trigger on the main branch builds every commit after it is pushed or merged, but at that point the merge has already been accepted; it detects failures only after the code is in main, so it does not prevent a bad pull request from being merged.

About these practice questions

This AZ-400 question is part of Courseiva's 823-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

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.