# Release approval

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/release-approval

## Quick definition

A release approval is a gate that must be passed before a software update is deployed to a production or staging environment. It ensures that the right people or automated checks review and authorize the release. This process helps prevent errors and maintains quality control during deployments.

## Simple meaning

Think of a release approval like a bouncer at a private event. The bouncer doesn't let anyone inside the venue without checking their invitation and ID first. In software development, a release approval acts like that bouncer for your code. A team of developers finishes building a new feature, like a new payment button on a website. Before that button goes live for customers, someone must press the "OK" button. That someone might be a senior developer, a project manager, or even an automated testing tool. If they approve, the feature moves forward to the production server. If they reject it, the code goes back for fixes. This checkpoint is not just about saying yes or no. It also verifies that all tests passed, security checks are clear, and the deployment follows company policies. Without release approvals, teams could accidentally push broken or insecure updates to users. In large organizations, multiple approvals may be required before a release reaches the public. For example, a test environment approval might come from a quality assurance lead, while a production approval might come from a release manager. Each approval adds a layer of safety. The process is also documented for audits, which is important for industries like finance or healthcare. So, a release approval is a simple but powerful way to control what goes live and when, making sure only safe, tested, and authorized updates reach the users.

## Technical definition

In Azure DevOps, a release approval is a gate defined in a release pipeline that pauses the pipeline execution at a pre-deployment or post-deployment stage until the required approvals are granted. This mechanism enforces governance and compliance by requiring explicit authorization from specified users or groups before a release proceeds to a particular environment, such as staging or production. The approval process is configurable within the release pipeline editor. A typical approval gate can be set for a specific environment, where the pipeline will stop and wait for one or more approvers to review the release summary, check artifacts, and either approve or reject the request. The approval request is sent via email notification, and the approver can respond through the Azure DevOps web interface or mobile app. Multi-stage approval chains can be created, where the release must pass each approval gate sequentially. For example, a release may require approval from the QA team before moving to staging, and then from the release manager before moving to production. Timeouts can be configured: if an approver does not respond within a set period, the release can be automatically rejected or marked as timed out. Azure DevOps also supports automated approval gates, such as checking that a certain number of tests passed in the previous stage, or that no critical work items are unresolved. These automated gates use pre-hooks and post-hooks to run checks that must succeed for the pipeline to continue. The approval history is stored in the release log, providing an audit trail for compliance. In a real IT implementation, release approvals are often integrated with organizational change management processes, where a change request ticket must be referenced in the approval notes. Azure DevOps also supports deferred approvals, where an approver can schedule a release to proceed at a future time. This is useful for planned deployments during maintenance windows. The approval process can be extended with Azure Functions or webhooks to trigger external workflows, such as notifying a monitoring tool or updating a configuration management database. The approval policy can enforce that all members of a security group must approve, or that any single member of a group can approve. Understanding the difference between pre-deployment and post-deployment approvals is crucial: pre-deployment approvals happen before a stage runs, while post-deployment approvals occur after the stage has completed but before promoting to the next stage. This technical control prevents unauthorized changes from reaching production and ensures that each release is vetted by the appropriate stakeholders.

## Real-life example

Imagine you are the owner of a popular food truck that serves gourmet tacos. You have a team that helps cook, but you want to ensure every new recipe is tested before it goes on the menu. You create a process: the chef first creates a new taco recipe in the test kitchen (like a development environment). Then, before that recipe can be offered to customers, you require two approvals. First, the sous chef must taste the taco and approve it. That is like a test environment approval in Azure DevOps. If the sous chef thinks the taco is too spicy, they reject it, and the chef tweaks the recipe. Once approved, the recipe moves to the main food truck kitchen (staging environment), but it still cannot be sold yet. You, as the owner, must give a final approval. You might check the cost of ingredients, the preparation time, and if it fits with the current menu. Only after you approve does the taco appear on the menu for customers (production environment). This process ensures that no strange taco reaches a paying customer without quality checks and proper authorization. Each approval step is like a gate that prevents a bad batch from ruining your reputation. In the software world, release approval works exactly like this food truck approval chain. The code goes through different stages, and at each stage, a designated person or automated check must say "Go" before it moves forward. This ensures the final product is safe, tested, and approved by the right people before users see it.

## Why it matters

