Pipelines: testing strategy · Topic 1 of 2
Quality Gates and Release Gates
AZ-400 gates: quality gates in builds and pull requests, classic release gates, YAML environment checks, GitHub protection rules, security and governance.
- 5 min
- Quality gates guard the build and pull request. Release gates guard deployment.
- Classic release gates: Invoke Azure Function, Invoke REST API, Query Azure Monitor alerts, Query work items, security and compliance assessment.
- YAML pipelines use approvals and checks on environments and other resources. They are not in the YAML.
What it is
A gate is an automatic or manual checkpoint that decides whether a change may move to the next step. A quality gate protects the build stage: the code must compile, tests must pass and standards must be met. A release gate protects the deployment stage: the target environment must be healthy and the change must be approved.
Gates replace "someone remembers to check" with a rule that always runs. They also cover security (no critical vulnerabilities) and governance (the target is compliant, a change record exists).
How it works
Quality gates
Typical conditions a quality gate enforces:
| Condition | How it is enforced |
|---|---|
| Code builds and unit tests pass | Build validation on the pull request (Azure Repos) or a required status check (GitHub) |
| Code coverage meets a threshold | Coverage settings or a test step that fails below the target |
| Static analysis passes | A tool such as SonarQube or SonarCloud runs prepare, analyze and publish steps, and its quality gate result can fail the build |
| No new high severity vulnerabilities or leaked secrets | Code scanning, dependency scanning and secret scanning results |
| Review done | Required reviewers, comment resolution, linked work item |
| Licenses acceptable | A license compliance scan |
The principle is shift left: find problems at pull request time, where they are cheapest to fix.
Release gates in classic release pipelines
In a classic release pipeline, each stage has pre-deployment and post-deployment conditions with approvals and gates. Gates are automated checks that run repeatedly until all pass or a timeout is reached.
| Gate | Use |
|---|---|
| Invoke Azure Function | Call your own logic and check the response |
| Invoke REST API | Call a service, such as a change management system |
| Query Azure Monitor alerts | Pass only if no alerts are active for the application |
| Query work items | Pass only if a work item query returns an acceptable count, such as zero open critical bugs |
| Security and compliance assessment | Check Azure Policy compliance of the target resources |
Gate settings control when evaluation starts (a delay), how often it repeats (the sampling interval) and how long it may keep trying (the timeout). A gate that never passes fails the stage when the timeout ends. Gates and approvals can be evaluated in either order.
The YAML equivalent: checks on environments
Multistage YAML pipelines place approvals and checks on the resource, such as an environment, not in the YAML file. A stage that targets the environment waits for all checks.
| Check | Purpose |
|---|---|
| Approvals | A person or group must approve |
| Branch control | Only allowed branches may deploy, and they must be protected |
| Business hours | Deploy only inside a time window |
| Invoke Azure Function / Invoke REST API | Run your own validation |
| Query Azure Monitor alerts | Block while alerts are active |
| Required template | The pipeline must extend a specific template |
| Exclusive lock | Only one run deploys at a time |
Checks run in categories: static checks first, then pre-check approvals, then dynamic checks, post-check approvals and finally the exclusive lock. They are managed by the resource owner, so people who edit the YAML cannot remove them.
GitHub equivalents
GitHub environments support deployment protection rules: required reviewers, a wait timer, limits on which branches or tags can deploy, and custom protection rules provided by GitHub Apps (for example, checking a monitoring system). Environment secrets are available only to jobs that target the environment and pass its rules.
Security and governance gates
| Goal | Gate |
|---|---|
| Block vulnerable dependencies | Dependency scanning with a severity threshold that fails the run |
| Block leaked secrets | Secret scanning and push protection |
| Prove compliance | Azure Policy compliance check on the target, or an evidence step that stores results |
| Control who deploys to production | Approvals by a named group, with separation of duties |
| Tie to change management | An Invoke REST API check against the change system |
A worked scenario
A bank requires that nothing reaches production with an open critical bug or an active alert, and that a change manager approves. The team sets build validation on main, adds a SonarQube quality gate, and creates a production environment with a Query Azure Monitor alerts check, a branch control check that allows only main, and an approval by the change manager group. Pipeline authors cannot weaken these rules because they are not in the YAML.
What to remember for the exam
- Quality gates guard the build and pull request. Release gates guard deployment.
- Classic release gates: Invoke Azure Function, Invoke REST API, Query Azure Monitor alerts, Query work items, security and compliance assessment.
- YAML pipelines use approvals and checks on environments and other resources. They are not in the YAML.
- GitHub uses environment deployment protection rules and required status checks.
- Gates retry until they pass or time out.
"Block the deployment while the monitoring alert is open" is the Query Azure Monitor alerts gate or check.
How the exam asks about this
- "A pull request must not complete unless the build and tests pass." Build validation or a required status check.
- "Only deploy to production from protected branches." Branch control check.
- "Require a manager to approve deployment to production." An approval on the environment.
- "Stop the release while there are open critical bugs." Query work items gate (classic) or an Invoke REST API check.
Common mistakes
Putting approvals only in the YAML. Checks on the resource cannot be bypassed by editing the pipeline file.
Making a gate advisory. A gate that can be ignored is a suggestion.
Gates that are too slow. Slow gates tempt teams to bypass them. Run quick checks first.
Granting wide bypass rights. Anyone with bypass permission removes the protection.
Check yourself
Where are approvals and checks for a multistage YAML pipeline defined?
On the resource, such as an environment, not in the YAML file.
Which classic release gate passes only when no alerts are active?
Query Azure Monitor alerts.
Which GitHub feature adds required reviewers and a wait timer before a deployment?
Environment deployment protection rules.
Topic 1 of 2 in Pipelines: testing strategy
Test yourself on Pipelines: testing strategy
The full Microsoft AZ-400 question bank has 766 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Microsoft. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.