CI/CD explained: pipeline stages and gates
CI/CD is automation of the path from a code commit to running software. Continuous integration builds and tests every change merged into the shared branch; continuous delivery keeps every build releasable and deploys it through environments with a human deciding when to go to production; continuous deployment removes that human decision. The deciding question on an exam is always the same: is there a manual step before production?
Three terms, one line each
- Continuous integration (CI). Microsoft defines it as automatically building and testing code every time a team member commits to version control. A commit to the main branch triggers a build, tests and validation. The point is to merge often, so conflicts and bugs surface early.
- Continuous delivery (CD). Microsoft describes it as automating build, test, configuration and deployment from a build to a production environment through a release pipeline. Successive environments support progressively longer-running integration, load and user acceptance tests.
- Continuous deployment. The common usage of the term is delivery without the final manual approval: every change that passes all automated checks goes live. Microsoft’s pages use “continuous delivery” for the whole pipeline and allow an optional manual approval before the next ring, so the strict distinction is a convention that exams apply, not a Microsoft definition. Read the stem for whether a person approves production.
The initials CD are therefore ambiguous. When an exam writes “CD”, check whether the stem says approval is required.
How a pipeline is shaped
A pipeline is a sequence of stages, each with jobs and steps. Later stages run only if earlier ones succeed, and the cheap, fast checks run first. Microsoft calls this fail fast.
| Stage | What it does | Typical failure it catches |
|---|---|---|
| Build | Compile or package, produce an artifact once | Syntax errors, missing dependencies |
| Unit and static tests | Run tests, scan code and dependencies | Logic bugs, known-vulnerable packages |
| Deploy to test | Install the artifact in a test environment | Configuration mistakes |
| Integration, load, acceptance | Slower tests against the running system | Behaviour that unit tests cannot see |
| Deploy to production | Promote the same artifact, often by ring or canary | Problems that appear only under real traffic |
Build the artifact once and promote that same artifact through the environments. Rebuilding for each environment means the thing tested is not the thing shipped.
Approvals and gates
Two controls sit between stages, and exams treat them as different things.
- Approval. A person signs off. In Azure Pipelines, approvals and checks are configured on the resource, for example an environment, in the web interface, not in the YAML file. Microsoft states that people editing the YAML cannot change the checks performed before a stage starts. Approvers can be users or groups, and if a group is approver one member is enough. An approval has a timeout, and when it expires the stage is skipped.
- Gate or automated check. A system decides. Azure Pipelines offers checks such as branch control, required template, invoke Azure Function, invoke REST API, business hours and query Azure Monitor alerts. The last one passes only when no alert rule is firing, which suits canary rollouts. All checks on all resources used by a stage must pass before it starts.
GitHub Actions uses the same idea with a different name. An environment can have protection rules: required reviewers (up to six, and one approval is enough), a wait timer, and limits on which branches and tags may deploy. A job that references the environment waits for the rules before it runs or sees the environment secrets. Plans matter for private repositories: on GitHub Free, Pro and Team, required reviewers and wait timers work only in public repositories, so private repositories need GitHub Enterprise for them.
A worked example
A team builds a container image for an API. The pipeline: on merge to main, build the image and run unit tests; push the image to a registry; deploy to a staging environment and run smoke tests; deploy to production.
The security officer wants production deployments approved by the release manager, and wants that to hold even if a developer edits the pipeline file. The answer is an approval on the production environment, not a manual step inside the YAML. The team also wants production deployment to proceed only when no monitoring alerts are firing in staging. Add an Azure Monitor alerts check on the environment. If both are on one environment, the stage waits for both. A business-hours check can also keep deployments out of the overnight window.
Which exams test this
| Exam | How the topic appears | Where covered on this site |
|---|---|---|
| AZ-400 | Design and implement build and release pipelines (50–55%): quality and release gates, trigger rules, multi-stage pipelines, checks and approvals on YAML environments, and deployment strategies such as blue-green, canary and ring | Build and release pipelines |
| DP-800 | Secure, optimize, and deploy database solutions (35–40%), outline as of October 19, 2026 (the earlier version differs only in minor areas): CI/CD with SQL Database Projects, including a testing strategy, source control, and controls on deployment pipelines such as branching policies, approvals and code owners | Secure, optimize and deploy |
| 200-901 | Application Deployment and Security (15%): describe the components of a CI/CD pipeline for application deployments; Infrastructure and Automation (20%): the components and benefits of a CI/CD pipeline for infrastructure automation | Application deployment and security and infrastructure automation |
| Databricks Data Engineer Associate | Implementing CI/CD (10%): branches and pull requests in Git folders, and Declarative Automation Bundles with environment-specific settings to promote the same code across dev, test and prod | Jobs and CI/CD |
| Databricks Data Engineer Professional | Debugging and Deploying (10%): deploy resources with Declarative Automation Bundles and set up Git-based CI/CD with Git folders | Monitoring and deploying |
| DP-750 | Deploy and maintain data pipelines and workloads (30–35%): development lifecycle with Git, a testing strategy from unit tests to UAT, and packaging and deploying bundles with the Databricks CLI | Deploy and maintain pipelines |
| MLA-C02 | Deployment and Orchestration of ML and AI Workflows (24%): CI/CD pipelines for MLOps with AWS CodePipeline, CodeBuild and CodeDeploy, automated testing, deployment strategies and rollback | Deployment and orchestration |
| AI-300 | MLOps infrastructure (15–20%): automate resource provisioning with GitHub Actions workflows; model lifecycle (25–30%): progressive rollout and safe rollback | MLOps infrastructure |
| AI-103 | Plan and manage an Azure AI solution (25–30%): integrate Foundry projects with CI/CD pipelines | Plan and manage |
| Databricks Generative AI Engineer | Assembling and Deploying Applications (22%): apply CI/CD practices such as promoting prompts across environments and testing agent components | Assembling and deploying |
| DP-600 | Maintain a data analytics solution (25–30%): version control for a workspace and Fabric deployment pipelines. Fabric’s own promotion tool, not a general CI/CD pipeline | Maintain a solution |
| DP-700 | Implement and manage an analytics solution (30–35%): version control, database projects and Fabric deployment pipelines | Implement and manage |
| AB-620 | Minor topic. Test and manage agents (20–25%), application lifecycle management for agents: implement and extend Power Platform Pipelines to promote solutions between environments | Test and manage |
| SY0-801 | Minor topic. Security Operations (27%): CI/CD is listed among SecOps uses of automation and orchestration. SY0-801 launches November 17, 2026; SY0-701 is the live exam until then | Security operations |
| CY0-001 | Minor topic. AI-assisted Security (24%): CI/CD with code scanning, software composition analysis, testing and automated deployment and rollback | CY0-001 AI-assisted security explained |
How the questions are built
The traps repeat:
- Where is the control configured? “Cannot be removed by editing the YAML” means an environment check. “Prevent unreviewed code reaching main” means a branch policy or branch protection, which is a CI-side control, not a deployment approval.
- Approval or gate? “A manager must sign off” is an approval. “Proceed only if no alerts” or “only if a REST call returns success” is an automated check.
- Delivery or deployment? Presence of a manual production step decides.
- Which stage failed? A failing test stage stops the pipeline before deploy. The answer is never to skip the stage.
- Rollout style. “Limit the impact on users” points to rings, canary or blue/green, where Microsoft’s guidance is to monitor and roll forward or reroute.
Question 1. A YAML pipeline deploys to a production environment. A compliance rule says each production deployment needs sign-off from the release managers group, and developers who can edit the YAML must not be able to remove that sign-off. What should you configure?
- A. A manual validation step in the pipeline YAML
- B. An approval check on the production environment
- C. A branch policy on the main branch
- D. A variable group with restricted permissions
Show answer
Answer: B
Approvals and checks belong to the resource, here the production environment, and are managed outside the YAML, so editing the pipeline file does not change them. A manual validation step in the YAML can be edited out. A branch policy governs merging, not deployment. Variable groups hold values and cannot require sign-off.
Question 2. After a release goes to production, a team wants the next ring to receive the update only if no Azure Monitor alert rules are firing for the application, without a person reviewing each rollout. Which control fits?
- A. A manual approval on each ring
- B. A required template check on the service connection
- C. A query Azure Monitor alerts check on the environment
- D. A business hours check on the environment
Show answer
Answer: C
A check that queries Azure Monitor alerts passes only when no alert rule is active, so the pipeline decides automatically and the rollout continues to the next ring when the application is healthy. A manual approval needs a person. A required template check controls which YAML template a pipeline extends, not application health. A business hours check only restricts when deployments run.
Go deeper
- What is continuous integration? and What is continuous delivery?, Microsoft’s definitions and the ring, canary and blue/green techniques.
- Define approvals and checks, the Azure Pipelines page with the full list of checks and their order.
- Managing environments for deployment, the GitHub Actions equivalent.
- On this site: Git branching strategies for what feeds the pipeline, the AZ-400 cheat sheet, and how to study for certification exams.