AZ-400 Manual approval for production Practice Question
You have a release pipeline that deploys to multiple environments. You need to ensure that a manual approval is required before deploying to production. What should you configure?
⚠ Common exam trap
Many candidates confuse pre-deployment approvals with post-deployment approvals or manual intervention tasks, as candidates often think a manual task can substitute for a formal approval gate, but only pre-deployment approvals enforce the 'before deployment' requirement with proper workflow and audit trail.
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 a pre-deployment approval on the production stage
Pre-deployment approvals are configured on a stage in Azure Pipelines to require manual sign-off before any deployment to that stage begins. Since the question specifies that approval is needed before deploying to production, a pre-deployment approval on the production stage enforces that gate before the release pipeline executes any deployment tasks in that 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.
- ✗
Add a manual intervention task in the production stage
Why it's wrong here
A manual intervention task is an agent-based task that pauses execution within the job and requires a user to resume, but it is not a stage-level approval and does not provide the same auditability or separation of duties as a pre-deployment approval.
- ✗
Set a post-deployment approval on the production stage
Why it's wrong here
A post-deployment approval is configured to execute after the production stage has already run, meaning the release pipeline will deploy the artifact to production before any approver can review or consent. By the time the post-deployment approval is triggered, the software is already live, so it does not prevent or gate the deployment — it merely allows for a sign-off after the fact, often used for validation or compliance documentation. While it offers a manual checkpoint and audit trail, it fundamentally cannot satisfy a requirement to approve before production deployment, because the deployment has already succeeded. This makes it an incorrect choice for a pre-deployment manual authorization gate.
- ✓
Set a pre-deployment approval on the production stage
Why this is correct
A pre-deployment approval is a release-stage gate that pauses the pipeline immediately before the production stage starts, and it requires a designated approver or approval group to explicitly approve the deployment. This ensures the artifact is not deployed to production until manual authorization is granted, and Azure Pipelines records the approver, timestamp, and any comments for full auditability. Unlike branch policies or post-deployment hooks, this mechanism directly satisfies the requirement to approve before production deployment and provides a clean separation of duties between build and release. Additionally, you can configure policies such as re-approval if the artifact changes, making it the correct, policy-driven approach.
- ✗
Set a branch policy on the release branch
Why it's wrong here
A branch policy on the release branch operates at the source-control level, typically requiring pull request reviews, successful builds, or merge checks before code is merged into that branch. It has no effect on a release pipeline that has already built and packaged an artifact, because the artifact is immutable at deployment time and the pipeline does not re-evaluate branch policies when deploying. Even if the branch policy were active, it would not pause or gate the production stage, so it cannot serve as a manual approval mechanism for a specific release deployment. This is why it is incorrect: it governs code changes, not the deployment of an artifact to a production environment.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-400 exam frequently reuses these exact scenarios with slightly different constraints.
✓Set a pre-deployment approval on the production stageCorrect answer▾
Why this is correct
A pre-deployment approval is a release-stage gate that pauses the pipeline immediately before the production stage starts, and it requires a designated approver or approval group to explicitly approve the deployment. This ensures the artifact is not deployed to production until manual authorization is granted, and Azure Pipelines records the approver, timestamp, and any comments for full auditability. Unlike branch policies or post-deployment hooks, this mechanism directly satisfies the requirement to approve before production deployment and provides a clean separation of duties between build and release. Additionally, you can configure policies such as re-approval if the artifact changes, making it the correct, policy-driven approach.
✗Add a manual intervention task in the production stageWrong answer — click to see why▾
Why this is wrong here
Manual intervention task is for classic releases, but approvals are a better fit and work in YAML too.
✗Set a post-deployment approval on the production stageWrong answer — click to see why▾
Why this is wrong here
Post-deployment approval occurs after deployment, not before.
✗Set a branch policy on the release branchWrong answer — click to see why▾
Why this is wrong here
Branch policies affect pull requests, not release pipelines.
Analysis generated from the official AZ-400blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Visual reference
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
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.
Key term
Stage
A stage is a discrete phase in a software development or deployment pipeline where code is built, tested, integrated, or released in a controlled environment.
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.