AZ-400: Implement CI — Azure Pipelines & GitHub Actions

2-ci-azure-pipelines-gh-actions-moc

Implement CI: Azure Pipelines & GitHub Actions — MOC

MS Learn path: Implement CI using Azure Pipelines and GitHub Actions · Continuous integration — build & validate on every change.

Planned concepts

Azure Pipelines · GitHub Actions · ci-trigger · Agents & pools · YAML pipelines · Jobs/steps/tasks · build-artifact · pipeline-templates · self-hosted-agent · pipeline-variables · pipeline-run · monorepo-pipeline · pipeline-maintenance · pipeline-retention · test-coverage · Pipeline security · secretless-pipeline-authentication · Integration testing

Planned modules

Set up CI with Azure Pipelines · Use GitHub Actions for CI · Manage agents & pools · Pipeline artifacts & templates · Components & stage · Advanced YAML · Evaluation & quality gates · Webhooks & triggers · Run diagnostics & maintenance · Pipeline security controls · Integration & E2E testing · Dependencies & supply chain · Branch protection & policies

Modules in this path

Skills (current AZ-400 blueprint)

Choose Azure Pipelines or GitHub Actions; design hosted/self-hosted runner infrastructure; author YAML with triggers, templates, variables, job order and parallelism; implement tests, coverage, artifacts, environments/checks, security, retention, and operational maintenance.

Route check: Explain why a production environment check, a secretless Azure login, and a project retention policy solve three different problems. Then complete both implementation labs: GitHub Actions and Azure Pipelines.

Evidence route

After the two starter labs, complete package promotion before you treat a package version as a release input. Next complete reusable YAML, agents, and GitHub integration: it makes the runner, connection, template, variable, dependency, and failure boundaries observable. Finish this path with IaC and pipeline maintenance.

Route check: Given a queued job and an unstarted GitHub push, identify the evidence that separates capacity, agent capability, repository authorization, trigger configuration, and dependency ordering.

Practice questions

Conceptual checkpoint

Explain the sequence in this path using one workload scenario: identify the boundary being changed, the identity or tool acting on it, the expected evidence, and the failure that would change your decision.

Sources and re-audit

Re-audit when the AZ-400 course path, study-guide effective date, or the services and permissions taught here change.

set-up-ci-with-azure-pipelines

Set up CI with Azure Pipelines

MS Learn module: Explore Azure Pipelines · Learning objectives: understand what Azure Pipelines does, when to use it, and how to define a basic YAML pipeline that builds and tests code on every change.

Overview

The entry point to CI: what Azure Pipelines is, why YAML-first, and how to author a azure-pipelines.yml that runs on a Microsoft-hosted agent, is gated by triggers, and executes jobs/steps.

Units / lessons covered

  • What is continuous integration and why automate it
  • Azure Pipelines capabilities (CI + CD, cross-platform, hosted agents)
  • Authoring a YAML pipeline (azure-pipelines.yml)
  • Configuring triggers, variables, and running a build

Key terms / commands

  • azure-pipelines.yml · trigger: · pool: · steps: · Microsoft-hosted agent · run/queue

Hands-on / what to try

Create a minimal pipeline: trigger on a branch, pool: vmImage: 'ubuntu-latest', a script: echo hello step; add a real dotnet/npm build and watch it run on a commit.

Exam focus

  • YAML-first is recommended; classic editor is legacy.
  • Know the top-level YAML keys and the stages → jobs → steps model.

Path MOC · use-github-actions-for-ci · agents-and-pools · pipeline-artifacts-and-templates

use-github-actions-for-ci

Use GitHub Actions for CI

MS Learn module: Understand CI with GitHub Actions · Learning objectives: describe workflows, events, jobs, steps, and actions; create a workflow YAML that builds on push/PR and deploys to Azure.

Overview

