Design and implement build and release pipelines
Pipeline Architecture and YAML
CoreSelect the automation platform, execution infrastructure, trigger model, dependency graph, reusable boundary, and protected environment for a maintainable pipeline.
Aligned to AZ-400 skills measured as of July 27, 2026; guide and product behavior verified September 25, 2026.
Why this matters
Most pipeline failures blamed on YAML are actually scope errors: wrong trigger, wrong evaluation time, missing identity, unavailable network path, mutable runner, or an unmodeled dependency.
Must Know
- Choose GitHub Actions for GitHub-native workflows and governance; choose Azure Pipelines when Azure DevOps resources, enterprise release controls, or existing pipeline investments are decisive.
- Hosted runners or agents provide fresh maintained images; self-hosted execution provides private connectivity and custom tools but transfers patching, cleanup, isolation, and capacity ownership to the organization.
- Source authentication for a GitHub repository is separate from the Azure identity used by a deployment.
- Triggers decide whether a run starts; conditions decide whether a stage, job, or step runs inside an existing run.
- Azure YAML template expressions and parameters shape the pipeline at compile time; runtime variables, outputs, and conditions act later.
- Use `dependsOn` or `needs` for ordering and allow independent jobs to run in parallel only when capacity exists.
- Azure YAML templates and GitHub reusable workflows centralize governed sequences; variables and composite actions solve narrower reuse problems.
- Reference protected environments so approvals, checks, secrets, and deployment history are enforced at the deployment boundary.
Compare and Distinguish
- A GitHub reusable workflow is called as a job; a composite action is used as a step.
- An Azure variable group stores shared values; a task group is classic reuse; a YAML template reuses declarative structure.
- A pool or runner label selects execution capability; a parallel-job entitlement determines how many jobs may run.
Scenario examples
- Scenario: CI runs on features but deployment only on main. Think: broad trigger plus a success-and-branch stage condition.
- Scenario: On-premises hardware is required by one test. Think: separate job on a restricted self-hosted pool and exchange an artifact.
Exam traps
- A self-hosted runner is not automatically ephemeral or isolated between jobs.
- A custom condition can overwrite the default success condition unless success is included.
- Copying YAML is not reuse; it creates independent drift.
Key takeaways
- Model events, evaluation time, identity, execution location, and dependency explicitly.
- Use hosted execution by default and self-hosted only for a documented need.
- Move shared behavior into versioned reusable units with least token permissions.
How it works
- The platform expands templates into a plan, creates runs from matching events, schedules eligible jobs, and evaluates runtime conditions.
- Protected environments delay a deployment job and withhold environment secrets until required checks and approvers permit access.
Objects and administrative surfaces
- `.github/workflows`, workflow permissions, events, environments, runner groups, labels, reusable workflows, and Actions logs.
- `azure-pipelines.yml`, repository resources, triggers, stages, jobs, templates, pools, variable groups, environments, checks, and service connections.
When to use it
- Use self-hosted execution for documented private connectivity, hardware, or licensed-tool needs that hosted images cannot satisfy.
Security and governance implications
- Restrict runner groups, minimize workflow token scopes, separate source credentials from cloud identities, and protect environments.
Troubleshooting signals
- For an unexpected skip or queue, inspect trigger filters, compiled YAML, dependency results, condition evaluation, demands, and capacity.
More detail
- Select GitHub Actions for GitHub-native workflow governance and Azure Pipelines when Azure DevOps resources are the decisive boundary.
- Use dependsOn or needs to express the job graph, and verify that agent supply plus parallel-job capacity can execute that graph.
- Choose reusable workflows or YAML templates for governed sequences, leaving composite actions and variable groups to narrower reuse.
Ready for the quiz?
- What is the difference between a trigger and a condition?
- Why might a job queue even when a matching agent exists?
- Where should a reusable GitHub deployment workflow be called?
Related objectives
- D3.3.S1 — Select a deployment automation solution, including GitHub Actions and Azure Pipelines
- D3.3.S2 — Design and implement a GitHub runner or Azure DevOps agent infrastructure, including cost, tool selection, licenses, connectivity, and maintainability
- D3.3.S3 — Design and implement integration between GitHub repositories and Azure Pipelines
- D3.3.S4 — Develop and implement pipeline trigger rules
- D3.3.S5 — Develop pipelines by using YAML
- D3.3.S6 — Design and implement a strategy for job execution order, including parallelism and multi-stage pipelines
- D3.3.S7 — Develop and implement complex pipeline scenarios, such as hybrid pipelines, VM templates, and self-hosted runners or agents
- D3.3.S8 — Create reusable pipeline elements, including YAML templates, task groups, variables, and variable groups
- D3.3.S9 — Design and implement checks and approvals by using YAML-based environments