Two Actions That Implement a Gated Deployment in Azure Pipelines
Which TWO actions should you take to implement a gated deployment strategy in Azure Pipelines?
Quick Answer
Deployment gates evaluate external health signals — error rates from Azure Monitor or Application Insights, for example — before letting a release proceed to the next stage automatically. Manual approval checks add the human half of a gated strategy, pausing the pipeline for an explicit sign-off before deployment continues. Together, automated gates and manual approvals are what make a deployment gated.
⚠ Common exam trap
Watch out — candidates often confuse monitoring (dashboard) or pipeline structure (multi-stage YAML) with the actual gating mechanism, forgetting that gates require explicit evaluation of health metrics or approvals to block or allow the release.
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 deployment gates to evaluate metrics like error rate before allowing the next stage.
Option A is correct because deployment gates in Azure Pipelines are precisely the mechanism that queries external sources—such as Azure Monitor alerts, REST APIs, or work items—to evaluate metrics like error rate and automatically decide whether the stage may proceed, which is the core of a gated deployment. Option E is correct because manual approval checks (approvals and checks configured on an environment or service connection) pause the pipeline before production deployment so a human can verify readiness, which is a standard gating control in a gated release strategy. Option B is not correct because a dashboard is a monitoring and visualization tool; it reports health but does not itself gate or block a pipeline stage. Option C is not correct because a multi-stage YAML pipeline is just the structural definition of stages and does not by itself implement gating logic. Option D is not correct because a rollback strategy is a recovery measure after a failed deployment, not a gate that controls whether deployment proceeds.
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 deployment gates to evaluate metrics like error rate before allowing the next stage.
Why this is correct
Deployment gates query external metrics such as error rate or incident counts before releasing a stage, automatically blocking promotion when thresholds are breached. This satisfies the gated deployment requirement by enforcing automated, metric-based verification rather than relying solely on human judgement.
- ✗
Configure a dashboard to monitor application health.
Why it's wrong here
A dashboard surfaces health metrics but does not enforce a gate; Azure Pipelines gates require configured checks such as invoke REST API, query work items, or approvals that block a stage automatically. It is tempting because monitoring is integral to release validation, yet dashboards inform humans rather than halting promotion.
- ✗
Use a multi-stage YAML pipeline.
Why it's wrong here
A multi-stage YAML pipeline structures build and release phases but contains no gate construct; gates are added via approval and check configurations on environments or stages. It is tempting because multi-stage pipelines are the recommended modern pattern, yet staging alone neither evaluates conditions nor blocks deployment.
- ✗
Configure a rollback strategy if deployment fails.
Why it's wrong here
A rollback strategy handles failure after deployment, whereas gates prevent promotion until pre-defined conditions pass; the requirement is to block, not to recover. It is tempting because rollback is a release-safety practice, but it operates post-deployment and does not satisfy gated deployment semantics.
- ✓
Add manual approval checks before deployment to production.
Why this is correct
Manual approval checks pause a stage until nominated approvers sign off, giving human verification before production release. Combined with automated gates, this enforces the controlled promotion the gated deployment strategy requires, preventing unreviewed changes reaching live environments.
Visual reference
Go deeper
Related to this question
Learn chapter
Implementing Security and Compliance in Pipelines
Key term
Dashboard
A dashboard is a visual display of key metrics and data points that helps IT professionals monitor, analyze, and manage systems or processes in real time.
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
Courseiva writes every AZ-400 question from scratch — 696 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 →
Same concept, more angles
1 more way this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which TWO conditions must be met to use the 'Approvals and gates' feature in a release pipeline? (Choose two.)
medium- A.A manual intervention task must be added.
- B.A post-deployment approval must be configured.
- ✓ C.A pre-deployment approval must be configured.
- D.A variable group must be linked to the pipeline.
- ✓ E.The pipeline must use a service connection.
Why C: Option C is correct because Approvals and gates in an Azure DevOps release pipeline require at least one approval to be configured on a stage — either a pre-deployment approval (checked before the stage runs) or a post-deployment approval — and the pre-deployment approval is the canonical trigger that enables the approval mechanism for that stage. Option E is correct because approvals and gates are evaluated against a target resource that the pipeline deploys to, and that target (such as an Azure subscription, resource group, or other protected resource) is reached through a service connection, so a service connection must be present for the approval/gate checks to be associated with the deployment. Option A is not required: a Manual Intervention task is a separate agentless task that pauses a running stage, not a prerequisite for enabling Approvals and gates. Option B is not required: a post-deployment approval is an alternative placement of an approval, not a mandatory condition, and the feature works with a pre-deployment approval alone. Option D is not required: variable groups supply variables to the pipeline and have no bearing on whether approvals and gates can be used.
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.