Release approval matters because it directly impacts the reliability and security of software deployments. In a professional IT environment, even a small coding error can bring down a critical service, leak sensitive data, or cause financial loss. Release approvals act as a safety net that catches these problems before they affect users. For example, a financial institution deploying a new transaction processing system must ensure that all regulatory compliance checks are passed. An approval gate can require that a compliance officer reviews the release notes and signs off before the deployment proceeds. Without this gate, a developer might accidentally bypass checks and push an update that violates data protection laws. In DevOps culture, speed is important, but so is control. Release approvals strike a balance by allowing fast automated pipelines while still enforcing manual checks where needed. This is especially important in large organizations with multiple teams, where one team might not be aware of changes made by another team. The approval process creates a moment of coordination and review. It also provides an audit trail that can be used for incident post-mortems or regulatory audits. If a deployment causes an outage, the logs will show who approved the release and what checks were performed. This accountability encourages thorough review. For IT professionals, understanding release approvals is essential because they will likely be asked to approve releases in their role, or they may need to configure these gates in Azure DevOps pipelines. It is not just a technical feature; it is a governance tool that aligns with industry standards like ITIL and change management best practices. Ignoring approval gates can lead to chaos, where untested code goes straight to production, increasing the risk of downtime and customer dissatisfaction.

## Why it matters in exams

For general IT certification exams, especially those covering Azure DevOps (like the Azure DevOps Solutions certification AZ-400) and change management topics in ITIL Foundation, release approval is a core concept. In the AZ-400 exam, candidates must understand how to implement release approval gates, configure pre-deployment and post-deployment approvals, and set up automated quality gates. Questions may ask about the difference between manual and automated approvals, how to set up approval groups, and how to handle approval timeouts. In ITIL Foundation exams, release approval is often discussed under release and deployment management, focusing on the formal authorization required before a release is deployed to production. The concept also appears in PMP (Project Management Professional) exams when discussing change control boards and release management. In questions, you might see scenarios where a release fails due to an unresolved approval, or where an approver is unavailable and the pipeline must automatically reject the release. Exam takers need to know that release approvals can be configured per environment, that approval groups can include multiple users, and that the approval request is sent via email. They should also understand that post-deployment approvals are used for validation after the release is deployed to a stage, allowing manual testing or smoke tests before promoting to the next stage. Another common exam topic is the difference between approval gates and deployment gates. Deployment gates (like checking Azure Monitor metrics) are automated, whereas approval gates are typically manual. However, Azure DevOps also supports automated approval gates using Azure Functions. For the AZ-400 exam, candidates should be able to design a release pipeline that includes both manual and automated approval gates to meet compliance requirements. They might also need to know how to link a release approval to a work item or change request in Azure Boards. Release approval is a frequent topic in exam questions about release strategy, quality assurance, and deployment control. Mastery of this concept is necessary to pass related certification exams.

## How it appears in exam questions

Release approval appears in exam questions primarily in three patterns: scenario-based, configuration-based, and troubleshooting-based. In scenario-based questions, you are given a business requirement. For example, "Your company requires that all production deployments be approved by the release manager. You need to configure the Azure DevOps release pipeline to enforce this. What should you do?" The answer would involve setting a pre-deployment approval on the production environment and adding the release manager as an approver. Another scenario: "The QA lead wants to approve releases to the staging environment only after all unit tests pass. How can you implement this?" The correct answer is to configure a post-deployment approval gate on the QA environment with the QA lead as the approver. Configuration-based questions ask you to identify the correct settings. For instance, "Where do you configure release approvals in Azure DevOps?" Options might include Pipeline settings, Environment approvals, or Release definition. The correct answer is Environment approvals. They may ask, "What is the difference between pre-deployment and post-deployment approvals?" Pre-deployment approvals occur before a stage runs, while post-deployment approvals occur after the stage completes. Troubleshooting-based questions present a problem. For example, "A release is stuck waiting for approval, but the approver has not received an email. What is the most likely cause?" The answer might be that the approver's email address is not configured in Azure DevOps profile, or the notification settings are disabled. Another troubleshooting question: "A release timed out waiting for approval. What does that mean?" It means the timeout period configured for the approval expired, and the pipeline automatically rejected the release. Candidates must also know how to override a pending approval if they have the appropriate permissions. This is a common trap: only users with the "Manage approvals" permission can override an approval. In short, exam questions focus on the practical application of release approvals, the configuration options, and the implications of approval settings on pipeline behavior.

## Example scenario

