The 'Design a release pipeline' domain on the AZ-400 exam asks you to become the architect of how software travels from a developer’s laptop to users’ hands. Instead of manually copying files or hoping nothing breaks, you need a blueprint for automated, safe, and predictable delivery. Think of it as writing the instruction manual for a robot that prepares, tests, and serves your software – every single time, without errors.
Jump to a section
A simple way to picture Designing a Release Pipeline
Have you ever wondered how a wedding caterer guarantees that hundreds of guests all get their hot, perfectly-cooked meals at the same time, without the kitchen descending into chaos?
The caterer’s process is a perfect analogy for 'Designing a Release Pipeline'. The ‘starter code’ is the raw ingredients (your application code). The ‘build server’ is the prep kitchen where vegetables are chopped and sauces are prepped (the code is compiled and tested). The ‘release pipeline’ is the entire orchestrated cooking and service plan: each course (environment) is a separate stage – starter (development), main course (staging), dessert (production). The ‘approval gate’ is the head chef tasting the sauce before it leaves the kitchen, and the ‘automated rollback plan’ is the emergency plan if a dish comes out burnt. The caterer doesn’t just hope the meal goes well; they design a repeatable, reliable sequence of checks and handoffs, from prepping ingredients to plating the final course. This ensures that every wedding (every deployment) is consistent, safe, and on time, no matter how large or complex the menu (the application).
A release pipeline is an automated process that defines how your software moves from its source code form to a live, running application that users can access. Imagine you are running a bakery. You have a recipe (your source code) and you need to bake a cake, wrap it, and deliver it to a customer. Without a pipeline, you would do every step by hand: mix ingredients, bake, check if it tastes good, wrap it, and drive it over. If you get 1,000 orders, you would collapse from exhaustion. A release pipeline automates all those steps.
In technology, a ‘release’ is the finished, packaged version of your software, ready to be installed or served. A ‘pipeline’ is a sequence of stages (like checkpoints) that your release travels through. Each stage performs a specific job. The most common stages are:
Build: The source code is compiled (turned from human-readable code into machine-executable instructions) and packaged into a single file or container, like a .zip file or Docker image.
Test: Automated tests run to check that the software works correctly. If a test fails, the pipeline stops.
Deploy to a pre-production environment: The release is put into a copy of the real-world system (called 'staging' or 'UAT' – User Acceptance Testing) where it can be tested safely without affecting real users.
Approve: A human (or an automatic policy) checks that everything looks good before moving to production.
Deploy to production: The release is finally sent to the live environment where users see it.
Why does this matter for AZ-400? The exam tests how to design these stages, how to add gates (checks) that prevent bad releases, and how to configure variables (like different server addresses for test vs. production) without hard-coding secrets. A core concept is ‘release strategy’ – for example, you might deploy to a small subset of users first (a 'canary' release) and then gradually increase that percentage. This minimises risk.
The pipeline replaces the old, chaotic ‘scream test’ approach, where a developer would manually upload a file to a server and yell “Is it working?” Instead, you define an ‘artifact’ – the output of a build, like a package – and then connect that artifact to a release pipeline. Azure Pipelines (part of Azure DevOps) uses a YAML (Yet Another Markup Language) file or a visual designer to define this flow. This is not a suggestion; it is a blueprint. When you ‘design a release pipeline’ for the exam, you are deciding which stages exist, what triggers them (e.g., every time a new build finishes), and what conditions must be met to proceed.
You also need to understand ‘environment’ – a logical grouping of compute resources where your software runs. ‘Development’, ‘Test’, ‘Stage’, ‘Production’ are typical environments. Each environment can have its own ‘deployment job’ that uses variables and secrets (passwords) appropriate for that environment. The pipeline automatically injects the right values. This eliminates the error of manually typing a test password into production.
The pipeline also defines ‘deployment strategy’ – the method you use to move the software to a server. ‘Blue-green deployment’ is one where you have two identical environments (blue and green). You deploy the new release to the inactive environment, switch traffic over, and if something goes wrong, you switch back. ‘Rolling deployment’ updates servers one by one, so users never see downtime. ‘Canary deployment’ sends the new version to a small percentage of users first. The exam loves asking you to choose the right strategy based on a scenario – for instance, if zero downtime is required, you would choose blue-green.
Finally, a pipeline includes ‘approvals and gates’. An ‘approval’ is a human check, like a manager clicking ‘Approve’ before the release goes to production. A ‘gate’ is an automated health check – for instance, the pipeline might query an application monitoring service to see if the error rate is below a threshold before proceeding. If the gate fails, the pipeline pauses or stops. This is how you design a pipeline that is not just a one-way conveyor belt, but a safe, controlled progression of changes.
1. Define the artifact source
Choose where your pipeline will get the software package to deploy. This is typically a build pipeline in Azure Pipelines, but it can also be an Azure Container Registry or a GitHub release. This step determines what triggers the release.
2. Create the stages for each environment
Define logical stages like ‘Dev’, ‘Test’, ‘Staging’, and ‘Production’. Each stage represents a deployment to a specific environment. You can add a stage for ‘Approval’ or ‘Health Check’. The order of stages matters because a release flows from top to bottom.
3. Configure deployment strategy per stage
For each stage, choose how you want to deploy the artifact to the environment. Options include: ‘runOnce’ (deploy to all resources at once), ‘rolling’ (update a subset at a time), ‘blue-green’ (swap between two identical environments), or ‘canary’ (incrementally shift traffic). This decision strongly affects downtime and risk.
4. Set up pre-deployment and post-deployment approvals
Add human approvals to stages where manual oversight is required, such as before releasing to production. You can require approval from one or multiple users. Post-deployment approvals can be used to approve moving to the next stage after a deployment completes.
5. Add gates (automated health checks)
Gates automatically evaluate a condition before or after a deployment. For example, you can add a gate that queries Azure Monitor to confirm the error rate is below a threshold. If the gate fails, the pipeline pauses or stops, preventing a bad release from reaching users.
6. Configure variables and service connections
Define variables for settings that change between environments, such as database connection strings, API endpoints, or storage account names. Link the pipeline to Azure services using service connections (like an Azure Resource Manager service connection) so it has permission to deploy.
7. Set up release triggers and retention policies
Decide what starts the pipeline: a new artifact (continuous deployment trigger), a scheduled time, or a manual launch. Also set how many old releases to keep (retention) to save storage and maintain compliance.
Consider a global retail company that releases its mobile app every two weeks. Without a release pipeline, the team would manually build the app on one developer's laptop, upload the file to a shared drive, and then a different person would manually upload it to the app store – a process full of errors and delays.
With a designed release pipeline, the process looks like this:
The developer commits new code to a Git repository in Azure Repos. This commit automatically triggers a build pipeline (the continuous integration part).
The build pipeline compiles the iOS and Android versions, runs 10,000 automated tests, and outputs a signed package as an artifact.
That artifact is automatically picked up by the release pipeline. The first stage deploys the package to a ‘Test’ environment running on virtual machines in Azure. Here, quality assurance (QA) testers manually test new features. They also have automated UI tests running in parallel.
After QA signs off, the pipeline waits for a manager to approve deployment to a ‘Staging’ environment, which mirrors production exactly. In staging, a ‘gate’ checks that the Staging site’s homepage loads within 2 seconds. If it doesn’t, the pipeline stops.
After the gate passes, the pipeline uses a ‘rolling deployment strategy’ to update the production servers. It updates 5% of the server fleet, monitors for errors for 10 minutes (another gate), then updates the next 10%, and so on. If at any point the error rate spikes, the pipeline automatically triggers a rollback – it reverts the 5% of servers back to the previous version.
Finally, the pipeline sends a notification to the entire engineering team: ‘Release v2.1 is live’.
What does the IT professional do? They open Azure Pipelines and define this flow using the visual editor or a YAML file. They set up ‘variable groups’ in Azure DevOps Library to store database connection strings for each environment, and mark them as secret. They configure ‘service connections’ (like the credentials that allow Azure DevOps to talk to Azure App Service). They write the conditions for gates – for example, using Azure Monitor queries to check performance. They also design the ‘deployment strategy’ by choosing between ‘runOnce’, ‘rolling’, or ‘canary’ in the pipeline settings.
This real-world scenario shows that a release pipeline is not an abstract concept; it is a daily tool that saves companies from costly outages. The AZ-400 exam expects you to know the differences between these strategies and when to use each one, and to be able to read a pipeline YAML file and spot design flaws.
The AZ-400 exam tests your ability to design a release pipeline by presenting you with business requirements and asking you to choose the correct pipeline structure. You will not be asked to write a YAML file from memory, but you will need to read and interpret one.
The core exam topics for this section are: - ‘Deployment strategies’: blue-green, canary, rolling, and feature toggles (flags that turn features on/off without deploying new code). The exam will give you a scenario with requirements like “zero downtime during deployment” or “instant rollback” – you must pick the right strategy. - ‘Approval and gate strategies’: when to use pre-deployment approvals (before deploying to an environment) vs. post-deployment approvals (after deploying). Gates typically use metrics from Azure Monitor or other monitoring tools. - ‘Release triggers’: continuous deployment trigger (each new build triggers a release) vs. scheduled trigger vs. manual trigger. The question might say “deploy to production only on Fridays at 2AM” – you would choose scheduled trigger. - ‘Artifact sources’: the exam tests that you know a release pipeline picks up artifacts from a build. Common sources are Azure Repos Git, GitHub, and Azure Container Registry. - ‘Environment configuration’: how to use variables and secrets, how to link pipeline stages to different Azure subscriptions, and how to use ‘service connections’.
Common traps in the exam:
They will list a deployment strategy that sounds plausible but is wrong. For example, they might describe a canary deployment as “deploying to all servers at once” – that is actually a rolling or blue-green context, not canary. Learn the precise definitions.
They will offer a ‘multi-stage pipeline’ design where a gate checks something before the wrong step, e.g., checking the production site health before deploying to staging. You must identify that the gate is in the wrong stage.
They will trick you on ‘approval policies’: an approval can be set at the environment level, not the pipeline level. So if you need a manager to approve all production deployments, you configure a pre-deployment approval on the production environment.
They will test your understanding of ‘re-deployment’: if a deployment fails, the pipeline can be retried from the point of failure. They may ask what happens to the artifact version – the same artifact is redeployed, not a new build.
Key definitions to memorise:
Artifact: the packaged output of a build (e.g., .zip, .nupkg, Docker image).
Stage: a logical unit in the pipeline (e.g., Build, Test, Deploy-Production).
Job: a set of steps that run on an agent (a machine that executes pipeline tasks).
Variable: a name-value pair that can be passed to pipeline tasks.
Secure file: a file (like a certificate) uploaded to Azure Pipelines that is protected.
Environment: a collection of resources (VMs, Kubernetes clusters) where you deploy.
The exam expects you to understand the relationship between build and release: a build pipeline creates artifacts, a release pipeline consumes them. You must know that a release pipeline can be triggered by the completion of a build pipeline. This is the continuous delivery (CD) part of the CI/CD chain.
A release pipeline automates the deployment of an artifact through multiple environments, each with specific checks and gates.
Artifacts are the immutable output of a build pipeline; once built, the same artifact should be deployed through all environments without recompilation.
Deployment strategies (blue-green, rolling, canary) are chosen based on business requirements like zero downtime, instant rollback, or gradual rollout.
Secrets must never be stored in YAML files or source code; use Azure Key Vault or secret variables linked to the pipeline.
Approvals and gates are not the same: approvals require a human to click 'Approve', while gates are automated health checks against monitoring metrics.
The exam tests your ability to read a multi-stage pipeline YAML and identify missing stages, incorrect deployment strategies, or misplaced gates.
Each environment in a pipeline can have its own set of variables and service connections, allowing the same pipeline to work across dev, test, and production without code changes.
A post-deployment gate can monitor the health of the recently deployed environment and trigger an automatic rollback if conditions are not met.
These come up on the exam all the time. Here's how to tell them apart.
Pre-deployment approval
Occurs before the deployment starts.
Approves that the release is ready to go into an environment.
Example: manager must click 'Approve' before deploying to production.
Post-deployment approval
Occurs after the deployment finishes.
Approves that the release can proceed to the next stage.
Usually used for manual testing sign-off after a deployment.
Blue-green deployment
Traffic is switched in an instant between two identical environments.
Rollback is immediate by switching traffic back to the previous environment.
All users see the new version at the moment of switch.
Canary deployment
Traffic is shifted gradually (e.g., 1%, then 10%, then 50%, etc.).
Rollback is slower because you must shift traffic back incrementally.
Only a subset of users sees the new version initially, allowing real-user monitoring.
Rolling deployment
Updates servers in batches (e.g., 20% at a time).
Requires only one production environment; no duplicate infrastructure needed.
Rollback requires redeploying the old version in batches.
Blue-green deployment
Updates all servers at once by switching traffic between two environments.
Requires double the infrastructure (two full environments) during switchover.
Rollback is immediate by flicking traffic back to the previous environment.
Artifact (build output)
The immutable package produced by a build pipeline.
Contains compiled code, assets, and metadata.
Does not change once built.
Release (deployment instance)
An execution of a release pipeline that deploys an artifact to environments.
Has a state (in progress, succeeded, failed, rolled back).
Multiple releases can exist from the same artifact.
Mistake
A release pipeline and a build pipeline are the same thing.
Correct
A build pipeline compiles and tests code and produces an artifact. A release pipeline takes that artifact and deploys it through environments (e.g., dev, staging, production). They are separate but connected stages of the CI/CD process.
The terms CI (continuous integration, build) and CD (continuous delivery, release) are often said together as CI/CD, leading beginners to assume they are a single step. The exam deliberately tests the distinction.
Mistake
I can hardcode database passwords in my pipeline YAML file because only the DevOps team will see it.
Correct
Secrets and passwords must never be stored in YAML files or source control. They should be stored in Azure Key Vault and referenced via a variable group link, or set as secret variables in the pipeline library. Hardcoding secrets is a security violation.
Newcomers think that because their repo is private, it is safe. They haven't yet learned that any user who can view the repo can see the secret, and that secrets can leak if the code is accidentally shared or audited.
Mistake
If a deployment to production fails, I must rebuild the entire application from source code and create a new artifact.
Correct
You can re-run the release pipeline with the existing successful artifact. The problem is in deployment, not the build. You fix the deployment script or environment, then redeploy the same artifact.
Beginners conflate the build and release steps, thinking that any failure demands starting over. The exam tests the idea that the artifact is immutable once built.
Mistake
A 'canary deployment' means you deploy the new version to all servers at once but at night.
Correct
A canary deployment sends the new version to a small subset of servers or users (the 'canary') first, monitors for issues, and then gradually rolls out to the rest. This minimises impact if the release has a bug.
The word 'canary' is unfamiliar, and beginners guess that it means something fast or stealthy. The actual origin (canary in a coal mine) is about early warning, which maps to rolling out to a small group first.
Mistake
Approval gates must be placed on every stage of the pipeline to be safe.
Correct
Approvals should be placed only on stages that require human oversight, typically pre-production and production. Putting approvals on every stage (e.g., test stage) slows down the process unnecessarily. Automated gates (health checks) are better suited for non-production stages.
Beginners want maximal human control because they don't trust automation. The exam teaches that a good design balances safety with speed, using gates only where risk is high.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A build pipeline (CI) compiles source code, runs tests, and creates an artifact. A release pipeline (CD) takes that artifact and deploys it through environments like dev, staging, and production. Think of building as cooking the meal and releasing as serving it.
No, Azure DevOps also offers a classic visual editor for release pipelines. However, the exam focuses heavily on YAML because it is the modern approach and is version-controlled. You should be able to read a basic YAML pipeline.
A gate is an automated check that evaluates a condition using monitoring data, such as the error rate from Application Insights. If the condition is not met, the pipeline stops or waits until it improves. It is different from an approval, which requires a human to click a button.
Yes, you can simply re-run the release stage with the same artifact. You do not need to rebuild the code. The artifact is immutable, so the only fix needed is on the deployment environment or script.
Store the connection strings as secret variables in a variable group in the Azure Pipelines Library. Link that variable group to the release pipeline, and map different values to different environments. This way, the string is never in source control and is encrypted at rest.
It is a strategy where you maintain two identical production environments (blue and green). You deploy the new version to the inactive environment, run tests, then switch the traffic router to point to that environment. If something goes wrong, you switch back immediately.
You've finished Designing a Release Pipeline. Continue through the AZ-400 study guide to build a complete picture of the exam.
Done with this chapter?