CI done inside the repo host. GitHub Actions uses .github/workflows/*.yml where events fire workflows of jobs/steps running on GitHub-hosted or self-hosted runners, reusing the action ecosystem.

Units / lessons covered

  • Workflows, events, and the on: trigger
  • Jobs, steps, and actions; runs-on
  • Reusing logic (composite actions, reusable workflows)
  • Deploying to Azure with GitHub Actions

Key terms / commands

  • .github/workflows/<name>.yml · on: · runs-on: · actions/checkout · actions/upload-artifact

Hands-on / what to try

Create a workflow that runs npm ci + npm test on push, then add actions/upload-artifact; deploy a build to an Azure App Service with the Azure login action.

Exam focus

  • Workflow file location and YAML schema differ from Azure Pipelines.
  • Events (push, pull_request, schedule, workflow_dispatch); filters on branches/paths.
  • Sharing output between jobs via actions/upload-artifact / download-artifact.

Path MOC · set-up-ci-with-azure-pipelines · pipeline-artifacts-and-templates

agents-and-pools

Manage Azure Pipeline agents and pools

MS Learn module: Manage Azure Pipeline agents and pools · Learning objectives: choose between Microsoft-hosted and self-hosted agents, create agent pools, register agents, and match jobs to capable agents.

Overview

Every job needs compute. This module is about the where of CI: Microsoft-hosted vs self-hosted pools, how to register agents, and how pool: + capabilities route jobs.

Units / lessons covered

  • Microsoft-hosted agents (vmImage) and pricing/minutes
  • Self-hosted agents: install, configure with PAT, register, run
  • Creating org/project agent pools and managing access
  • Capabilities/demands and job-agent matching

Key terms / commands

  • pool: vmImage: vs pool: <poolName> · ./config.sh / ./run.sh · PAT (Agent Pools scope) · capabilities/demands:

Hands-on / what to try

Register a self-hosted agent into a project pool, declare a capability, then run a job with pool: myPool and a demands: filter; confirm it picks the right agent.

Exam focus

  • Self-hosted agents poll (outbound HTTPS only), one job at a time.
  • PAT scope needed: Agent Pools (read & manage).
  • Capability/demands: matching is a frequent exam question.

Path MOC · set-up-ci-with-azure-pipelines · use-github-actions-for-ci

pipeline-artifacts-and-templates

Pipeline artifacts and templates

MS Learn module: Implement a code workflow in your build pipeline · Learning objectives: publish and consume build artifacts, and factor reusable pipeline logic into templates and parameters.

Overview

Two forces shape a healthy CI pipeline: sharing output (artifacts) between jobs/releases, and sharing logic (templates) across pipelines so a change lands once, everywhere.

Units / lessons covered

  • Publishing and downloading build artifacts (publish task, download task)
  • Feeding artifacts into release/CD stages
  • Step/job/stage templates and extends
  • Template parameters with defaults and type checking

Key terms / commands

  • PublishPipelineArtifact / DownloadPipelineArtifact · actions/upload-artifact · template: / extends: / parameters:

Hands-on / what to try

Publish build output from one job and download it in a second job; then extract the repeated build steps into a templates/build.yml step template and include it from two pipelines.

Exam focus

  • Artifacts are how jobs on different agents share files; a later job must explicitly download.
  • extends: enforces structure; template: just includes — know the difference.
  • GitHub Actions equivalents: upload/download-artifact, reusable workflows (on: workflow_call).

Path MOC · set-up-ci-with-azure-pipelines · use-github-actions-for-ci

azure-pipelines

Azure Pipelines

What it is

Azure Pipelines is the Azure DevOps service that automates continuous integration (CI), continuous testing, and continuous delivery (CD). A pipeline is a repeatable set of instructions that can build, test, package, and deploy code to cloud, on-premises, VM, container, or platform-service targets.

Why it exists

Without automation, people repeat build and release steps differently and discover integration failures late. Pipelines make the process visible and repeatable, but the team must still choose safe triggers, protect secrets, review deployment permissions, and decide which tests are meaningful.

Key ideas

  • CI: builds and tests a code change so problems appear before release.
  • CD: promotes a deployable artifact through one or more environments. Continuous delivery does not require every production deployment to be automatic.
  • Definition: pipelines can be defined in YAML or, in supported scenarios, classic UI definitions. YAML keeps the automation with the code and supports review.
  • Trigger: a push, pull request, schedule, manual action, or another pipeline can start a run; see ci-trigger.
  • Jobs, steps, and tasks: describe the work that runs; see jobs-steps.
  • Agent: the machine that executes the job. Use Microsoft-hosted agents for standard ephemeral jobs or self-hosted agents when a job needs controlled network access or tools.

Northwind example

When Luis opens a pull request for Northwind’s ordering API, a pipeline restores dependencies, runs tests and security checks, and publishes a versioned build artifact only if the checks pass. A separate deployment stage releases that same artifact to test, then requires the team’s production approval rule. The pipeline does not make the code correct by itself: a skipped test, overly broad service connection, or unreviewed YAML change can still create risk.

Exam notes

  • Pipeline = automation; it is not the source repository, a package feed, or a deployment approval by itself.
  • A build artifact should be produced once and promoted through environments, rather than rebuilt differently for each environment.
  • Agent capacity, image availability, and pricing change; confirm them from current Azure DevOps documentation before designing around them.

pipeline-yaml · agent-pool · jobs-steps · build-artifact · pipeline-templates · github-actions · self-hosted-agent

Diagram

azure-pipelines - Microsoft diagram

Diagrams courtesy of Microsoft Learn / Azure docs: azure/devops/pipelines/get-started/what-is-azure-pipelines

📘 Source: Microsoft Learn — What is Azure Pipelines?

pipeline-yaml

YAML pipeline

What it is

A YAML pipeline is an Azure Pipelines definition written in a YAML file stored with source code, commonly azure-pipelines.yml. It is “pipeline as code”: the automation instructions can be versioned, reviewed, and changed through the same workflow as the application.

Why it exists

Storing the pipeline in the repo means it is versioned, reviewable in PRs, and created/maintained like application code. Configuration lives beside the source it builds.

Key ideas

  • Common top-level keys include trigger, pr, pool, variables, stages, jobs, steps, extends, and resources. A pipeline does not need every key.
  • Execution is hierarchical: stages contain jobs, and jobs contain steps. This makes it possible to model build, test, and deployment work separately.
  • Templates reduce repetition. template: and extends can share approved pipeline logic, but they also create dependencies that must be reviewed and versioned carefully.
  • YAML lives in the repo. You can edit it in the Azure Pipelines experience or in any editor, then use a PR to review what the automation will do.
  • GitHub Actions also uses YAML under .github/workflows/, but its syntax and execution model are not interchangeable with Azure Pipelines YAML.

Northwind example

Northwind keeps azure-pipelines.yml beside the order API. The file triggers CI for main, defines a build stage, a test stage, and a production deployment stage, and imports a shared security-scan template. When Luis changes the pipeline, the PR shows both the application change and the exact automation change reviewers must assess.

Exam notes

  • A YAML pipeline is versioned automation, not a static configuration screen.
  • Learn the stage → job → step structure and the trigger, pool, variables, and template concepts.
  • Review pipeline changes as carefully as application changes because they can build, access, and deploy systems.

azure-pipelines · jobs-steps · ci-trigger · pipeline-templates

📘 Source: Microsoft Learn — Pipeline Yaml

ci-trigger

CI trigger

What it is

A trigger is the event or schedule that starts a pipeline run. It answers “when should this automation begin?” In Azure Pipelines, common YAML entries are trigger: for pushes, pr: for pull requests, and schedules: for scheduled runs.

Why it exists

Continuous integration should run automatically for relevant changes, without relying on someone to remember a manual run. Triggers scope that automation to the branches, paths, tags, or schedule that matter, which avoids both missed validation and unnecessary runs.

Key ideas

  • Azure Pipelines
    • trigger: — push/CI trigger. If no push trigger is specified, YAML pipelines normally trigger for pushes to all branches unless the organization’s or project’s Disable implied YAML CI trigger setting is enabled.
    • pr: — pull-request trigger; runs when a PR targets matched branches.
    • schedules: — cron-based scheduled builds (cron:, branches:, always:).
    • trigger: none disables CI.
  • GitHub Actions
    • on: defines events — push, pull_request, schedule (cron), workflow_dispatch (manual), release, etc.
    • Branch/path/tag filters via branches:, paths:, tags:.
  • A trigger starts a run; a condition decides whether an already-running job or step runs. They solve different timing decisions.

Northwind example

Northwind’s order-service pipeline triggers on pushes to main and on pull requests targeting main. A path filter avoids rebuilding the service when only its marketing documentation changes. A nightly schedule runs a slower security scan. Inside the run, a deployment job has a condition that limits production deployment to main; that condition does not start the run—it only controls one job after the run has begun.

Exam notes

  • trigger: handles push CI; pr: handles pull-request validation; schedules: handles time-based runs.
  • Path and branch filters reduce irrelevant runs but can also accidentally skip required validation if designed too broadly.
  • Trigger is distinct from a job or step condition.

pipeline-yaml · azure-pipelines · github-actions

📘 Source: Microsoft Learn — Ci Trigger

jobs-steps

Jobs, steps, and tasks

What it is

The execution hierarchy of a pipeline. Azure Pipelines organizes work as stages → jobs → steps, although a simple pipeline can use an implicit stage or job. A step can run a script, checkout, a task, or a template. In GitHub Actions, the comparable hierarchy is workflow → jobs → steps; a step runs a script or an action.

Why it exists

Breaking work into stages/jobs/steps gives control over where work runs (which pool), whether it runs (conditions/dependencies), and how output flows between phases.

Key ideas

  • Stage — a logical phase, such as build, test, or deploy. Every pipeline has at least one stage, even when it is not declared.
  • Job — the smallest schedulable unit. Its steps run sequentially on one agent. Jobs without dependencies can run in parallel when capacity is available.
  • Step — the smallest unit of work: a built-in task (PublishPipelineArtifact, DotNetCoreCLI, CopyFiles), a script:/bash:/pwsh: block, or checkout.
  • Conditions (condition: succeeded(), failed(), always()) and variables gate/fan-out execution.
  • Outputs cross job boundaries through artifacts (see build-artifact) or explicitly declared output variables referenced through dependencies. A normal variable set in one job is not automatically available to another job.

Exam notes

  • Steps execute on an agent as part of a job; separate jobs can run on different agents or pools.
  • strategy: matrix: gives parallel build variants (OS × config).
  • GitHub Actions parallels: jobs, steps, runs-on:, if:, needs:.

pipeline-yaml · agent-pool · build-artifact

📘 Source: Microsoft Learn — Specify jobs and stages, checked 2026-09-17.

build-artifact

Build artifact

What it is

A build artifact is a named set of files a pipeline publishes for later use. It can contain a compiled application, a zipped web site, deployment manifests, test evidence, or another output needed by a later job or deployment stage.

Why it exists

Different jobs and stages can run on different agents with clean workspaces. Publishing an artifact gives the next stage an explicit, reproducible input instead of assuming the build files are still on the same machine.

Key ideas

  • Publish then download. Azure Pipelines can publish a Pipeline Artifact with publish or PublishPipelineArtifact, then download it in a later stage or another pipeline. Name the artifact for what it contains.
  • Artifacts make promotion reliable. The production stage should download the binary or package that passed earlier validation, not rebuild it from a moving branch.
  • Retention is part of the design. Deleting an Azure Pipelines run deletes its associated artifacts. Retain the evidence and deployable output for as long as your recovery, audit, and release process needs.
  • Artifact is not the same as a package. A pipeline artifact is build output associated with pipeline use. A package in a package feed, such as NuGet or npm, has a versioned distribution lifecycle and its own immutability rules.

Northwind example

Northwind’s CI job compiles the order API, creates order-api.zip, and publishes it as the order-api artifact. The staging and production jobs each download that named artifact. If production needs a rollback, the team can choose a previously retained, known-good artifact rather than asking the build server to recreate old code from memory.

Exam notes

  • Publish artifacts when a later job, stage, or pipeline must consume build output.
  • “Build once, promote the same artifact” reduces accidental differences between test and production.
  • Plan retention: deleting a pipeline run can remove its associated artifacts.

azure-pipelines · github-actions · jobs-steps

📘 Source: Microsoft Learn — Build Artifact

pipeline-templates

Pipeline templates

What it is

Templates let you factor reusable YAML into separate files and include them from multiple pipelines. In Azure Pipelines there are step/job/stage templates (and extends); in GitHub Actions the equivalent is reusable workflows and composite actions.

Why it exists

Without templates, every pipeline duplicates the same build/test steps, and a one-line change means editing every pipeline. Templates centralize shared logic with parameters, keeping pipelines DRY and consistent.

Key ideas

  • Azure Pipelines
    • template: templates/steps.yml includes a step template; parameters (parameters:) pass values.
    • Job/stage templates reuse whole jobs/stages.
    • extends: template: (with parameters:) enforces a contract — pipelines must conform to the template’s structure.
  • GitHub Actions
    • Reusable workflows — call uses: owner/repo/.github/workflows/wf.yml@ref with with:/secrets:.
    • Composite actions — bundle multiple steps into one reusable action.
  • Templates support parameters with defaults, type checking, and ${{ }} expressions.

Exam notes

  • Common exam task: extract repeated steps into a template and include it via template:.
  • extends: is stricter than template: — it defines the pipeline structure.
  • GitHub Actions: reusable workflows use on: workflow_call; secrets must be explicitly passed.

pipeline-yaml · azure-pipelines · jobs-steps · github-actions

📘 Source: Microsoft Learn — Pipeline Templates

github-actions

GitHub Actions

What it is

GitHub Actions is GitHub’s built-in CI/CD automation engine. You define workflows as YAML files under .github/workflows/ in your repository; each workflow runs jobs containing steps that execute actions when triggered by repository events.

Why it exists

It keeps automation configuration with the repository. Events such as push, pull_request, and schedule can trigger workflows, and reusable actions make common steps composable.

Key ideas

  • Workflow = the automation unit; one YAML file = one workflow.
  • Events drive it (push, pull_request, workflow_dispatch, schedule); see ci-trigger.
  • Jobs run in parallel by default; steps within a job run sequentially and share a runner’s filesystem.
  • Runners execute jobs — GitHub-hosted (ubuntu/windows/macos) or self-hosted.
  • Actions are reusable building blocks (community or actions/* official).
  • Artifacts — actions/upload-artifact / actions/download-artifact share build output between jobs; see build-artifact.
  • Reusable workflows & composite actions enable reuse; see pipeline-templates.

Exam notes

  • Workflow file lives at .github/workflows/<name>.yml.
  • GitHub-hosted and self-hosted runners have different security, maintenance, and billing considerations. Check the current GitHub plan and runner documentation before estimating cost.
  • A workflow that deploys to Azure needs an appropriately scoped Azure identity and authorization; do not put a long-lived credential in the workflow file.
  • Runs (like Azure Pipelines runs) are the execution of a workflow on an event.

azure-pipelines · ci-trigger · build-artifact · pipeline-templates · self-hosted-agent

📘 Source: GitHub Docs — Workflows and workflow artifacts, checked 2026-09-17.

agent-pool

Agent pool

What it is

An agent pool is a named collection of agents that execute jobs. In Azure Pipelines you assign a job to a pool with pool:; the job then runs on any available agent in that pool.

Why it exists

Pipelines need compute to execute steps. Instead of pinning each job to one machine, a pool lets Azure Pipelines choose an available agent that meets the job’s requirements. A pool can contain Microsoft-hosted or self-hosted agents, but it is not itself a VM image.

Key ideas

  • Microsoft-hosted agents run in the built-in Azure Pipelines pool. vmImage: ubuntu-latest selects an image; it is not the name of a pool. Each job receives a fresh VM, which is discarded after that job.
  • Self-hosted pools contain agents that you register and maintain. They offer more control, but your organization is responsible for the machines, security, and capacity.
  • In Azure DevOps Services, agent pools are organization-scoped and can be shared with projects. Pool permissions and pipeline permissions control which projects and pipelines may use them.
  • One agent runs one job at a time. More eligible agents can increase concurrent jobs, subject to the available parallel-job capacity.
  • GitHub Actions equivalent: runners (GitHub-hosted or self-hosted) chosen via runs-on:.

Exam notes

  • Syntax: pool: { vmImage: 'ubuntu-latest' } selects a Microsoft-hosted image; pool: mySelfHostedPool selects a named self-hosted pool.
  • Demand/demands: — self-hosted agents can declare capabilities (e.g. dotnet), letting jobs pick capable agents.
  • Hosted pool names/vmImage values are common exam items.

self-hosted-agent · azure-pipelines · jobs-steps

📘 Source: Microsoft Learn — Create and manage agent pools, checked 2026-09-17.

self-hosted-agent

Self-hosted agent

What it is

A self-hosted agent is pipeline execution software that you install and register on a machine you control, such as an on-premises machine or VM. It joins an agent pool and runs jobs there instead of on Microsoft-hosted compute.

Why it exists

Hosted agents are convenient and maintained for you, but may not meet a private-network, custom-tool, or compliance requirement. Self-hosted agents let you control the runtime while using the same pipeline engine. They also create an operational and security boundary you must maintain.

Key ideas

  • Azure Pipelines: install, configure, register, and run the agent. A PAT is one registration option; a service principal or device code flow may also be supported. Registration credentials are not a reason to put a long-lived PAT in pipeline YAML.
  • The agent is registered in one organization-level pool; projects and pipelines are then authorized to use that pool. A job selects it with pool: <poolName>.
  • Capabilities/demands: — declare tools (e.g. java, dotnet) so jobs request capable agents.
  • GitHub Actions: self-hosted runners added at repo/org/enterprise level, chosen with runs-on: [self-hosted, linux, x64].
  • Agents are single-job at a time (one agent = one concurrent job) unless you register multiples.

Exam notes

  • Plan secure outbound connectivity to the Azure DevOps or GitHub service and apply the provider’s current network guidance. Do not expose a broad inbound management path merely to run builds.
  • If using a PAT for Azure Pipelines registration, give it only the documented agent-pool scope and protect it. Prefer another supported registration method when it better fits the environment.
  • Demand/capability matching is a classic exam item.
  • Managed agents simplify upgrades; self-hosted means you patch and maintain the machine.

agent-pool · azure-pipelines · github-actions

📘 Source: Microsoft Learn — Azure Pipelines agents and self-hosted agent authentication options, checked 2026-09-17.