Contoso Ltd. is a software company developing a customer portal. They use Azure DevOps for CI/CD. The team has three environments: dev, staging, and production. The company policy states that every release to production must be approved by the release manager, Sarah. Also, any release to staging must first be approved by the QA lead, Mike. Sarah is on vacation, and a critical bug fix needs to go to production urgently. The team lead, John, asks how to proceed. The correct solution is to either wait for Sarah to return, or if John has the necessary permissions, he can temporarily add himself as an approver on the production environment, but only if the change management board approves. In the exam scenario, this tests knowledge of approval configuration and permissions. Another scenario: The team configures a release pipeline with two stages. The first stage deploys to staging. They set a pre-deployment approval gate for staging. Mike the QA lead receives an email notification with a link to approve or reject. He reviews the release summary and sees that all tests passed. He clicks "Approve." The pipeline then proceeds to deploy to staging. After the staging deployment, they have a post-deployment approval gate for production. Sarah receives the approval request. She reviews the release notes and checks that the staging deployment was successful. She approves, and the pipeline promotes the release to production. This simple scenario illustrates the sequential nature of approvals. A common exam scenario question: "You need to ensure a release cannot proceed to production unless the staging deployment has completed successfully and a manual approval is given. How should you configure the pipeline?" The answer is to set a post-deployment approval on the staging environment with the production environment approvers. This ensures the approval happens after staging succeeds but before production deployment. Understanding this sequencing prevents mistakes in pipeline design.

## Common mistakes

- **Mistake:** Thinking approval gates apply to the entire pipeline rather than to specific environments.
  - Why it is wrong: Approval gates are associated with individual environments (staging, production) inside a release pipeline. Each environment can have its own set of approvals.
  - Fix: Configure approvals per environment in the Azure DevOps release pipeline editor by clicking the environment and selecting 'Pre-deployment approvals' or 'Post-deployment approvals'.
- **Mistake:** Assuming email notification for approval is sent to every team member automatically.
  - Why it is wrong: Only users or groups explicitly configured as approvers for that environment receive the email notification. The email is sent to the approver(s) listed in the approval settings.
  - Fix: Ensure you add the correct users or security groups to the approver list for each environment.
- **Mistake:** Believing that automated approval gates (like check for passing tests) are the same as manual approvals.
  - Why it is wrong: Manual approvals require a human to click approve or reject, while automated gates are conditions that are checked automatically by the pipeline without human intervention.
  - Fix: Understand that both can be combined: you can have an automated gate that checks test results and a manual approval that requires a person to sign off.
- **Mistake:** Thinking that a release can proceed even if the approval times out and no one responded.
  - Why it is wrong: When the timeout period expires without a response, the release is automatically rejected (or marked as timed out), and the pipeline does not proceed.
  - Fix: Set appropriate timeout values based on how long approvers typically take to respond. For critical issues, consider shorter timeouts or ensure backup approvers are configured.

## Exam trap

{"trap":"The question might ask: 'You need to configure an approval that must be granted by all members of a security group. What should you set?' The trap is that learners might think 'any one member' is the default behavior.","why_learners_choose_it":"Because in many team-based approval systems, any single member can approve. Azure DevOps defaults to 'Any member of the group' can approve, which is a common trap.","how_to_avoid_it":"If the requirement is that all members must approve, you need to select 'All members of the group' in the approval options. Read the requirement carefully. For exam, remember the two modes: 'Any' vs 'All'."}

## Commonly confused with

