Checks and approvals with YAML environments
Design and implement checks and approvals by using YAML-based environments
Conditions let the pipeline author decide whether a stage runs. Checks let the resource owner decide whether a stage may consume their resource. That ownership split is the concept the exam tests.
Where checks attach
Checks are configured on resources, not on pipelines:
- Environments
- Service connections
- Agent pools
- Variable groups
- Secure files
A manual approval on the production environment therefore governs every
pipeline that deploys to it, including one written by a team that has never seen
your approval policy.
The five categories, in order
Within a category, checks run in the order they were created. Checks are re-evaluated on each check's retry interval, and if they have not all succeeded before the timeout, the stage does not execute. A terminal failure — someone rejecting an approval — stops the stage immediately.
Checks worth knowing by name
| Check | What it enforces |
|---|---|
| Branch control | The deployment may only come from permitted branches |
| Required template | The pipeline must extend a specified template — the technical enforcement behind "every pipeline must use our secure template" |
| Business hours | Deployment only within a stated window |
| Exclusive lock | Only one run at a time may proceed to the resource |
| Invoke Azure Function / REST API | Gate on an external system's answer |
| Query Azure Monitor alerts | Block the deployment if the target is currently alerting |
Exclusive lock runs last and is what prevents two concurrent releases from colliding on the same environment.
Environments give you more than a gate
An environment also provides deployment history per target and the resource
records (VMs, Kubernetes namespaces) that strategies like rolling operate on.
That is why deployment jobs target environments while ordinary jobs do not.
Primary sources