AZ-400 exam questions on CI/CD pipelines test how you design the full automation chain from a developer's laptop to production. The exam focuses on differences between Azure Pipelines and GitHub Actions, YAML structures, trigger filtering, reuse mechanisms, and runner selection. Both platforms sit inside the Microsoft ecosystem, but their philosophies differ — the exam repeatedly asks which one fits a given situation. The answer is always inside the scenario conditions.
CI and CD — Putting Sensors on the Assembly Line
Imagine an automobile assembly line where parts move to the next station without any quality check. Defects only surface at the final inspection, when fixing them is most expensive. Ten developers working simultaneously discover on Monday that everything is in conflict. CI (Continuous Integration) solves this by automatically running a build and tests every time code is merged, catching problems at the earliest possible moment.
CD has two forms. Continuous Delivery automatically delivers validated artifacts to staging but keeps a manual approval gate before production. Continuous Deployment removes that gate entirely and deploys straight to production. The exam distinction: a manual approval anywhere before production means Delivery; nothing standing between the pipeline and production means Deployment.
Azure Pipelines vs GitHub Actions — Choosing a Platform
Picture two stores side by side. One is a full-service department store with a specialized DevOps wing (Azure Pipelines). The other is a developer-community concept shop with an enormous selection of ready-made components (GitHub Actions). Which one you pick depends almost entirely on what you already own.
Azure Pipelines is part of the Azure DevOps platform, integrating tightly with Azure Repos, Azure Boards, and Azure Artifacts. It connects to Bitbucket, GitHub, GitHub Enterprise, and Azure Repos as source systems, so you are not locked to a single Git host. Enterprise features — deployment groups, variable groups, service connections, and multi-stage pipelines — are built in.
GitHub Actions is a workflow automation platform fully integrated with GitHub repositories. Workflows live as YAML files under . Over 15,000 Actions are available in the GitHub Marketplace. Every GitHub event (push, pull_request, schedule, workflow_dispatch) can be a trigger, keeping code and CI/CD on the same platform.
| Situation | Recommendation | |-----------|----------------| | Source on GitHub, open-source environment | GitHub Actions | | Existing Azure DevOps adoption, Git-host independence | Azure Pipelines | | On-premises source | Azure Pipelines | | PR-driven validation as the primary pattern | GitHub Actions |
!Azure Pipelines versus GitHub Actions
YAML Structure and Triggers
Think of a restaurant kitchen. When an order arrives, the appetizer station fires first, then main course, then dessert. Within each station, multiple cooks work in parallel. CI/CD pipelines follow the same hierarchical model.
Azure Pipelines YAML is structured as . A Stage is a logical phase (Build, Test, Deploy). A Job runs on a single agent. A Step is an individual Script or Task. GitHub Actions uses with no Stage concept; the keyword expresses Job-level dependencies.
Triggers: in Azure Pipelines, (branch push), (Pull Request), and (cron runs) are separate keywords. In GitHub Actions, events list under . Path filters narrow pipelines to fire only when files under a specific directory change — essential in monorepos. In glob patterns, does. matches but does not — the exam returns to this distinction repeatedly.
Without , Jobs run in parallel by default. runs even when a prior stage failed; skips only on cancellation. A step publishing test results must use so results are visible even when tests fail.
Reuse — Templates, Reusable Workflows, and Environments
Instead of rewriting the company letterhead on every document, you open a shared template and fill in the unique content. Pipeline reuse works the same way.
Azure Pipelines templates are separate YAML files defining Stages, Jobs, Steps, or Variables, referenced with . When stored in a dedicated template repository, reference them via and pin with or a commit SHA. Pointing at the main branch lets unvalidated changes propagate to every production pipeline immediately.
GitHub Actions reusable workflows are invoked via , accepting and as parameters, with up to four levels of nesting. A composite action packages multiple Steps into a single shareable or publishable Action.
An environment represents a deployment target (development, staging, production). A Job linked to an environment tracks deployment history and enforces gate checks: approvals, required template checks, pipeline permissions, and business hours checks — all configured independently per environment. To restrict which pipelines can reach production, use environment pipeline permissions, not the service connection's security tab. A variable group linked to Azure Key Vault loads secrets dynamically at runtime, keeping plain text out of YAML files.
Runner Selection — Microsoft-hosted vs Self-hosted
Renting a car (Microsoft-hosted runner) means the rental company handles maintenance — you just drive. But accessing a private garage that only admits company vehicles requires owning your own car (self-hosted runner). The right choice depends on where you need to go.
Microsoft-hosted runners provision a fresh VM for every build and discard it on completion. Microsoft handles OS patching, tooling, and availability. Windows Server, Ubuntu, and macOS images are available with common build tools pre-installed. These runners cannot reach internal network resources not exposed to the internet.
Self-hosted runners install on organization-managed machines, reaching resources behind a firewall. The agent uses an outbound pull model over HTTPS port 443, so no inbound firewall rules are needed. Scale set agents auto-scale runner count based on queue depth while keeping the network access of self-hosted runners. Container jobs run each job inside a Docker container image on top of a self-hosted runner, isolating dependencies per service.
When queues are overloaded and internal network access is not needed, buying additional parallel jobs has lower operational overhead than deploying self-hosted runners.
Exam Key Takeaways
"Source on GitHub, open-source environment" -- GitHub Actions "Existing Azure DevOps adoption, Git-host independence" -- Azure Pipelines vs -- matches only one "Must publish results even when tests fail" -- "Run immediately, no dependency on prior stages" -- "Allow only specific pipelines to deploy to production" -- environment pipeline permissions (not service connection security) "Keep secrets out of YAML" -- variable group linked to Azure Key Vault "Prevent template changes from propagating to production" -- pin with a tag or commit SHA "Need access to internal network resources" -- self-hosted runner "Minimize operational overhead, need auto-scaling" -- Microsoft-hosted runner or scale set agent "Trigger for calling a reusable workflow" -- event CI = automated build and test on every commit / CD Delivery = auto-deliver to staging, manual approval for production / CD Deployment = fully automated to production