- **Release approval vs Deployment gate:** A deployment gate is an automated check (e.g., monitoring metrics, passing tests) that the pipeline evaluates before proceeding. A release approval is a manual action where a person decides. They are both gates but different in execution. (Example: If a pipeline checks that CPU usage is below 90% before deploying, that is a deployment gate. If a pipeline waits for Sarah to click 'Approve', that is a release approval.)
- **Release approval vs Change approval (in ITIL):** Change approval in ITIL is a broader concept that involves a change advisory board (CAB) reviewing and authorizing a change request. Release approval in Azure DevOps is a specific technical control within the CI/CD pipeline. ITIL change approval is more about process and documentation. (Example: A company might have an ITIL change approval requiring a CAB meeting to authorize a major software upgrade. Then, the Azure DevOps pipeline uses release approval to enforce the technical gate before the actual deployment.)
- **Release approval vs Approval in code review:** Code review approval is about accepting code changes into a branch (e.g., pull request approval). Release approval is about deploying already committed code to an environment. They happen at different stages of the development lifecycle. (Example: A developer's pull request must be approved by a peer before merging to the main branch (code review approval). Later, when that code is to be deployed to production, a release manager must approve it (release approval).)

## Step-by-step breakdown

1. **Create release pipeline** — First, you create a release pipeline in Azure DevOps that defines the stages of deployment, such as dev, staging, production.
2. **Select environment to add approval** — Click on the environment (e.g., 'Production') where you want to enforce an approval gate. This opens the environment settings.
3. **Configure pre-deployment or post-deployment approval** — Decide whether the approval should be required before the deployment runs (pre-deployment) or after the deployment completes but before promoting to next stage (post-deployment). Check the corresponding checkbox.
4. **Add approvers** — Add specific users or security groups that are authorized to approve. Set whether any one member of the group can approve, or all members must approve.
5. **Configure timeout and policies** — Set a timeout period (e.g., 8 hours) after which the approval request expires. Optionally, set policies like 'Resend notification' or 'Allow approver to defer'.
6. **Save and create release** — Save the pipeline configuration. When a release is triggered, the pipeline will pause at the approval gate and send email notifications to the approvers.

## Practical mini-lesson

Release approvals are a central feature for any IT professional managing Azure DevOps pipelines. In practice, you will often work with multi-environment release pipelines where each environment has different approval requirements. For example, a typical company might have a dev environment with no approvals for fast iteration, a staging environment requiring QA lead approval, and a production environment requiring both a release manager approval and an automated check that all critical tests pass. Configuring this in Azure DevOps is straightforward but requires attention to detail. When you set a pre-deployment approval on the Production environment, the pipeline will stop before running the deployment script. This allows the approver to review the release summary, including the associated work items, commits, and test results. The approver can also leave comments explaining their decision. This is important for audit trails. In real-world scenarios, it is common to set up approval groups that include multiple people to avoid bottlenecks when someone is out of office. Also, you can configure the approval settings to require approval from all members of a security group, which is useful for compliance-heavy environments. A common mistake is forgetting to set the timeout. If the timeout is too short, approvals might expire during weekends; if too long, releases can be stuck waiting for days. A good practice is to set a timeout of 8-12 hours for production approvals, and configure notifications to escalate if not approved within half that time. Another practical consideration is the use of post-deployment approvals for validation checks. For instance, after deploying to staging, you might have a post-deployment approval gate that requires the QA team to run manual smoke tests and then approve before the pipeline moves to production. This adds a layer of human validation that automated tests cannot replace. Professionals need to balance speed and control. Using release approvals effectively means configuring the right approvers, timeouts, and policies to ensure safe deployments without creating excessive delays.

## Memory tip

Remember: 'Pause for People', release approvals pause the pipeline for human approval before deployment.

## FAQ

**Can I set a release approval that requires approval from multiple people?**

Yes, in Azure DevOps you can require approval from all members of a security group, or any single member. Configure this in the environment approval settings.

**What happens if an approver does not respond to the approval request?**

If the timeout period expires without a response, the release is automatically rejected or marked as timed out, and the pipeline does not proceed.

**Can I configure automated release approvals?**

Yes, you can set automated approval gates that check conditions like test results or monitoring metrics. These run without human intervention.

**How do approvers receive notification about pending approvals?**

Approvers receive an email notification from Azure DevOps with a link to the approval portal. They can also see pending approvals in the Azure DevOps web interface.

**Can an approver defer an approval to a later time?**

Yes, if the policy allows it, approvers can defer an approval to a specific future time, which is useful for scheduling deployments during maintenance windows.

**Can I edit the approval configuration after a release is created?**

Yes, you can edit the approval settings in the release pipeline definition, and those changes apply to future releases. However, changes do not affect releases that are already queued or in progress.

## Summary

Release approval is a fundamental control mechanism in Azure DevOps that ensures software deployments are authorized and validated before proceeding to critical environments. It acts as a manual or automated gate that pauses the release pipeline, requiring verification from specified people or checks before moving forward. For IT certification learners, especially those preparing for Azure DevOps or ITIL exams, understanding release approvals is crucial because they appear frequently in questions about pipeline configuration, change management, and deployment control. The concept teaches the balance between speed and safety in modern software delivery. Key takeaways include knowing the difference between pre-deployment and post-deployment approvals, configuring approvers and timeouts, and troubleshooting common issues like missed notifications or timed-out approvals. In practice, release approvals provide an audit trail, enforce compliance, and prevent unauthorized or untested code from reaching users. They are not just a technical checkbox but a governance tool that aligns with industry standards. On exams, candidates should be prepared to design approval workflows, interpret scenario-based questions, and identify configuration settings. Ultimately, mastering release approvals helps professionals build reliable, controlled deployment pipelines that deliver value safely.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/release-approval