AZ-400 Practice Question: Design and implement build and release pipelines
Which THREE of the following are valid considerations when designing a release pipeline to deploy to multiple environments (dev, test, prod) using Azure Pipelines YAML?
⚠ Common exam trap
A common mix-up: candidates confuse stage-level approvals (which do not exist) with environment-level approvals, and they mistakenly think YAML templates should be used to define separate deployment steps per environment instead of parameterizing a single template.
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 variable groups scoped to environments to override variables per stage.
Variable groups can be reused across pipelines and stages. In a multi-stage YAML pipeline, you can use different variable groups for each environment by referencing them in the `variables` section of each stage (e.g., a variable group for dev, test, and prod). This allows you to override values such as connection strings per environment without duplicating pipeline code. For production deployments, you should configure approvals and checks on the Azure Pipelines environment resource (e.g., 'prod') to require manual sign-off before the deployment job runs. Stage-level approvals do not exist in Azure Pipelines; approvals are always attached to an environment or a service connection. For branch-based filtering, you can use stage `condition` expressions, such as `and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`, to control which stages run based on the source branch. To reduce duplication, use YAML templates with parameters to define a single deployment template that is reused across environments rather than creating separate templates per environment.
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 variable groups scoped to environments to override variables per stage.
Why this is correct
In Azure Pipelines, variable groups can be linked to an environment, allowing environment-specific variable values to be automatically injected into deployment jobs that target that environment. This enables per-stage overrides without duplicating pipeline code, because each stage can reference a different environment and thus consume its linked variable group, making it a valid and recommended practice.
- ✓
Use environment-level approvals to gate production deployments.
Why this is correct
Environment approvals are a first-class control in Azure Pipelines that require designated approvers to manually validate a deployment before it proceeds to a protected environment. This is the correct way to gate production deployments because the check is attached to the environment resource itself, not to a stage, and it automatically applies to any pipeline that deploys to that environment, providing auditability and control.
- ✗
Use stage-level approvals to gate each stage.
Why it's wrong here
Azure Pipelines does not support attaching approval checks directly to a pipeline stage; approval gates are configured on environments and are invoked when a deployment job targets that environment. Trying to enforce stage-level approvals would require workarounds like manual validation tasks or creating separate environments per stage, which lack the built-in audit, notification, and centralized management of environment approvals.
- ✓
Use conditions on stages to filter based on branch.
Why this is correct
Stage conditions in YAML pipelines can evaluate expressions such as eq(variables['Build.SourceBranch'], 'refs/heads/main'), enabling stages to run only for specific branches. This is a valid, declarative way to filter stage execution by branch without needing separate pipeline definitions or external scripts, and it integrates cleanly with the pipeline's dependency graph and other conditions.
- ✗
Use YAML templates to define each environment's deployment steps.
Why it's wrong here
YAML templates are a code-reuse mechanism for structuring pipeline definitions, but they are not inherently tied to environments; using templates is a style and maintainability choice, not a required consideration for environment-based deployment management. Environment-specific deployment steps can be defined directly in the pipeline or via templates, but that decision does not affect how environments gate, track, or secure deployments, so it is not one of the core considerations.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Service connection
A service connection in Azure DevOps is a secure, configurable link that allows your pipelines to authenticate and interact with external services like Azure, GitHub, or on-premises servers.
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.
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.