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
- set-up-ci-with-azure-pipelines — author a YAML pipeline that builds/tests on every change
- use-github-actions-for-ci — workflows, events, jobs/steps in GitHub Actions
- agents-and-pools — Microsoft-hosted vs self-hosted agents, pool routing
- pipeline-artifacts-and-templates — sharing build output and reusing pipeline logic
- pipeline-components-and-stage — stages/jobs/steps/tasks, ordering, dependencies, variables & secrets
- advanced-yaml-pipelines — schema keywords, queues, and reusable job snippets
- pipeline-evaluation-and-quality-gates — automated tests, coverage, and merge-blocking quality gates
- webhooks-and-triggers — push/PR/schedule triggers and external webhook invocation
- pipeline-run-diagnostics-and-maintenance — run retries, timeouts, debugging, and upkeep
- pipeline-security-controls — approval gates, least-privilege agents, secrets in pipelines
- pipeline-integration-tests — integration/E2E tests, test data, containers for test deps
- dependency-and-supply-chain — dependency scanning, artifact signing, reproducibility
- branch-protection-and-policies — protecting main, PR policies, required reviews
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
- az400-q-ci-001 — Azure Pipelines vs GitHub Actions
- az400-q-ci-002 — self-hosted build agents
- az400-q-ci-003 — reusing steps with pipeline templates
- Q: tests, approvals, and retention
- Q: runner infrastructure
- Q: test strategy
- Q: secretless Azure deployment
- Q: Classic-to-YAML migration
- Q: reusable secure YAML
- Q: dependent deployments
- Q: progressive feature exposure
- Q: reproducible package release
- Q: pipeline concurrency
- Q: parallel jobs and dependencies
- Q: controlled hotfix
- Q: IaC drift
- Q: package feeds and upstreams
- Q: PR triggers and path filters
- Q: shared production environment checks
- Q: least-privilege service connection
- Q: flaky pipeline tests
- Q: retention policy
- Q: IaC what-if review
- Q: secure pipeline templates
- Q: hosted versus self-hosted execution
- Q: SemVer and CalVer
- Q: governed on-demand environments
- Q: desired-state configuration
- Q: test evidence and coverage
- Q: idempotent deployment retries
- Q: GitHub-to-Azure-Pipelines integration
- Q: variables, secrets, and federation
- Q: deployment rings
- Q: release-stage load testing
- Q: agent capabilities and demands
- Q: build once, promote artifacts
- Q: automated release notes
- Q: deployment concurrency
- Q: third-party action supply chain
- Q: Terraform state locking
- Q: approval versus automated check
- Q: dependency caching and cost
- Q: schedule migration
- Q: artifact tampering boundary
- Q: production pipeline authorization
- Q: A/B rollout telemetry
- Q: diagnosable deployment scripts
- Q: controlled Bicep parameters
- Q: dependency version resolution
- Q: pipeline queue-time diagnosis
- Q: operational rollback criteria
- Q: Classic release migration
- Q: stop a bad rolling deployment
- Q: isolate untrusted agents
- Q: govern shared templates
- Q: promote a tested package
- Q: immutable container image
- Q: canary-compatible schema change
- Q: secret-safe diagnostics
- Q: actionable pipeline failure context
- Q: evidence retention exception
- Q: flag-off versus rollback
- Q: select GitHub Actions or Azure Pipelines
- Q: isolate integration-test dependencies
- Q: bounded retry and backoff
- Q: audit a protected environment
- Q: backwards-compatible API change
- Q: validate shared YAML templates
- Q: clean up temporary environments
- Q: detect VM configuration drift
- Q: measure pipeline health
- Q: order dependent deployments
- Q: deploy a binary safely
- Q: retire old pipeline assets
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
- AZ-400 course overview, checked 2026-08-31.
- AZ-400 study guide, checked 2026-08-31.
Re-audit when the AZ-400 course path, study-guide effective date, or the services and permissions taught here change.