L13. Checks, Approvals & Environments in YAML Pipelines
Environments centralize deployment gates, Azure Monitor alert checks can automatically block a deploy during an active incident, and deployment jobs support first-class strategies plain jobs never will.
YAML Environments as Deployment Targets
In a YAML pipeline, an environment represents a logical deployment target: production, staging, or a Kubernetes namespace. Crucially, checks and approvals attach to environments, not to individual pipelines.
This means the same approval requirement applies whether pipeline A or pipeline B deploys there. If your security policy requires two approvals before production, every team's pipeline to production must follow that policy because it is enforced on the environment itself.
Types of Checks: Manual vs Automated
Checks fall into two categories: Manual approvals: a named human must sign off before deployment proceeds. The approver receives a notification and must explicitly approve in the Azure DevOps UI or reject the deployment. Automated gate conditions include:
- Azure Monitor alert check: blocks deployment while a specified alert is actively firing (e.g., a Sev1 incident alert)
- Business hours check: only allows deployments during a defined window (e.g., 9 AM to 6 PM on weekdays)
- REST API or Azure Function check: invokes external logic to decide whether to allow progression
- Branch control: only allow deployment from specific branches (e.g., only from main, never from feature branches)
A single environment can have multiple checks stacked together. All must pass before deployment proceeds.
Deployment Jobs vs Regular Jobs
A deployment job (using the deployment: keyword) is purpose-built for environments and supports first-class deployment strategies as a built-in concept:
jobs:
<ul class="list-disc pl-6 mb-4 space-y-2">
<li class="text-slate-300">deployment: Deploy</li>
</ul>
environment: production
strategy:
runOnce:
deploy:
steps: [...]A regular job (job:) has no native environment or strategy support. You can reference an environment in a regular job, but strategies like rolling or canary are not recognized.
Approval Strategies Comparison
| Approach | Pros | Cons |
|---|---|---|
| Approval on environment | Single source of truth, consistent across all pipelines | Less granular (applies to entire environment) |
| Approval in each pipeline YAML | Flexible per-pipeline | Duplicated policy, hard to enforce uniformly |
| Automated alerts as gates | Prevents deploys during incidents | Requires proper alert configuration |
Environment Resource Scoping
Environments can reference specific resources within them: a Kubernetes namespace, a VM resource, or an Azure resource group. This allows checks to apply at a granular level (e.g., approval required only for production namespace, not staging namespace).
Why Centralize Checks on Environments
Imagine a production environment with 10 teams deploying via different pipelines. If approval is baked into each pipeline's YAML, one team's pipeline might have the wrong approvers, or a policy change requires editing 10 files. By centralizing the check on the environment, all 10 pipelines inherit the same policy automatically, and updating approvers requires one change. Exam tip: The AZ-400 exam tests why Azure Monitor alert checks matter: they automate the decision to block a deployment during an active incident, removing the dependency on a human remembering to check the incident dashboard first.
- ✓A YAML environment represents a deployment target and is the object checks and approvals attach to, so the same approval requirement applies consistently no matter which pipeline deploys to that environment
- ✓Checks include both manual approvals (a named human must sign off) and automated gate conditions like an Azure Monitor alert check, a business-hours restriction, or a custom REST API/Azure Function validation
- ✓An Azure Monitor alert check can block a deployment from proceeding while a specified alert is actively firing, preventing a deployment during an ongoing incident
- ✓A deployment job (using the deployment: keyword) is purpose-built to target an environment and supports first-class deployment strategies (runOnce, rolling, canary), unlike a plain job: which has no environment-check integration
- ✓Centralizing checks on the environment itself, rather than duplicating an approval step in every pipeline's YAML, keeps the sign-off policy consistent and lets it be updated in one place regardless of how many pipelines deploy there
1. A company wants to guarantee that no deployment to production proceeds while there is an active Sev1 incident, without relying on a human remembering to check the incident dashboard first. What YAML pipeline feature supports this automatically?
2. What distinguishes a deployment job (deployment:) from a regular job (job:) in a YAML pipeline?
3. Why would a team attach an approval check to a YAML environment representing production, rather than adding a manual approval step inside each individual pipeline's YAML file?
Recommended: Pluralsight
This free course covers the theory. Pluralsight adds structured DevOps Engineer Expert learning paths, hands-on Azure Pipelines and GitHub Actions labs, and timed practice exams to make it stick before exam day.