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

Planned modules

Set up CI with Azure Pipelines · Use GitHub Actions for CI · Manage agents & pools · Pipeline artifacts & templates

Modules in this path

Skills

Set up CI, agents, parallelism, quality gates.

Practice questions

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 CI/CD service inside Azure DevOps that automatically builds, tests, and deploys code. It runs cross-platform (Linux, macOS, Windows) and supports every major language and both private and public cloud targets.

Why it exists

Continuous integration means compiling and validating code on every change so integration problems surface immediately instead of at release time. Azure Pipelines provides a scalable, repeatable execution engine that runs your build/test steps on Microsoft-hosted agents (or your own) with secrets, caching, and release tooling built in.

Key ideas

  • CI (continuous integration) builds & tests on every commit/PR; CD (continuous delivery) deploys the built artifact.
  • Pipelines as code — defined in YAML (recommended) or in the classic visual designer (legacy).
  • Trigger — CI/PR/scheduled triggers start a run; see ci-trigger.
  • Jobs/steps/tasks — the execution model; see jobs-steps.
  • Runs on agents & pools — Microsoft-hosted or self-hosted.
  • Free for public projects; private repos get a monthly free allocation of Microsoft-hosted minutes.

Exam notes

  • YAML-first is the current, recommended way to define pipelines (the classic editor is legacy/being phased out).
  • Azure Pipelines supports both CI and CD; the “release pipeline” concept still exists in classic mode.
  • azure-pipelines.yml is the conventional filename.
  • Pools: Microsoft-hosted (ubuntu-latest, windows-latest, macos-latest) vs self-hosted.

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 — Azure Pipelines

pipeline-yaml

YAML pipeline

What it is

