AZ-400 Practice Question: Design and implement build and release pipelines
You are designing a multi-stage YAML pipeline for an application that requires approval for production deployment. The pipeline must run automatically for non-production stages. Which TWO configurations should you use?
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
✓
Set the pipeline trigger to include branches used for non-production stages.
Options A and B are correct. Option A: Setting the pipeline trigger to include branches used for non-production stages enables automatic CI triggers for those branches, so non-production stages run automatically. Option B: Adding an 'approvals' block to the production stage enforces manual approval before deployment to production. Options C, D, and E are incorrect: C suggests using a release pipeline which is unnecessary; D would require manual approval for every stage, not just production; E describes a single-stage pipeline, which doesn't fit the multi-stage requirement.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Set the pipeline trigger to include branches used for non-production stages.
Why this is correct
Setting the pipeline trigger to include branches used for non-production stages means CI will automatically run the pipeline for changes to develop/feature branches, allowing non-production stages (e.g., build, test, staging) to execute without manual intervention. This is correct in a multi-stage YAML design where automated progression is desired for non-production while production remains approval-gated.
- ✓
Define a stage for production with an 'approvals' block.
Why this is correct
Defining a production stage with an 'approvals' block attaches a manual approval gate at the stage level, so the pipeline automatically executes non-production stages and then pauses before the production deployment until an authorized user approves or rejects the run. This is the declarative YAML equivalent of a pre-deployment approval in classic releases.
- ✗
Use a release pipeline instead of a YAML pipeline.
Why it's wrong here
Using a separate release pipeline is incorrect because Azure Pipelines YAML fully supports multi-stage definitions with environment approvals, branch triggers, and stage-level dependencies, making a classic release pipeline unnecessary for this scenario. Migrating to YAML allows the entire process to be versioned as code and managed consistently.
- ✗
Set the pipeline to require manual approval for every stage.
Why it's wrong here
Requiring manual approval for every stage would add unnecessary human gates to build, test, and other non-production stages, slowing down CI/CD and contradicting the requirement that only production should have a manual approval. In a multi-stage YAML pipeline, approvals are declared per stage (or per environment resource), so you can scope them exclusively to production.
- ✗
Use a single-stage pipeline with conditional approval.
Why it's wrong here
A single-stage pipeline with conditional approval cannot enforce separate approval gates for production while allowing automatic progression through non-production stages, because all stages share the same pipeline definition and approval configuration. This approach is tempting because conditional approvals can pause a single-stage run at a specific job or environment, which works for simple manual-intervention scenarios. It would be correct if the entire pipeline required a single approval point, without the need for distinct stage-level automation and separation between environments.
Visual reference
Go deeper
Related to this question
Learn chapter
Designing a Build Pipeline
Key term
YAML pipeline
A YAML pipeline is a text-based file written in YAML format that defines an automated series of steps for building, testing, and deploying software in a continuous integration and continuous delivery (CI/CD) system.
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
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.