AZ-400 Practice Question: Design and implement build and release pipelines
Which TWO conditions should you configure in a release pipeline to ensure that a deployment to production only happens when both the staging deployment succeeded and a manual approval is granted? (Choose two.)
⚠ Common exam trap
Deployment queue settings do not define stage dependencies; they only control how deployments of the same stage are queued. Stage dependencies are defined via triggers (e.g., 'After stage') or through gates that check external conditions.
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 pre-deployment approval on the production stage.
To ensure release to production only after staging success and manual approval, you need a pre-deployment approval on the production stage (B) for the manual approval, and a pre-deployment gate on production that checks that the staging deployment succeeded (E). A gate is a valid condition that verifies the required state before deployment. Option D, the deployment queue setting 'After previous deployment', only controls concurrency of the same stage and does not create a dependency on the staging stage, so it does not ensure staging succeeded.
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 post-deployment approval on the staging stage.
Why it's wrong here
A post-deployment approval on the staging stage runs after the staging deployment has already happened, allowing manual sign-off on that environment. However, it does not define a trigger or gate for the production stage, so production could still be started independently (e.g., via a release trigger or a manual deployment) without waiting for that approval, meaning it fails to enforce the intended order.
- ✓
Add a pre-deployment approval on the production stage.
Why this is correct
A pre-deployment approval on the production stage forces a designated user or group to explicitly approve the release before any production deployment is attempted. This acts as a manual gate that, because the production stage only triggers after staging completes, ensures production is deployed only after staging has succeeded and been reviewed.
- ✗
Set the trigger to 'After release' and filter by artifact.
Why it's wrong here
Setting the trigger to 'After release' and applying an artifact filter causes the production stage to start immediately when a release is created, potentially even before the staging stage begins. The artifact filter only limits which artifacts initiate the release; it does not make production wait for staging's outcome, so this option does not enforce the required deployment order.
- ✗
Set the deployment queue setting to 'After previous deployment' for the production stage.
Why it's wrong here
The deployment queue setting 'After previous deployment' ensures the production stage is queued to run only after the previous stage in the release pipeline (in this case, staging) has fully completed, including any successful deployment and post-deployment steps. This enforces sequential execution and guarantees that production does not begin until staging has finished, regardless of the trigger type.
- ✓
Add a gate that checks if the staging deployment succeeded.
Why this is correct
A gate on the production stage can evaluate conditions (such as querying deployment status, health metrics, or work items) before the deployment proceeds, but it does not control when the stage is queued or started; stage triggers and queue settings determine ordering. Moreover, checking whether staging succeeded is inherently handled by the pipeline's stage dependency logic, and relying on a gate alone would not prevent production from starting before staging runs.
Visual reference
Go deeper
Related to this question
Learn chapter
Designing a Build Pipeline
Key term
Stage
A stage is a discrete phase in a software development or deployment pipeline where code is built, tested, integrated, or released in a controlled environment.
Key term
Release pipeline
A Release pipeline is an automated sequence of steps that takes software from code commit to production deployment, ensuring quality and consistency.
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 →
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.