AZ-400 Practice Question: Design and implement build and release pipelines
Your company develops a microservices-based application deployed on Azure Kubernetes Service (AKS). The CI/CD pipeline uses Azure Pipelines. The development team has recently adopted a trunk-based development strategy where all feature work is done on short-lived branches that merge to main at least daily. The release pipeline must automatically deploy to a development environment on each commit to main, and to a staging environment after a manual approval. The staging environment is used for integration tests and must remain stable. You need to design the release pipeline strategy to support this workflow. What should you do?
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 single release pipeline with two stages: 'Dev' triggered automatically on successful build, and 'Staging' with a pre-deployment approval gate.
It creates a single release pipeline with two stages: 'Dev' triggered automatically on successful build, and 'Staging' with a pre-deployment approval gate. This meets the requirements: automatic deployment to dev on each commit to main, and manual approval before deploying to staging, keeping staging stable. Option A is wrong because deploying to both environments simultaneously bypasses the manual approval needed for staging. Option C is wrong because separate pipelines add maintenance overhead and don't leverage pipeline stages for approval gates. Option D is wrong because a post-deployment approval gate would deploy to staging first, then require approval, which doesn't prevent deployment without approval. Also disabling continuous deployment trigger for staging would require manual promotion, which is not desired.
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 release pipeline with one stage that deploys to both dev and staging simultaneously, and add a manual intervention task before staging deployment.
Why it's wrong here
Simultaneously deploying to dev and staging in one stage is incorrect because these environments serve different purposes (early validation vs. release candidate verification). A manual intervention task only pauses the pipeline mid-flight and does not provide a formal, auditable pre-deployment approval gate, nor does it allow staging to be promoted independently from dev.
- ✓
Create a single release pipeline with two stages: 'Dev' triggered automatically on successful build, and 'Staging' with a pre-deployment approval gate.
Why this is correct
A single release pipeline with a 'Dev' stage triggered automatically on successful build and a 'Staging' stage with a pre-deployment approval gate is the correct pattern. It promotes the same build artifact through environments, enables fast feedback in dev, and uses an approval gate to ensure staging deployments are authorized and traceable before they occur.
- ✗
Create two separate release pipelines: one for dev with continuous deployment trigger, and one for staging with a manual trigger.
Why it's wrong here
Creating separate release pipelines for dev and staging is harder to maintain because you duplicate pipeline definitions and risk deploying different build versions to each environment. The same build artifact should flow through stages in one pipeline to maintain traceability, and a manual trigger on a separate pipeline does not tie the staging deployment to the specific artifact that already passed dev.
- ✗
Create a single release pipeline with two stages: 'Dev' triggered automatically, and 'Staging' with a post-deployment approval gate and disable continuous deployment trigger.
Why it's wrong here
Disabling CD trigger would not allow automatic deployment to staging after approval; approval should be pre-deployment.
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
Continuous deployment
Continuous deployment is a software release practice where every code change that passes automated tests is automatically deployed to production without human approval.
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.