AZ-400 Practice Question: Design and implement build and release pipelines
You are designing a release pipeline for a critical production application. The pipeline must ensure that changes are deployed to a staging environment first, and if integration tests pass, they are automatically deployed to production. However, if the tests fail, the deployment to production must be blocked. What is the best approach?
⚠ Common exam trap
It's easy for candidates to confuse stage-level gates with task-level conditions, assuming a single stage with conditional tasks can achieve the same result, but gates operate at the stage boundary and can evaluate aggregated results from the entire previous stage, not just individual task outcomes.
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
✓
Create a multi-stage YAML pipeline with a gate on the production stage that evaluates test results from the staging stage.
A multi-stage YAML pipeline with a gate on the production stage allows you to evaluate the results of integration tests run in the staging stage before proceeding to production. The gate can be configured to check for test pass/fail status from the staging stage, blocking the production deployment if tests fail. This approach provides a clear, automated approval flow within a single pipeline definition, aligning with the requirement for conditional promotion based on test results.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create a single stage in the pipeline with conditional tasks to deploy to staging and then to production based on test results.
Why it's wrong here
This approach bundles staging and production in a single stage, losing the separation needed for independent rollback and environment-specific configuration. Conditional tasks that run based on test results are not a formal gate, so they cannot evaluate published test data before promoting, and a failed production deployment would require redeploying the entire stage rather than isolating the failure.
- ✓
Create a multi-stage YAML pipeline with a gate on the production stage that evaluates test results from the staging stage.
Why this is correct
This approach leverages a single YAML pipeline with multiple stages, where the staging stage deploys and runs tests, publishing results as artifacts. A pre-deployment gate on the production stage uses those published test results (e.g., pass rate or coverage) to automatically block or allow the promotion, ensuring the exact same build that passed staging is deployed. Because gates are evaluated automatically before the stage starts, no manual approval is required, yet the release is safely gated by objective quality signals.
- ✗
Create two separate pipelines: one for staging and one for production. Use a pipeline trigger to run the production pipeline after staging completes.
Why it's wrong here
Two separate pipelines do not share the same artifact version by default, so the production pipeline may deploy a different build than the one validated in staging. A pipeline trigger only waits for completion; it does not evaluate test results or enforce a quality gate before production, and managing two definitions adds unnecessary overhead compared to a single multi-stage YAML pipeline.
- ✗
Use a classic release pipeline with pre-deployment approvals on the production stage.
Why it's wrong here
Classic release pipelines with pre-deployment approvals require a human to manually approve each production release, which does not satisfy the requirement of automatic promotion based on test results. This option lacks an automated gate that can evaluate test pass rates from the staging stage, whereas a multi-stage YAML pipeline can apply a built-in gate that automatically blocks or allows promotion.
Go deeper
Related to this question
Learn chapter
Designing a Build Pipeline
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.
Key term
Pipeline
A pipeline is an automated series of steps that takes code from development to production, ensuring quality and speed.
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 →
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.