Domain 3 · 50–55%

Design and implement build and release pipelines

The heart of AZ-400 — more than half the exam. Six sub-objectives covering how software is packaged, tested, built, deployed, provisioned and kept healthy, across both Azure Pipelines and GitHub Actions.

Budget your study time here

At 50–55%, this domain is worth as much as the other four combined. If you are short on time, work through these six pages first and treat Domains 1, 2, 4 and 5 as revision. Within Domain 3, pipelines and deployments attract the most questions.

The six sub-objectives

3.1

Package management strategy

Azure Artifacts vs GitHub Packages, feeds and views, upstream sources, SemVer vs CalVer, artifact versioning.

Read → 3.2

Testing strategy for pipelines

Quality and release gates, the test pyramid, service containers, test agents, results publishing, code coverage.

Read → 3.3

Design and implement pipelines

Actions vs Pipelines, agents and runners, triggers, YAML structure, parallelism, templates, environments and approvals.

Read → 3.4

Design and implement deployments

Blue-green, canary, ring, rolling, A/B, feature flags, slots, hotfix paths, resiliency and database deployments.

Read → 3.5

Infrastructure as code

Bicep and ARM, deployment modes and what-if, DSC and Machine Configuration, Azure Deployment Environments.

Read → 3.6

Maintain pipelines

Pipeline health and flaky tests, cost/time optimisation, caching, concurrency, retention, classic → YAML migration.

Read →

How the pieces fit together

flowchart TB subgraph CI["Continuous integration"] S[Source commit / PR] --> B[Build] B --> T["Test
3.2 unit · integration · coverage"] T --> PK["Package
3.1 artifacts & feeds"] end subgraph CD["Continuous delivery"] PK --> G{"Gates & approvals
3.2 / 3.3"} G --> IAC["Provision infrastructure
3.5 Bicep / ARM"] IAC --> D["Deploy
3.4 blue-green · canary · ring"] D --> M["Monitor & feed back
Domain 5"] end M -.->|"health signals gate the next release"| G D -.->|"3.6 optimise, retain, maintain"| B

The six sub-objectives are stages of one pipeline, not six separate topics — questions frequently cross the boundaries.

One exam, two toolchains

Nearly every concept in this domain exists in both Azure Pipelines and GitHub Actions under different names. Learn the pairs — a large share of Domain 3 questions are really vocabulary questions.

Concept	Azure Pipelines	GitHub Actions
Definition file	`azure-pipelines.yml` (anywhere in the repo)	`.github/workflows/*.yml`
Top-level unit	Pipeline → stages → jobs → steps	Workflow → jobs → steps (no stages)
Compute	Agent (Microsoft-hosted or self-hosted), in a pool	Runner (GitHub-hosted or self-hosted), in a runner group
Reusable unit of work	Task (`- task: X@1`)	Action (`- uses: org/action@v1`)
Reuse across pipelines	YAML templates, task groups (classic)	Reusable workflows (`workflow_call`), composite actions
Shared configuration	Variable groups (Library), optionally Key Vault-linked	Org/repo/environment variables and secrets
Deployment target + gating	Environments → approvals & checks	Environments → protection rules
Job ordering	`dependsOn` + `condition`	`needs` + `if`
Fan-out over a config set	`strategy: matrix:`	`strategy: matrix:`
Build outputs	Pipeline artifacts (`PublishPipelineArtifact@1`)	Artifacts (`actions/upload-artifact`)
Package registry	Azure Artifacts	GitHub Packages / `ghcr.io`
Manual run	Run pipeline (UI/CLI), `parameters:`	`workflow_dispatch:` with `inputs:`
Secretless Azure auth	Service connection with workload identity federation	`azure/login` with OIDC

Caveat — stages exist only in Azure Pipelines

GitHub Actions has no stage construct. Multi-stage behaviour is expressed with jobs plus needs: and per-job environment:. If an answer option offers "add a stage" to a GitHub Actions workflow, it is wrong.

Choosing between them

Choose…	When the scenario has…
GitHub Actions	Code already in GitHub; open-source project; team living in the GitHub ecosystem (Issues, Projects, Dependabot, Advanced Security); wanting the marketplace of community actions
Azure Pipelines	Azure Repos, Bitbucket or TFVC as the source; a need for rich release management (stages, gates, deployment groups); existing classic pipelines; enterprise governance across many projects
Both together	Code in GitHub, CD in Azure Pipelines — connect via the Azure Pipelines GitHub App so build status appears as a check on the PR

TFVC is the tiebreaker

GitHub Actions cannot build from Team Foundation Version Control. If a legacy TFVC repository appears anywhere in the scenario, the answer is Azure Pipelines.