Courseiva
Design and implement build and release pipelinesmediumMultiple ChoiceObjective-mapped

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

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a policy that requires all pull requests to be built and pass tests before merging. What should you do?

⚠ Common exam trap

Candidates often confuse pipeline triggers (which only initiate runs) with merge gating (which enforces that those runs must succeed before merging), leading candidates to select option B instead of A.

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

Add a branch protection rule in the GitHub repository requiring status checks.

GitHub branch protection rules allow you to require status checks to pass before merging a pull request. By configuring a rule that requires the Azure Pipelines build and test status check to succeed, you enforce that all pull requests are validated before they can be merged into the protected 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.

  • Add a branch protection rule in the GitHub repository requiring status checks.

    Why this is correct

    Branch protection rules in GitHub allow requiring status checks to pass before a pull request can be merged. When you require status checks, the pipeline's validation becomes a mandatory gate: any PR that doesn't have a successful status check from the configured pipeline is blocked from merging, directly enforcing the quality gate at the repository level. This is the only option that enforces the requirement at the merge point.

  • Set the pipeline trigger to run on pull request.

    Why it's wrong here

    Setting the pipeline trigger to run on pull request only ensures that the pipeline executes when a PR is opened or updated, but it does not prevent a PR from being merged if the pipeline fails or hasn't run. The trigger merely kicks off the build; it does not enforce any merge policy. Therefore, this alone cannot guarantee that changes are validated before merging.

  • Configure pipeline permissions to require approval.

    Why it's wrong here

    Pipeline permissions control who can view, edit, or run pipelines, not whether a pull request can be merged. Requiring approval on pipeline permissions would restrict who can modify pipeline definitions, but it has no bearing on the merge process. Thus, it doesn't enforce a validation gate for PRs.

  • Add a pre-deployment check on the environment.

    Why it's wrong here

    Pre-deployment checks on an environment are used in release pipelines to gate deployments to a specific environment (like production) based on approvals or checks. They do not apply to pull requests or the merge process in GitHub. Since the requirement is about validating changes before merging code, environment checks are irrelevant.

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 →

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.