Courseiva
Design and implement build and release pipelinesmediumMultiple ChoiceObjective-mapped

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

You maintain a classic release pipeline that deploys to multiple environments. You need to ensure that a deployment to the Production environment only proceeds after a manual approval from a specific group of users. Which feature should you configure?

⚠ Common exam trap

Watch out — candidates often confuse pre-deployment approvals with deployment gates, as both can pause a deployment, but gates are automated checks (e.g., monitoring metrics) while approvals require explicit human action from a designated group.

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

Pre-deployment approvals on the Production environment

Pre-deployment approvals are configured on an environment to require manual sign-off before a release is deployed to that environment. In a classic release pipeline, this ensures that the deployment to Production only proceeds after a specific group of users has approved it, meeting the requirement for manual approval before deployment.

Answer analysis

Option-by-option breakdown

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

  • Post-deployment approvals on the Production environment

    Why it's wrong here

    Post-deployment approvals are configured on an environment and take effect after the deployment has already completed, meaning they cannot intervene to prevent an unwanted deployment to Production. They are used for post-release sign-off, not for gating the deployment before it starts.

  • Deployment queue settings on the Production environment

    Why it's wrong here

    Deployment queue settings control how multiple release runs are queued and executed against an environment, such as serial or parallel execution, and they do not provide any manual sign-off step. They manage concurrency, not human approval, so they cannot satisfy the requirement to pause for approval before deploying.

  • Deployment gates on the Production environment

    Why it's wrong here

    Deployment gates are automated checks that evaluate conditions like monitoring metrics or work item completion prior to or after deployment, but they are not a manual approval mechanism. They can be used to automatically approve or reject based on data, but they do not insert a human approver into the pipeline before Production deployment.

  • Pre-deployment approvals on the Production environment

    Why this is correct

    Pre-deployment approvals are explicitly designed to pause the release pipeline before a deployment to an environment begins, requiring a designated approver to review and approve the release. For a Production environment, this ensures that a human sign-off is obtained before any code is deployed to Production.

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

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.