AZ-400 Practice Question: Design and implement build and release pipelines
You are implementing a release pipeline for a web application deployed to multiple Azure App Service instances across different regions (West US, East US, and North Europe). The deployment must follow a phased rollout: first West US, then East US, then North Europe, with a manual approval gate between each region. Each region should have its own slot for staging and production. You need to design the pipeline to minimize duplication of stages and tasks. What should you do?
⚠ Common exam trap
The trap is assuming deployment groups are the universal solution for multi-target deployment. For Azure App Service, deployment groups are not appropriate; you must use environments and deployment jobs targeting App Service resources.
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 multi-stage YAML pipeline with environment per region and a manual approval on each environment.
For a phased rollout to multiple Azure App Service regions, you should create an environment per region and use a multi-stage YAML pipeline that contains deployment jobs (or stages) targeting those environments. Manual approval gates can be configured on each environment, enabling controlled progression from West US to East US to North Europe without duplicating tasks. This approach directly uses App Service slots and environments. Deployment group jobs (Option D) are intended for targeting on-premises or VM-based agents, not App Service instances, and do not support slots. Options B and C are incorrect because they duplicate tasks or deploy in parallel rather than in the required phased sequence.
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 multi-stage YAML pipeline with environment per region and a manual approval on each environment.
Why this is correct
While this approach provides a manual approval gate per region via separate environments, it still requires the pipeline author to define and manage duplicate environment objects and job logic for each region, significantly increasing YAML complexity and maintenance burden compared to a single reusable job that targets tagged deployment group agents.
- ✗
Create three separate stages (one per region) and duplicate the deployment tasks in each.
Why it's wrong here
Duplicating stages and tasks for each region leads to copy-paste maintenance: any change to deployment steps must be applied multiple times, risking drift and errors, and the pipeline becomes longer, harder to read, and less efficient than a single parametric job that selects the target region via agent tags.
- ✗
Use a single stage with parallel deployment to all regions and add manual approvals before each region's deployment.
Why it's wrong here
A single stage with parallel deployment to all regions sends the update to every region at once, so there is no phased rollout window to validate the first region before others proceed; the manual approvals exist only before the parallel fan-out, not between individual regions, preventing you from controlling or pausing a sequential rollout.
- ✗
Use a single stage with a deployment group job that targets agents tagged with region names, and use deployment group tags to control phased rollout.
Why it's wrong here
Using a single deployment group job with agents tagged by region lets you reuse the same tasks for every region and control the rollout order by scoping the tag query per run (for example, deploying only to the 'canary' tag first, then adding 'prod-west', then 'prod-east'), enabling phased releases with minimal duplication and full oversight through approval gates.
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
Approval gate
An approval gate is a checkpoint in an Azure DevOps release pipeline where a pipeline run pauses until a designated team or person manually approves or rejects the deployment.
About these practice questions
One of 823 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.