AZ-400 build and release pipelines explained
Design and implement build and release pipelines is 50-55% of AZ-400, more than all other domains together. It covers six areas: package management, testing in pipelines, pipeline design, deployment strategies, infrastructure as code, and pipeline maintenance. If you can read and write a multi-stage YAML pipeline and justify a deployment strategy from a requirement, you have most of the exam.
Package management
- Tools. Azure Artifacts and GitHub Packages host packages (NuGet, npm, Maven, Python, containers and more).
- Feeds and views. An Azure Artifacts feed can pull from upstream sources such as nuget.org, and views (for example
@Local,@Prerelease,@Release) promote a package through quality levels without republishing it. - Versioning. Semantic versioning (
MAJOR.MINOR.PATCH) signals breaking changes; calendar versioning (CalVer) uses dates. Pipeline artifacts also need a versioning strategy, often the build number.
Testing strategy for pipelines
Tests are layered: local tests, unit tests, integration tests and load tests, each running where it is cheap and meaningful. You should know how to publish test results, collect code coverage, and add quality gates and release gates (a failed coverage threshold, a security scan result, an Azure Monitor alert check or a manual approval can block a release). Flaky tests, which pass and fail without code change, are a maintenance topic: quarantine them rather than ignore the pipeline.
Designing pipelines
Choosing GitHub Actions or Azure Pipelines
Both are valid. The exam asks you to pick one from the scenario: the code lives in GitHub, the team already uses Azure Boards, a feature such as environments with checks or Azure Artifacts is needed. A pipeline in Azure Pipelines can build a GitHub repository, so “the code is on GitHub” does not force Actions.
Runners and agents
| Option | Use when |
|---|---|
| Microsoft-hosted agent / GitHub-hosted runner | Clean image per job, no maintenance, public internet access is enough |
| Self-hosted agent / runner | You need private network access, special software, more control over cost or hardware |
| Scale set agents (Azure) / larger runners | You need elastic capacity with your own images or bigger machines |
Think about cost, licenses (parallel jobs), connectivity and who maintains the image.
YAML essentials
trigger:
branches:
include: [ main ]
paths:
exclude: [ docs/* ]
stages:
- stage: Build
jobs:
- job: build
pool: { vmImage: ubuntu-latest }
steps:
- script: dotnet test --collect:"XPlat Code Coverage"
- stage: Deploy
dependsOn: Build
condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
jobs:
- deployment: web
environment: production
strategy:
runOnce:
deploy:
steps:
- script: echo deploying
Know these ideas: trigger versus pr triggers and path filters; stages contain jobs, jobs contain steps; stages run in sequence unless dependsOn is set, and jobs in a stage run in parallel unless dependencies are set; condition overrides the default success check; a deployment job targets an environment, which is where checks and approvals (manual approval, branch control, Key Vault or Azure Monitor checks) live. In GitHub Actions the equivalents are on:, needs:, if: and environments with required reviewers.
Reuse
- Azure Pipelines: step, job, stage and variable templates; template extends for enforcing structure; variable groups; task groups in classic pipelines.
- GitHub Actions: reusable workflows (
workflow_call), composite actions and organization-level starter workflows.
Reusable templates are the answer whenever a requirement says “many repositories must follow the same build steps”.
Deployments
| Strategy | What happens | Typical reason |
|---|---|---|
| Blue-green | Two identical environments; switch traffic at once | Instant rollback, minimal downtime |
| Canary | Send a small share of traffic to the new version first | Test in production with limited blast radius |
| Ring | Release to rings of users in turn | Gradual rollout inside an organization |
| Rolling | Update instances in batches | Capacity must stay available |
| Feature flags | Deploy code switched off, enable later | Separate deployment from release |
| A/B testing | Compare two variants with real users | Measure which version performs better |
For Azure App Service, deployment slots with a swap give blue-green behaviour with warm-up. Feature flags are managed in Azure App Configuration Feature Manager. A hotfix path is a documented fast route to production that still runs the essential checks. Deployments with database changes need ordered, repeatable migration steps and a plan for rollback.
Infrastructure as code
Define infrastructure in source control, test it and deploy it through a pipeline. Know Bicep and ARM templates (declarative, idempotent), desired state through Azure Machine Configuration and Automation State Configuration, and Azure Deployment Environments for on-demand self-service environments from approved templates. Choosing a configuration management technology is a scenario question: Bicep for Azure resources, Machine Configuration or similar for the state inside machines.
Maintaining pipelines
Watch failure rate, duration and flaky tests; optimise for cost and time with caching, parallelism and shallow clones; set retention for artifacts and runs; manage concurrency; and migrate classic pipelines to YAML so the pipeline is versioned with the code.
Example questions
Question 1. An Azure Pipelines YAML pipeline deploys to production. The release manager must approve each production deployment, and approval must be enforced even if someone edits the YAML. Where should you configure the approval?
- A. As a script step in the YAML that waits for input
- B. As a branch policy on main
- C. As an approval check on the production environment
- D. As a variable group with a protected value
Show answer
Answer: C
Approvals and checks are configured on the environment, outside the YAML file, so editing the YAML cannot remove them; a deployment job that targets the environment waits for approval. A manual step inside the YAML can be edited away. A branch policy governs merging, not deployment. A variable group controls values, not approvals.
Want more questions like this? Full AZ-400 practice tests →
Question 2. An organization has 60 repositories. Security requires that every build runs the same dependency scan and publishes the same artifacts, with changes made in one place. Which approach fits an Azure Pipelines setup?
- A. Copy the YAML into each repository and edit it as needed
- B. A shared YAML template that each pipeline extends
- C. A variable group containing the scan commands
- D. A self-hosted agent pool for all repositories
Show answer
Answer: B
Shared YAML templates, ideally enforced with extends, define the common steps once and are referenced by each pipeline, so a change propagates everywhere. Copying the YAML into each repository creates 60 divergent versions. A variable group stores values, not steps. A self-hosted agent pool controls where jobs run, not what they do.
Want more questions like this? Full AZ-400 practice tests →
Question 3. A web app runs on App Service. You must release a new version with near-zero downtime, validate it against production configuration first and be able to revert in seconds. What should you use?
- A. Deploy straight to the production app and restart it
- B. Scale the app to a single instance and deploy
- C. Delete the app and redeploy it from the pipeline
- D. Deploy to a staging slot and swap it into production
Show answer
Answer: D
Deploying to a staging slot, warming and testing it, then swapping gives near-zero downtime, and swapping back reverts in seconds. Deploying directly to production risks downtime and slow rollback. A single instance restart does not validate the new version. Deleting and recreating the app causes downtime.
Want more questions like this? Full AZ-400 practice tests →
Next
Continue with security and compliance.