Designing a Multi-Stage Pipeline with Conditional Testing and Approvals
You are designing a release pipeline for a critical business application that must adhere to strict compliance requirements. The pipeline must deploy to multiple environments (dev, test, staging, prod) with manual approvals required for staging and prod. Additionally, the pipeline must automatically run integration tests after deployment to dev and test, and only proceed to the next environment if tests pass. You need to implement this using Azure Pipelines YAML. What should you do?
Quick Answer
A single multi-stage YAML pipeline handles all of this in one definition: one stage per environment, a job after the dev deployment that runs integration tests, a condition on the next stage that only proceeds if those tests passed, and approval gates added to the staging and prod stages. Splitting this into separate pipelines or using the classic release designer can't enforce the conditional test gate as cleanly.
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
✓
Use a single multi-stage YAML pipeline with a stage per environment. Add a job after deployment to dev that runs integration tests, and use a condition on the next stage to run only if tests passed. Add approvals on staging and prod stages.
It uses a single multi-stage YAML pipeline with a stage per environment, adds a job after deployment to dev that runs integration tests, uses a condition on the next stage to run only if tests passed, and adds approvals on staging and prod stages. This satisfies all requirements: sequential deployment, conditional test execution, and manual approvals. Option A is incorrect because it lacks the conditional test execution; after deployment to dev, the pipeline would proceed to test regardless of test results. Option B is incorrect because separate pipelines with completion triggers cannot enforce the required conditions (run tests and only proceed if passed) and cannot easily add approvals per environment. Option C is incorrect because it describes a classic release pipeline, which does not support YAML-based definitions and cannot easily integrate conditional test execution with stage dependencies.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use a single multi-stage YAML pipeline with a stage per environment. Add approvals on staging and prod stages. Ensure stages run sequentially by default.
Why it's wrong here
No automated test gate between dev and test.
- ✗
Create separate YAML pipelines for each environment and use pipeline completion triggers to chain them together.
Why it's wrong here
Lack of centralized coordination and test result propagation.
- ✗
Use a classic release pipeline with environments and pre-deployment approvals on staging and prod. Add a post-deployment task to run integration tests in dev and test environments.
Why it's wrong here
Classic release pipelines do not support conditional stage execution based on test results.
- ✓
Use a single multi-stage YAML pipeline with a stage per environment. Add a job after deployment to dev that runs integration tests, and use a condition on the next stage to run only if tests passed. Add approvals on staging and prod stages.
Why this is correct
Stages with conditions and approvals fulfill all requirements.
Visual reference
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Pipeline
A pipeline is an automated series of steps that takes code from development to production, ensuring quality and speed.
Key term
Environment
An environment is a dedicated set of computing resources, configurations, and services used to develop, test, or host software applications in a controlled and repeatable way.
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 →
Same concept, more angles
6 more ways this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You are setting up a release pipeline for a web application. The pipeline must deploy to three environments: Dev, Test, and Prod. The deployment to Prod must be triggered only after a successful deployment to Test and after a manual approval. How should you configure the pipeline?
easy- A.Add a manual intervention task before the Prod deployment in the pipeline.
- B.Use a condition on the Prod stage to require success from Test and manual intervention variable.
- C.Schedule the Prod deployment to run after Test, and require manual trigger.
- ✓ D.Add a pre-deployment approval gate on the Prod environment.
Why D: Pre-deployment approval gates on the Prod environment block the release until manual approval is granted, and a stage condition ensures it runs only after successful Test deployment. Option A is wrong because manual intervention tasks are not designed for approvals and do not integrate with pipeline stages as seamlessly. Option B is wrong because conditions can't enforce manual approval; they only evaluate at runtime. Option C is wrong because scheduling doesn't provide manual approval; triggers can be manual but not combined with stage success conditions effectively.
Variation 2. 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.)
medium- A.Add a post-deployment approval on the staging stage.
- ✓ B.Add a pre-deployment approval on the production stage.
- C.Set the trigger to 'After release' and filter by artifact.
- D.Set the deployment queue setting to 'After previous deployment' for the production stage.
- ✓ E.Add a gate that checks if the staging deployment succeeded.
Why B: 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.
Variation 3. Your release pipeline deploys to multiple environments (Dev, QA, Prod) using approvals. You need to ensure that the deployment to Prod only proceeds if the deployment to QA succeeded and an approval is granted. Which combination of triggers and pre-deployment conditions should you configure?
hard- A.Set the trigger on Prod to 'Automatic' and add a post-deployment approval on QA.
- B.Set the trigger on Prod to 'After release' and add a pre-deployment approval on Prod.
- C.Set the trigger on Prod to 'Manual only' and add a pre-deployment approval on Prod.
- ✓ D.Set the trigger on Prod to 'After stage' and select QA as the stage, and add a pre-deployment approval on Prod.
Why D: It configures the Prod stage trigger to 'After stage' with QA selected as the preceding stage, ensuring that the release to Prod only starts after QA completes successfully. Adding a pre-deployment approval on Prod then enforces that a manual approval is granted before the deployment actually begins. This combination satisfies both conditions: dependency on QA success and required approval.
Variation 4. You have a release pipeline that deploys to multiple stages (Dev, QA, Prod). You want to automatically deploy to Dev and QA after a successful build, but require a manual approval for Prod. Which deployment strategy should you use?
medium- A.Set pre-deployment approvals on the Dev and QA stages.
- ✓ B.Set pre-deployment approvals on the Prod stage.
- C.Use a post-deployment approval on the QA stage.
- D.Disable the automatic trigger for all stages.
Why B: Pre-deployment approvals control whether a release can start deploying to a stage. By setting a pre-deployment approval on the Prod stage only, Dev and QA will deploy automatically (since they have no approval requirement), while Prod requires manual sign-off before deployment begins. This matches the requirement exactly.
Variation 5. You are designing a release pipeline for a mission-critical application. The pipeline must deploy to multiple environments (dev, test, prod) in sequence, with manual approval required before production deployment. Which Azure Pipelines feature should you use?
easy- ✓ A.Pre-deployment approvals
- B.Variable groups
- C.Pipeline triggers
- D.Deployment gates
Why A: Pre-deployment approvals are the correct feature because they allow you to require manual sign-off before a release proceeds to a specific stage. In this scenario, you need a manual approval gate before production deployment, which is exactly what pre-deployment approvals enforce—the release pauses at the production stage until an authorized user approves it.
Variation 6. You have a multi-stage YAML pipeline in Azure DevOps that deploys to multiple environments. The pipeline uses a deployment job with environment approvals. You need to ensure that the deployment to the production environment is only triggered after a manual approval is granted. However, you also want the deployment to automatically roll back if the post-deployment health check fails. Which configuration should you implement?
hard- A.Use a release pipeline with a pre-deployment approval and a post-deployment automatic rollback trigger.
- B.Configure pre-deployment approvals on the production environment and use a post-deployment gate that fails the deployment.
- C.Configure pre-deployment approvals and add a manual intervention task to roll back if health check fails.
- ✓ D.Enable 'Auto-revert' on the production environment and set post-deployment conditions.
Why D: Azure DevOps environments support an 'Auto-revert' setting that automatically triggers a rollback to the previous successful deployment when a post-deployment health check (defined via post-deployment conditions) fails. This combines manual approval (pre-deployment approvals on the environment) with automatic rollback, meeting both requirements without additional tasks or release pipelines.
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.