Courseiva
Design and implement build and release pipelinesmediumMultiple ChoiceObjective-mapped

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

You are configuring a release pipeline that deploys to multiple environments. You want to automate the deployment to the staging environment only if the build succeeds, and then require manual approval before deploying to production. Which strategy should you use?

⚠ Common exam trap

It's easy for candidates to confuse deployment gates (which are automated checks) with manual approvals, leading them to incorrectly select Option B, even though gates cannot provide the required manual intervention step.

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

Define an environment with approvals required for the production stage.

Azure Pipelines allows you to define environments with explicit approval checks. By adding a manual approval gate on the production environment stage, the pipeline will automatically deploy to staging after a successful build, but pause before production until an authorized user approves the release. This directly meets the requirement for automated staging deployment and manual production approval.

Answer analysis

Option-by-option breakdown

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

  • Define an environment with approvals required for the production stage.

    Why this is correct

    Defining an environment and enabling the approval check on its production stage is the correct way to require a manual sign-off before deployment. This approval is configured on the environment itself and naturally integrates with multi-stage YAML pipelines, ensuring that only authorized users can deploy to production.

  • Use deployment gates in the production stage to check for manual intervention.

    Why it's wrong here

    Deployment gates are automated conditions that evaluate health signals such as work items, Azure Monitor metrics, or query results before or after a deployment. They cannot perform a manual sign-off; a human approval requires a dedicated approval step on the environment, so using a gate for manual intervention is incorrect.

  • Use a classic release pipeline with pre-deployment approvals.

    Why it's wrong here

    Classic release pipelines do offer pre-deployment approvals and are a viable alternative, but they are being deprecated in favor of YAML-based pipelines. Azure DevOps guidance recommends defining environments with approvals in multi-stage YAML pipelines, making this legacy approach incorrect for a modern deployment pipeline.

  • Configure a branch policy on the main branch to require approval for pull requests.

    Why it's wrong here

    Branch policies on the main branch control source-code gates like required reviewers and build validation for pull requests, not deployment approvals. They do not interact with release stages, so they cannot provide a manual approval before a production deployment.

Visual reference

Client DHCP Server 1 Discover (broadcast) 2 Offer (IP: 192.168.1.10) 3 Request (I accept) 4 Acknowledge (lease confirmed) DORA — the four-step DHCP lease process

About these practice questions

Courseiva writes every AZ-400 question from scratch — 823 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.