Overview
Domain 3 carries half or more of the AZ-400 score and has six functional groups. Package management covers GitHub Packages, Azure Artifacts feeds, views, upstream sources and versioning with SemVer or CalVer. Testing covers quality and release gates, the test mix from unit to load tests, running tests in pipelines and code coverage. The pipelines group covers choosing GitHub Actions or Azure Pipelines, agent and runner infrastructure, triggers, YAML, job ordering, templates, variable groups and environment checks.
The deployments group covers blue-green, canary, ring and feature flag strategies, dependency ordering, low-downtime techniques such as slot swaps, hotfix paths, resiliency, Azure App Configuration feature flags and database deployment. Infrastructure as code covers configuration management, Bicep, ARM, Azure Machine Configuration and Azure Deployment Environments. The last group covers pipeline health, cost and concurrency, retention, and migrating classic pipelines to YAML.
How it's tested
Pipeline questions describe an application, its target platform, constraints such as zero downtime, network isolation, cost limits or approval rules, and sometimes a YAML snippet. You pick the tool, agent type, trigger, template structure, deployment pattern or IaC approach that satisfies every constraint at once, often in GitHub Actions and Azure Pipelines side by side.
-
Read the YAML
A pipeline or workflow fragment is shown and you identify the missing dependsOn, condition, trigger or template parameter.
-
Pick the rollout
Downtime, risk and audience requirements are given, and you choose blue-green, canary, rings, slot swap or feature flags.
-
Size the infrastructure
Private network access, tools, licensing and cost lead you to Microsoft-hosted, self-hosted or managed pool agents and runners.
A web app on Azure App Service must deploy with no downtime and allow instant rollback, and the team wants 10% of users on the new version first. Rolling deployments alone do not give instant rollback. Deploying to a staging slot, warming it up, then routing 10% of traffic with slot traffic routing before a full swap meets every need. If problems appear, swapping back restores the previous version immediately.
Functional groups 6
Official functional groups from the Microsoft outline, in outline order.
3.1 Design and implement a package management strategyGitHub Packages, Azure Artifacts, feeds, views, upstreams and versioning.
- What it means
- This group covers recommending package tools such as GitHub Packages and Azure Artifacts, designing feeds and views for local and upstream packages, setting a versioning strategy for code assets and packages with semantic versioning or date-based CalVer, and versioning pipeline artifacts.
- What to understand
- Azure Artifacts feeds host NuGet, npm, Maven, Python and Universal Packages at organization or project scope. Upstream sources proxy public registries such as nuget.org and npmjs and cache what you consume, which protects builds when the registry is down. Views such as @local, @prerelease and @release let you promote a version without republishing. GitHub Packages suits teams already in GitHub and integrates with GITHUB_TOKEN permissions. SemVer uses MAJOR.MINOR.PATCH with a major bump for breaking changes; CalVer uses dates such as 2026.10.1. Pipeline artifacts get versions from the run number or build number format.
- How it shows up
- Expect a question on promoting tested packages to consumers, or on picking a version bump for a change.
- Common confusion
- Thinking promotion copies a package to a new feed; a view only changes which consumers can see the same version.
3.2 Design and implement a testing strategy for pipelinesQuality and release gates, test mix, pipeline test tasks and code coverage.
- What it means
- This group covers quality and release gates including security and governance checks, a testing strategy that spans local, unit, integration and load tests, implementing tests in pipelines with test tasks, test agents and result publishing, and code coverage analysis.
- What to understand
- The test pyramid places many fast unit tests at the base, fewer integration tests above them and a small number of end-to-end and load tests at the top. Unit tests run on every pull request; integration and load tests usually run after deployment to a test environment. In Azure Pipelines, test results are published with the PublishTestResults task or built into tasks like DotNetCoreCLI, and appear in the Tests tab; coverage is published in Cobertura or JaCoCo format. Gates and checks can query Azure Monitor alerts, call a REST API or Azure Function, or require a security scan to pass before promotion.
- How it shows up
- Expect a question asking where a test type belongs in a pipeline or how to block promotion on a failed check.
- Common confusion
- Running long load tests on every pull request, which slows feedback, instead of after deployment to a test stage.
3.3 Design and implement pipelinesTool choice, agents and runners, triggers, YAML, job order, templates and environment checks.
- What it means
- This group covers choosing GitHub Actions or Azure Pipelines, designing runner or agent infrastructure for cost, tools, licenses, connectivity and maintenance, connecting GitHub repositories to Azure Pipelines, trigger rules, YAML pipelines, job ordering with parallelism and stages, hybrid and self-hosted scenarios, reusable elements, and checks and approvals using YAML environments.
- What to understand
- Microsoft-hosted agents and GitHub-hosted runners are fresh images with no maintenance but no private network access; self-hosted agents, VM scale set agents and Managed DevOps Pools reach private resources and keep tools installed. Parallel jobs are licensed per organization. Azure Pipelines supports CI, pull request, scheduled and pipeline resource triggers; GitHub Actions uses on: push, pull_request, schedule and workflow_dispatch. Stages and jobs run in parallel unless dependsOn and conditions order them. Templates reuse steps, jobs or stages and extends templates enforce structure. Variable groups can link to Azure Key Vault. Approvals and checks attach to environments, not to the YAML file.
- How it shows up
- Expect YAML snippets, agent choices for private networks, and questions on where an approval should live.
- Common confusion
- Adding an approval step inside YAML; in Azure Pipelines, approvals and checks are configured on the environment or resource.
3.4 Design and implement deploymentsDeployment strategies, ordering, low downtime, hotfixes, resiliency, feature flags and database tasks.
- What it means
- This group covers deployment strategies such as blue-green, canary, ring, progressive exposure, feature flags and A/B testing, reliable ordering of dependent deployments, minimizing downtime with load balancing, rolling updates and slot swaps, a hotfix path, a resiliency strategy, feature flags with Azure App Configuration Feature Manager, deploying containers, binaries and scripts, and deployments that include database tasks.
- What to understand
- Blue-green runs two identical environments and switches traffic at once. Canary sends a small share of traffic to the new version, while rings expand exposure by user group, for example internal users before everyone. Feature flags separate deployment from release, and Azure App Configuration with the Feature Management library can target flags by user or percentage. App Service deployment slots support warm-up, traffic routing and swap for instant rollback. A hotfix path defines how an urgent fix skips normal cadence but still passes essential gates. Database changes use DACPAC, migration scripts or EF Core migrations, run before the app that depends on them.
- How it shows up
- Expect requirements on downtime, rollback speed and audience that point to one strategy.
- Common confusion
- Treating canary and ring deployments as identical; canary splits by traffic share, rings expose by user group.
3.5 Design and implement infrastructure as code (IaC)Configuration management, IaC strategy, desired state configuration and Azure Deployment Environments.
- What it means
- This group covers recommending and implementing configuration management for application infrastructure, defining an IaC strategy with source control and automated testing and deployment, implementing desired state configuration using Azure Automation State Configuration, Azure Resource Manager, Bicep and Azure Machine Configuration, and using Azure Deployment Environments for on-demand self-service.
- What to understand
- Bicep compiles to ARM templates and is declarative and idempotent, so redeploying converges the resources. What-if previews changes, and deployment stacks can manage and delete resources as a group. Terraform is an alternative that tracks state in a backend. Configuration management inside machines uses Azure Machine Configuration, which supersedes Azure Automation State Configuration for new designs, or tools such as Ansible. An IaC strategy stores templates in Git, lints and validates them in pull requests, and deploys through pipelines. Azure Deployment Environments lets developers create approved environments from catalog templates within a dev center and project.
- How it shows up
- Expect a choice between IaC tools, or a question on letting developers self-provision approved environments.
- Common confusion
- Using Bicep to configure software inside a VM; that belongs to machine configuration tools.
3.6 Maintain pipelinesPipeline health, optimization, concurrency, retention and classic-to-YAML migration.
- What it means
- This group covers monitoring pipeline health such as failure rate, duration and flaky tests, optimizing pipelines for cost, time, performance and reliability, tuning concurrency, setting retention for artifacts and dependencies, and migrating classic Azure Pipelines to YAML.
- What to understand
- Pipeline analytics reports run success percentage, duration and failing tasks, and test analytics can flag flaky tests so they do not block merges. Caching with the Cache task or actions/cache speeds dependency restore. Concurrency is limited by purchased parallel jobs, and GitHub Actions concurrency groups can cancel superseded runs. Retention policies set how long runs, artifacts and test results are kept, and individual runs can be retained by lease. Classic pipelines are migrated by recreating stages and jobs in YAML, using the classic editor's View YAML for jobs as a starting point, and moving release approvals to environments.
- How it shows up
- Expect a slow or costly pipeline, or a flaky test problem, with optimization options.
- Common confusion
- Buying more parallel jobs when caching or removing redundant work would fix a slow single run.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Upstream sources
Feed setting that proxies and caches public registries.
- Remember
- Keeps builds working if the public registry fails.
- Tested as
- Package questions.
- Trap
- Expecting packages to be copied before first use.
-
Feed views
@local, @prerelease and @release promotion levels.
- Remember
- Promote without republishing.
- Tested as
- Release quality questions.
- Trap
- Creating separate feeds for each quality level.
-
Semantic versioning
MAJOR.MINOR.PATCH numbering.
- Remember
- Breaking change means a major bump.
- Tested as
- Versioning questions.
- Trap
- Bumping minor for a breaking API change.
-
Self-hosted agent or runner
Agent you install and maintain on your own machines.
- Remember
- Reaches private networks and keeps tools.
- Tested as
- Infrastructure questions.
- Trap
- Choosing hosted agents for private endpoints.
-
Managed DevOps Pools
Azure-managed agent pools for Azure Pipelines with VNet support.
- Remember
- Less maintenance than self-managed VMs.
- Tested as
- Agent design questions.
- Trap
- Assuming it applies to GitHub Actions.
-
Templates and extends
Reusable YAML for steps, jobs, stages or whole pipelines.
- Remember
- Extends templates can enforce required structure.
- Tested as
- Reuse and governance questions.
- Trap
- Using task groups in YAML pipelines; they are classic only.
-
Variable groups
Shared variables across pipelines, optionally linked to Key Vault.
- Remember
- Secrets stay masked in logs.
- Tested as
- Reuse questions.
- Trap
- Hardcoding secrets in YAML.
-
Environments with checks
Deployment targets that hold approvals and checks.
- Remember
- Configured outside YAML on the environment.
- Tested as
- Approval questions.
- Trap
- Writing approvals into the YAML file.
-
dependsOn and conditions
Control order and execution of stages and jobs.
- Remember
- Without dependsOn, jobs run in parallel.
- Tested as
- Job order questions.
- Trap
- Assuming file order sets execution order.
-
Deployment slots
Separate App Service instances that can swap.
- Remember
- Warm-up then swap gives near-zero downtime.
- Tested as
- Low-downtime questions.
- Trap
- Forgetting slot-sticky settings.
-
Feature flags
Toggle features at runtime without redeploying.
- Remember
- Azure App Configuration Feature Manager targets users or percentages.
- Tested as
- Release strategy questions.
- Trap
- Leaving stale flags in code forever.
-
Ring deployment
Gradual exposure by user group.
- Remember
- Internal ring first, then wider rings.
- Tested as
- Progressive exposure questions.
- Trap
- Confusing it with canary traffic splits.
-
Bicep
Declarative Azure IaC language compiled to ARM.
- Remember
- Idempotent, with what-if previews.
- Tested as
- IaC questions.
- Trap
- Treating it as a VM configuration tool.
-
Azure Deployment Environments
Self-service environments from approved templates.
- Remember
- Uses dev centers, catalogs and environment types.
- Tested as
- Self-service questions.
- Trap
- Granting developers Owner on subscriptions instead.
-
Pipeline caching
Reuses downloaded dependencies between runs.
- Remember
- Cache task or actions/cache keyed on lock files.
- Tested as
- Optimization questions.
- Trap
- Caching build outputs that must be rebuilt.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Deployment strategies
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Blue-green | Two full environments, switch all traffic | Instant switch and rollback | Underestimating the cost of two environments |
| Canary | Small traffic share on new version | Split by percentage of requests | Confusing with user-group rings |
| Ring | Expand by user group in stages | Internal users before customers | Assuming random traffic split |
| Feature flags | Toggle code paths at runtime | Separates deploy from release | Using flags instead of fixing bad deployments |
| Rolling | Replace instances in batches | No duplicate environment | Expecting instant rollback |
Agent and runner options
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Microsoft-hosted agent or GitHub-hosted runner | Fresh managed image per job | No maintenance, no private network | Using them for private resources |
| Self-hosted agent or runner | Your machine with the agent installed | Private access, persistent tools, you patch it | Ignoring maintenance and security |
| Managed DevOps Pools or scale set agents | Elastic pools of Azure VMs | Scale out with VNet access | Assuming GitHub Actions support |
Reusable pipeline elements
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| YAML template | Reusable steps, jobs, stages or variables | Version controlled with parameters | Missing required parameters |
| Task group | Reusable task set in classic pipelines | Classic only | Expecting it in YAML |
| Variable group | Shared variables in the Library | Can link Key Vault secrets | Forgetting to authorize the pipeline |
IaC and configuration tools
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Bicep or ARM | Declarative Azure resource deployment | Native to Azure, no state file | Using it for OS configuration |
| Terraform | Multi-cloud IaC with a state file | Needs a secured remote state backend | Committing state to Git |
| Azure Machine Configuration | Audits and applies settings inside machines | Successor for new DSC-style work | Starting new designs on Automation State Configuration |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Approval in YAML
- What candidates pick
- Add a manual validation step for production approval.
- Why it looks right
- It is visible in the pipeline file.
- Why it's wrong
- Environment approvals and checks are enforced by the resource and cannot be bypassed by editing YAML.
Clue to watch for Approvers must sign off before production deployment.
-
Hosted agent for private SQL
- What candidates pick
- Use a Microsoft-hosted agent to run database migrations against a private endpoint.
- Why it looks right
- Hosted agents need no maintenance.
- Why it's wrong
- Hosted agents cannot reach private networks; use a self-hosted agent or Managed DevOps Pool with VNet integration.
Clue to watch for The target has public access disabled.
-
Separate feeds for promotion
- What candidates pick
- Create dev, test and prod feeds and republish packages to each.
- Why it looks right
- Separate feeds seem clean.
- Why it's wrong
- Feed views promote the same package version without republishing, which preserves integrity and traceability.
Clue to watch for Promote a tested package to consumers.
-
Rolling for instant rollback
- What candidates pick
- Use rolling deployments to allow instant rollback.
- Why it looks right
- Rolling avoids extra environments.
- Why it's wrong
- Rolling rollbacks redeploy batch by batch; slot swap or blue-green gives an immediate switch back.
Clue to watch for Rollback must take seconds.
-
Task groups in YAML
- What candidates pick
- Create a task group to share steps across YAML pipelines.
- Why it looks right
- Task groups are a known reuse feature.
- Why it's wrong
- Task groups apply to classic pipelines; YAML uses step, job or stage templates.
Clue to watch for The pipelines are defined in YAML.
-
More parallel jobs for one slow run
- What candidates pick
- Buy extra parallel jobs to speed up a single long build.
- Why it looks right
- More capacity sounds faster.
- Why it's wrong
- Parallel jobs help concurrent runs; a single slow run needs caching, job splitting or faster agents.
Clue to watch for One pipeline run is slow, not a queue.
-
Bicep for VM settings
- What candidates pick
- Use Bicep to enforce registry settings inside VMs.
- Why it looks right
- Bicep already deploys the VMs.
- Why it's wrong
- Bicep manages Azure resources, while in-guest settings need Azure Machine Configuration or similar tools.
Clue to watch for Settings inside the operating system must stay compliant.
Answer framework
Use these steps to work through a Domain 3 pipeline or deployment scenario.
- Identify the platform and tool: GitHub Actions or Azure Pipelines, where the code and packages live, and whether the team already uses one of them.
- Check network and tooling needs to choose hosted, self-hosted or managed pool agents, and confirm parallel job and cost limits.
- Map triggers, stage order and reuse: trigger rules, dependsOn and conditions, templates, and variable groups linked to Key Vault.
- Choose the rollout from downtime, rollback and audience requirements, and place approvals and checks on the target environment.
- Confirm the supporting pieces that the scenario mentions: package views, test gates, IaC with Bicep or Terraform, database ordering, caching and retention policies.
Practice question
Want more like this? The AZ-400 practice test has questions for every domain.
Checklist
0 of 16
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Give this domain at least half of your total study time. Build one multi-stage YAML pipeline in Azure Pipelines that restores from an Azure Artifacts feed with an upstream source, runs unit tests with coverage, publishes an artifact, and deploys to a staging slot through an environment with an approval check. Then build the same flow as a GitHub Actions workflow using environments, required reviewers and a reusable workflow.
Break the pipelines on purpose: remove a dependsOn, mis-scope a variable, point a hosted agent at a private resource, and read the errors. Add a template with parameters and an extends template, and move secrets into a variable group linked to Key Vault.
After that, practice deployment patterns: slot swap with traffic routing, a feature flag in Azure App Configuration, and a Bicep deployment with what-if. Create an Azure Deployment Environments catalog if you have a subscription. Finish with pipeline analytics, caching and retention settings. Plan thirty to forty hours and revisit YAML syntax often.
FAQ
How much of AZ-400 is Domain 3, Design and implement build and release pipelines?
Microsoft weights it at 50–55%, by far the largest skill area, with six functional groups from package management to maintaining pipelines.
Do I need to know both GitHub Actions and Azure Pipelines?
Yes. The objectives ask you to select between them, integrate GitHub repositories with Azure Pipelines and design runners or agents for both.
Where should production approvals be configured in Azure Pipelines?
On the environment that the deployment job targets, as approvals and checks. The YAML file references the environment but does not hold the approval.
What is the difference between a canary release and a ring deployment?
A canary sends a percentage of traffic to the new version. Rings expose the new version to defined user groups in sequence, such as internal staff first.
Is Azure Automation State Configuration still tested?
It is named in the current objectives alongside Azure Machine Configuration. Microsoft recommends Machine Configuration for new work, so know both and why.
How can I reduce pipeline cost?
Cache dependencies, cancel superseded runs, right-size parallel jobs, use retention policies and choose agent types that match the workload.
Should I memorize YAML syntax?
Know the structure of stages, jobs, steps, triggers, templates, variables and environments well enough to spot errors in short snippets.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 3 knowledge
You have covered packages, tests, pipelines, deployments, IaC and pipeline upkeep. Test yourself on the domain that carries more than half of the exam.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the AZ-400 AI tutor Get any concept explained your way