What Is Check in DevOps?
On This Page
Quick Definition
A Check is like a security guard for your software releases. It pauses a deployment until certain conditions are met, such as getting approvals from specific people or verifying that another pipeline finished successfully. This helps prevent bad code from reaching production by adding a layer of verification before changes are made live.
Commonly Confused With
Branch policies are rules applied to pull requests in a Git repository, such as requiring a certain number of reviewers or a successful build. Checks, on the other hand, are applied to environments in Azure Pipelines and gate deployments. Branch policies prevent bad code from being merged; checks prevent bad code from being deployed.
A branch policy requires two reviewers before merging a pull request. A check requires a manager to approve before deploying to production.
Gates are defined in classic release pipelines as part of a stage, before or after deployment. Checks are a newer, more flexible feature defined at the environment level and work with both YAML and classic pipelines. Gates are specific to the pipeline definition; checks are reusable across pipelines that target the same environment.
A gate might wait for a test to complete before deployment starts. A check might block deployment entirely if it's outside business hours.
Approval is a specific type of check that requires human sign-off. Check is the broader category that includes approvals plus automated checks like business hours, Azure Functions, and monitor alerts. People often use 'approval' when they mean any check.
An approval check asks a person to click 'Approve'. A business hours check automatically evaluates the current time without human input.
Must Know for Exams
For the AZ-400 exam, checks are a major topic. The exam objectives under 'Design a release strategy' and 'Design a quality strategy' include implementing and managing deployment gates and approvals. You need to know the different types of checks available, how to configure them, and how they integrate with environments. Scenario-based questions often ask you to propose a solution for a specific business requirement, like requiring manager approval for production deployments, or preventing deployments outside of business hours.
You should also understand the difference between checks and other gating mechanisms like branch policies or required reviewers in pull requests. Checks are specific to environments within pipelines. The exam might present a scenario where a team is experiencing failed deployments and you need to troubleshoot why the deployment is stuck. You need to know how to diagnose a pending check and how to manually override it if you have permissions.
Another common exam pattern is to ask how to implement a custom check using Azure Functions. You should know the general approach: create an Azure Function, deploy it, and then add the Invoke Azure Function check to the environment. You might also need to know how to use the Azure DevOps REST API to query checks status. The exam will test your ability to design a secure release pipeline using checks, as well as your understanding of the security implications, such as requiring approval from a different group to satisfy separation of duties.
Simple Meaning
Imagine you are sending a very important package and you want to make sure it arrives safely. Before the delivery truck can leave the warehouse, you might have a checklist: the package must be packed correctly, the address must be verified, and a manager must sign off. If any of these checks fail, the truck stays parked. This is exactly what a Check does in Azure DevOps. It is a gate that a pipeline must pass through before it can deploy software to a specific environment, like a test server or production.
A Check can be simple, like requiring someone to manually approve the deployment. It can be more complex, like checking that another pipeline completed successfully, verifying that a work item is linked to the build, or ensuring that a certain quality gate in a testing tool has passed. The Azure DevOps environment runs the check, waits for the result, and only lets the deployment continue if all conditions are satisfied. If a check fails, the deployment is blocked, and the team gets a notification. This prevents bad releases, reduces risk, and gives teams confidence that every deployment follows the same rules.
In everyday terms, think of a Check as a bouncer at a club. The bouncer checks IDs, makes sure the guest is on the list, and checks for proper attire. If anything is wrong, the guest does not enter. The bouncer is your Check, and the club is the production environment. Without the bouncer, anyone could walk in, and that could cause chaos. With the bouncer, only verified, approved guests get in.
Full Technical Definition
In Azure DevOps, a Check is a policy-based gating mechanism that is evaluated before a deployment job can be executed in a specific environment. Checks are defined at the environment level and can be associated with one or more deployment jobs in a YAML or classic release pipeline. When a pipeline triggers a deployment to an environment that has checks configured, Azure Pipelines pauses the deployment job and evaluates all checks asynchronously. The deployment only proceeds if all checks pass successfully.
Checks can be implemented through a variety of built-in and custom extensions. Built-in check types include Approval, which requires one or more designated users or groups to approve or reject the deployment. Business hours checks restrict deployments to specific time windows. Existence of a branch control ensures that the pipeline is deploying from an approved branch. Invoke Azure Function allows a custom function to run and return a status. Query Azure Monitor alerts checks if there are active alerts that could indicate issues. Required template validates that the pipeline uses a specific YAML template. And Evaluate artifact ensures that an artifact meets defined criteria.
The evaluation of checks is governed by the Azure DevOps environment service. When a deployment is queued, the system creates a record for each check and polls their status. For approvals, a notification is sent to the approvers. For automated checks, the system runs the logic and returns a status of approved, rejected, or pending. Some checks can be configured with a timeout period, after which the check is considered failed. Checks can also be re-evaluated if conditions change, such as an approval being granted later.
Security and compliance are key aspects of checks. They are used in regulated industries to enforce separation of duties, require audit trails, and prevent unauthorized changes. Checks are part of the Azure DevOps governance model and can be integrated with Azure Policy for organizational compliance. For the AZ-400 exam, understanding how to configure and troubleshoot checks is essential for designing secure and reliable release pipelines.
Real-Life Example
Think of a new employee starting at a large company. Before they can enter the building on their first day, several checks must happen. First, HR must confirm they have signed all the paperwork. Then, IT must have set up their computer and badge. Security must have activated their access card. Finally, their manager must approve their start date. Only after all these checks are completed does the employee get an email saying they can start.
In Azure DevOps, this is exactly how a Check works for a deployment. The 'employee' is the new software version. The 'building' is the production environment. HR check could be a manual approval from a senior developer. IT check could be an automated test that verifies the code compiles. Security check could be a policy that ensures the code has no known vulnerabilities. Manager approval is another manual gate. The deployment cannot go live until every check passes.
If any check fails, the deployment is blocked and the team is notified. For example, if the automated security scan finds a critical vulnerability, the check fails, and the deployment stops. The team must fix the issue and rerun the pipeline. This prevents bad code from reaching users, similar to how the new employee cannot start without their badge being ready.
Why This Term Matters
In the real world of IT, deployments are risky. A bad deployment can cause downtime, data loss, security breaches, and unhappy customers. Checks are a critical tool for managing that risk. They enforce your team's policies automatically, so you don't have to rely on humans remembering to do things correctly every time. For example, you can require that every deployment to production must be approved by a senior engineer. This prevents junior developers from accidentally pushing untested code to live users.
Checks also help with compliance. Many industries like finance and healthcare require audit trails for every change. Azure DevOps checks log who approved what and when, providing a clear record for auditors. They also help prevent human error. For instance, a business hours check can stop deployments happening during peak traffic times, even if someone accidentally triggers a pipeline at 3 PM on a busy day.
From a DevOps perspective, checks enable a controlled continuous delivery process. They allow you to automate quality gates without slowing down the whole pipeline. For example, a check can verify that a security scan passed before the deployment proceeds. This means you can have fast automated deployments to dev environments, but strict manual checks for production. This balance between speed and safety is essential for modern software development.
How It Appears in Exam Questions
In the AZ-400 exam, checks appear in scenario-based and multiple-choice questions. A typical scenario might describe a company with multiple environments: dev, test, and production. The question will say that the team wants to ensure that no deployment happens to production on weekends. You need to choose the correct check type to implement that, which would be 'Business hours' check. Another common question: 'A deployment to production is stuck. What should you check first?' The answer is to look at the checks configured on the environment to see if any are pending or rejected.
Another question pattern involves approvals. The scenario might describe a team that requires two people to approve before a deployment, but currently only one is needed. You need to know that you can configure the approval check to require a specific number of approvers. A troubleshooting question might show a screenshot of a deployment stuck with a check icon, and ask what is happening. The correct answer is that a check is pending evaluation.
There are also questions about custom checks. For example, 'Your team wants to run a custom validation script before deploying to production. How should you implement this?' The answer is to create an Azure Function and add an Invoke Azure Function check. You might get a question about the difference between a gate and a check. Gates are defined in the release pipeline definition itself, whereas checks are defined at the environment level and can be shared across multiple pipelines. Understanding this distinction is important for the exam.
Study AZ-400
Test your understanding with exam-style practice questions.
Example Scenario
The company 'WebApp Solutions' uses Azure DevOps to deploy their e-commerce application. They have three environments: Development, Staging, and Production. Their deployment pipeline is fully automated for Dev and Staging, but for Production, they want to add an extra layer of safety. They decide to implement two checks on the Production environment.
First, they add an Approval check that requires the DevOps lead to manually approve every deployment. When a pipeline run reaches the stage that targets Production, it pauses and sends an email notification to the lead. The lead reviews the build details and can either approve or reject. If rejected, the deployment stops and the team knows why.
Second, they add a Business Hours check that only allows deployments between 2 AM and 4 AM on weekdays. This is because their e-commerce site has low traffic during that window, minimizing impact if something goes wrong. If a developer triggers a deployment at 3 PM, the check blocks it until the next allowed window.
One day, a critical bug fix needs to be deployed urgently at 10 AM because the site is down. The DevOps lead goes to the environment and can override the Business Hours check temporarily, since they have the required permissions. They approve the manual approval check, and the deployment goes through. The incident is resolved, and the override event is logged for auditing. This scenario shows how checks provide flexibility while maintaining control.
Common Mistakes
Thinking checks are only for manual approvals.
Checks include many automated types like business hours, Azure Function invocations, and monitor alerts. Limiting checks to only manual approvals misses the broader capability.
Study the full list of checks available in Azure DevOps environments and understand their use cases.
Configuring checks on the pipeline stage instead of the environment.
Checks are defined at the environment level, not the pipeline. If you switch to a different pipeline targeting the same environment, the checks still apply.
Always configure checks on the environment resource, not the pipeline stage definitions.
Assuming checks are evaluated only once at the start of deployment.
Some checks like Query Azure Monitor alerts are evaluated repeatedly at a defined interval until they pass or timeout. They are not a one-time gate.
Understand the evaluation frequency and timeout settings for each check type.
Overlooking the need for proper permissions to bypass checks.
Not all users have permission to approve or override checks. If the wrong person is assigned as an approver, the deployment can be stuck.
Configure approval groups and understand role-based access control for environments.
Confusing checks with branch policies or pipeline conditions.
Branch policies apply to pull requests, not deployments. Pipeline conditions (like 'only run when previous stage succeeded') are different from environment-level checks.
Remember: checks are security gates at the environment level; branch policies are for code quality in version control.
Exam Trap — Don't Get Fooled
{"trap":"A question may state: 'A deployment is waiting for a check. The check is configured with 're-evaluate every 5 minutes' and a timeout of 10 minutes. After 8 minutes, the check finally passes.
What happens to the deployment?' The trap answer is 'The deployment fails because the timeout expired.'","why_learners_choose_it":"Learners confuse the re-evaluation interval with the timeout.
They think that if a check takes longer than the interval, it will be forced to fail.","how_to_avoid_it":"Remember that the re-evaluation interval is how often Azure DevOps re-runs the check logic. The timeout is the maximum total time the check can take.
If the check passes before the timeout, the deployment proceeds. In this case, it passed after 8 minutes, which is within the 10-minute timeout, so it works."
Step-by-Step Breakdown
Define an Environment
In Azure DevOps, environments are logical containers for resources like virtual machines or Kubernetes clusters. You create an environment (e.g., 'Production') to which you will later add checks.
Add Check to Environment
On the environment page, you add one or more checks. For example, select 'Approvals' and specify the approver group. This check is now active for all pipelines targeting this environment.
Trigger a Deployment
When a pipeline runs and reaches a stage that deploys to the environment, Azure DevOps sees the checks and pauses the deployment job. It creates a record for each check.
Evaluate Checks
The system evaluates each check. For manual checks like approvals, it sends a notification to the approvers. For automated checks, it runs the logic. The status of each check is tracked as pending, approved, rejected, or failed.
Await Approval or Automated Result
The pipeline waits until all checks pass. If a human approver rejects, the deployment fails. If an automated check times out, it fails. You can see the status in the pipeline run view.
Proceed or Block
If all checks pass, the deployment continues. If any check fails, the deployment is blocked and does not proceed to the environment. The team can investigate and re-trigger the deployment after fixing the issue.
Log and Audit
All check evaluations are logged, including who approved or why a check failed. This provides an audit trail for compliance and debugging.
Practical Mini-Lesson
In practice, using checks effectively requires planning. The first step is to identify what gates are needed for each environment. For a development environment, you might not need any checks, or you might only want a simple automated test check. For production, you likely want multiple checks: an approval from a release manager, a business hours check to only deploy during off-peak hours, and a query Azure Monitor alerts check to ensure no critical alerts are active.
Configuring these checks is straightforward in the Azure portal. For approvals, you choose users or groups and can require a minimum number of approvers. For business hours, you define the allowed days, times, and time zone. For custom checks with Azure Functions, you need to write and deploy the function first, then configure the check to call it with appropriate parameters such as the build ID and environment name.
What can go wrong? Common issues include: the approval is sent to a user who is on vacation, causing delays. To avoid this, use a group instead of an individual. Another issue is a timeout on an automated check because the Azure Function is slow or unavailable. Always set a reasonable timeout and monitor the function's performance. Also, checks can be bypassed by users with appropriate permissions, but that bypass is logged. Make sure only trusted people have that power.
For AZ-400, you should also know how to use the REST API to query the status of checks, which can be useful for building custom dashboards. For example, GET https://dev.azure.com/{organization}/{project}/_apis/pipelines/checks?api-version=7.0. Understanding this helps in troubleshooting and automation.
Another advanced practice is using checks with deployment slots in Azure App Service. You can create a check that requires a slot swap to be approved, adding a manual gate before the swap goes live. This is a common pattern for blue-green deployments.
checks are a powerful governance tool. They reduce risk, enforce compliance, and give teams confidence in their releases. The best practice is to start with simple approvals, then add automated checks as your maturity grows.
Memory Tip
Check the Environment, not the Pipeline. Checks gate the deployment destination.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Related Glossary Terms
A/B testing is a controlled experiment that compares two versions of a single variable to determine which one performs better against a predefined metric.
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
AAA (Authentication, Authorization, and Accounting) is a security framework that controls who can access a network, what they are allowed to do, and tracks what they did.
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
An A record is a type of DNS resource record that maps a domain name to an IPv4 address.
Frequently Asked Questions
Can I use checks in YAML pipelines?
Yes, checks work with both YAML and classic release pipelines. You define the checks on the environment, and any pipeline that deploys to that environment will evaluate them.
Can I override a check if it's blocking a deployment?
Yes, users with the 'Administrator' role on the environment can manually re-evaluate or bypass a check. This is useful for urgent fixes.
What happens if a check times out?
If a check does not complete within its configured timeout period, it is marked as failed and the deployment is blocked. You can adjust the timeout when creating the check.
Are checks evaluated in a specific order?
Checks are evaluated in parallel by default. The deployment only proceeds when all checks have passed. There is no configurable order.
Can I use the same check across multiple pipelines?
Yes, because checks are defined on the environment, not on a specific pipeline. Any pipeline that deploys to that environment will use the same checks.
How do I troubleshoot a deployment stuck on a check?
Go to the pipeline run, click on the stage that is stuck, and look for the 'Checks' section. It will show the status of each check, including any pending approvals or errors.
Summary
A Check in Azure DevOps is an environment-level gate that evaluates predefined conditions before allowing a deployment to proceed. It can be a manual approval, an automated verification like business hours, or a custom logic via Azure Function. Checks are essential for maintaining deployment safety, ensuring compliance, and reducing risk in continuous delivery pipelines.
For the AZ-400 exam, you need to understand the difference between checks, gates, and branch policies. You must be able to configure common checks like approvals and business hours, and troubleshoot deployment issues related to pending checks. Questions often test your ability to choose the right check type for a given scenario and to interpret why a deployment is stuck.
In practice, start with simple manual approvals for production, then add automated checks as your process matures. Always use groups for approvals to avoid single points of failure. Remember that checks are a powerful tool for governance, and their configuration is critical for a secure DevOps workflow.