Design and implement build and release pipelines →hardMultiple ChoiceObjective-mapped

AZ-400 Practice Question: Design and implement build and release pipelines

You have a multi-stage YAML pipeline that deploys to multiple environments. You want to enforce that a manual approval is required before deploying to the production environment, but not for other environments. How should you configure the pipeline?

⚠ Common exam trap

A common mix-up: candidates confuse environment-level approval checks with stage-level gates or pipeline-level settings, thinking they can add an approval directly on a stage in the pipeline settings UI, which is not supported.

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 an environment named 'Production', add an approval check, and reference the environment in the deployment job.

Azure Pipelines allows you to add an approval check on a specific environment. By creating an environment named 'Production' and attaching an approval check to it, any deployment job that references that environment will require manual approval before proceeding. This ensures that only the production deployment is gated, while other environments deploy automatically.

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 an environment named 'Production', add an approval check, and reference the environment in the deployment job.
Why this is correct
In Azure Pipelines, manual approval checks are attached to environments, not to stages or the pipeline as a whole. By defining a 'Production' environment, adding an approval check to it, and referencing that environment in the deployment job's `environment:` keyword, you create a pre-deployment gate that prompts a designated approver before the job executes, yielding controlled, auditable production deployments.
✗
Set a pipeline-level approval check that applies to all stages.
Why it's wrong here
You cannot attach an approval check at the pipeline level in Azure Pipelines; checks are scoped to protected resources (such as environments). Even if such a setting existed, it would apply the approval requirement to every stage in the pipeline, including non-production stages, breaking the intended stage-specific control and forcing manual intervention for all deployments.
✗
Add an approval gate on the 'Production' stage in the pipeline settings.
Why it's wrong here
Azure Pipelines does not support configuring approval gates on a stage from pipeline settings; approvals and checks are defined on the environment that a deployment job targets. A stage itself has no resource-level check mechanism, so attempting to add an 'approval gate' on the stage would not only be invalid but also conflate the distinct concepts of stage execution and environment-based protection.
✗
Configure branch policy on the main branch to require approval for all changes.
Why it's wrong here
Branch policies operate at the repository level, governing when pull request changes can be merged into a branch (e.g., requiring reviewers or successful builds). They have no effect on pipeline executions after merge and cannot insert a manual approval step before a deployment runs, so this approach would not control production deployments as required.

Go deeper

AZ-400 Practice Question: Design and implement build and release pipelines

Why each option matters

Option-by-option breakdown

Related to this question