A YAML pipeline is an Azure Pipelines definition written as a azure-pipelines.yml file in your repository — pipelines as code. It replaces the older classic (visual designer) editor and is the recommended way to define CI/CD.

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

  • Top-level keys: trigger, pr, pool, variables, stages, jobs, steps, extends, resources.
  • Execution model: stages → jobs → steps (see jobs-steps).
  • Schema version 2 (YAML) is current; name, resources (repos, containers, pipelines).
  • Templates let you reuse YAML via template: / extends (see pipeline-templates).
  • Edited in Azure DevOps “Pipelines” UI or directly in the repo.
  • GitHub Actions workflows are also YAML (.github/workflows/*.yml) but use a different schema (on: events, runs-on:).

Exam notes

  • Conventional filename is azure-pipelines.yml.
  • YAML-first is the recommended approach; classic editor is legacy.
  • Common exam tasks: write a trigger:, set a pool:, add steps, reference variables and templates.
  • Validate YAML in the pipeline UI; syntax errors fail the run at queue time.

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

📘 Source: Microsoft Learn — Pipeline Yaml

ci-trigger

CI trigger

What it is

A trigger is the condition that starts a pipeline/workflow run. In Azure Pipelines, trigger: (CI), pr: (pull request), and schedules: define what kicks off a run; in GitHub Actions, triggers are the events that fire a workflow.

Why it exists

CI should run automatically when relevant code changes — without a human pressing “run”. Triggers scope automation so builds fire only on the branches, paths, or schedule you care about, avoiding wasted minutes.

Key ideas

  • Azure Pipelines
    • trigger: — CI trigger; runs on push to matching branches (default: every branch). Branch/path filters narrow it.
    • 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:.
  • Triggers differ from conditions (condition:) which gate individual jobs/steps within an already-running pipeline.

Exam notes

  • Know the Azure Pipelines trigger: vs pr: keywords and that path filters reduce runs.
  • GitHub Actions on: [push, pull_request] shorthand vs full object form with filters.
  • workflow_dispatch = manual trigger in GitHub Actions (no GitHub equivalent built-in in Azure Pipelines classic CI; classic has manual run).

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. In Azure Pipelines a pipeline is made of stages → jobs → steps; each step is a task (or script/checkout). In GitHub Actions the equivalent is workflow → jobs → steps (steps call actions).

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

  • Stages — major phases (build → deploy); jobs in a stage run in parallel by default.
  • Job — a unit that runs on a single agent; has its own pool, dependsOn, condition, strategy (matrix/parallel), continueOnError.
  • 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 flow between jobs via artifacts (see build-artifact) or variable outputs (setVariable).

Exam notes

  • Only steps run on the agent; jobs may run on different agents/pools; stages are the top-level groups.
  • 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 — Jobs Steps

build-artifact

Build artifact

What it is

A build artifact is the packaged output of a pipeline — compiled binaries, packages, or files — published by a build job and consumed by later jobs or a release/deployment.

Why it exists

CI produces things (DLLs, containers, npm/yarn packages) that other jobs or CD stages need. Artifacts hand those outputs between jobs (which may run on different agents) and into releases, decoupling “build” from “consume”.

Key ideas

  • Azure Pipelines
    • Publish with the PublishPipelineArtifact / PublishBuildArtifact task (or - task YAML) from a job.
    • Download with DownloadPipelineArtifact or via download in a later job/release.
    • The build artifact is a key input to classic release pipelines.
  • GitHub Actions
    • actions/upload-artifact uploads; actions/download-artifact retrieves in later jobs.
  • Artifacts differ from packages (NuGet, npm in Azure Artifacts) — artifacts are raw build output, packages are versioned feeds.

Exam notes

  • “Publish artifacts” is required when a later job or a release pipeline needs build output.
  • In GitHub Actions use actions/upload-artifact/download-artifact to share between jobs.
  • Artifacts are per-run; they persist for the run and into associated releases.

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 CI/CD inside the repository host — no separate tool — so “code + automation live together.” Events like push, pull_request, and schedule drive workflows, and the action ecosystem (actions/checkout, actions/upload-artifact) makes 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 runner pricing/free minutes for private repos vs free for public.
  • GitHub Actions can deploy to Azure (Azure login action, service principals); common in AZ-400.
  • 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: Microsoft Learn — Github Actions

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 gives elasticity: many agents, parallelism, and choice between Microsoft-managed and your own hardware.

Key ideas

  • Microsoft-hosted pools — pre-provisioned, managed VMs; named by OS (ubuntu-latest, windows-latest, macos-latest). Zero setup; billing by hosted minutes.
  • Self-hosted pools — you register your own agents into a pool (org/project level). More control, no per-minute cost, but you maintain them.
  • Organization vs project pools — org-level pools are shared; project pools are scoped to one project.
  • Parallelism — more agents in a pool ⇒ more concurrent jobs.
  • GitHub Actions equivalent: runners (GitHub-hosted or self-hosted) chosen via runs-on:.

Exam notes

  • Syntax: pool: vmImage: 'ubuntu-latest' (Microsoft-hosted) vs pool: mySelfHostedPool (self-hosted).
  • 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 — Agent Pool

self-hosted-agent

Self-hosted agent

What it is

A self-hosted agent is the pipeline execution software you install and register on a machine you control (on-prem VM, a cloud VM, a container, or your laptop). It joins an agent pool and runs jobs there instead of on Microsoft/GitHub-hosted compute.

Why it exists

Microsoft-hosted/GitHub-hosted agents give convenience but no control: you can’t install custom tools, keep secrets on-prem, meet compliance/network requirements, or avoid per-minute billing. Self-hosted agents let you bring your own runtime while staying part of the same pipeline engine.

Key ideas

  • Azure Pipelines: install the agent (./config.sh), configure with a PAT + pool/agent name, register, and start (./run.sh). Agent needs outbound HTTPS to Azure DevOps; uses polling for jobs.
  • Registered at organization (pool) or project scope; jobs select it via 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

  • Self-hosted agent requires outbound internet to Azure DevOps / GitHub; no inbound required (agents poll).
  • Use a PAT with the correct scope (Agent Pools: Read & manage) when configuring.
  • 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 — Self Hosted Agent