GCP Prep
Browse all topics
DevOps4 min readUpdated August 20, 2026

CI/CD and Build Automation

In one sentence

A pipeline is an assembly line for software — it takes a commit, proves it works, packages it, and moves it towards production without anyone typing a deployment command.

What it is

Continuous integration means every change is merged and automatically verified frequently, rather than accumulating on branches for weeks. Continuous delivery means every verified change is automatically prepared for release, so deploying becomes a decision rather than a project.

In practice this is a pipeline: a defined sequence of steps triggered by a commit. Each step either passes and hands work to the next, or fails and stops the change from progressing.

Why it matters

Deployment risk is not proportional to how often you deploy — it is proportional to how much changes in each deployment. Teams that deploy rarely deploy large batches, which makes each release riskier, which makes them deploy even more rarely. Automation breaks that loop.

There is a security dimension too. A pipeline is the natural place to scan dependencies, verify image provenance and enforce that nothing reaches production without passing the same checks. Doing this by convention rather than automation reliably fails.

Key concepts

  • Trigger — what starts the pipeline: a push to a branch, a pull request, a tag, or a schedule.
  • Build step — one unit of work in the pipeline, usually running inside a container so the environment is reproducible.
  • Artefact — the immutable output of a build, typically a container image. The same artefact should be promoted through environments rather than rebuilt for each one.
  • Artefact registry — where built images and packages are stored, versioned and scanned for vulnerabilities.
  • Quality gate — a check that must pass before the change proceeds: tests, coverage thresholds, vulnerability scans, policy checks.
  • Environment promotion — moving one artefact from development to staging to production, changing only configuration.
  • Rollback — the ability to return to the previous known-good version quickly, which matters more than any other single reliability property.

A typical pipeline

  1. 1Commit pushed to the source repository
  2. 2Build — compile, run unit tests, produce a container image
  3. 3Scan — check dependencies and the image for known vulnerabilities
  4. 4Publish — push the immutable artefact to a registry with a version tag
  5. 5Deploy to staging — run integration and smoke tests against a real environment
  6. 6Approve — automatic, or a human decision for higher-risk changes
  7. 7Deploy to production — progressively, with automated rollback on failure
Each stage is a gate; a failure stops promotion rather than being reported later.

Deployment strategies

StrategyHow it worksBest for
RollingReplace instances a few at a time until all run the new version.The sensible default. Low infrastructure cost, gradual exposure.
Blue/greenRun the new version alongside the old, then switch all traffic at once.Fast, complete rollback. Costs double capacity during the switch.
CanarySend a small percentage of traffic to the new version and watch metrics before increasing.High-risk changes where you want real production signal before committing.
Feature flagDeploy the code disabled, then enable it for selected users at runtime.Decoupling deployment from release entirely; targeted rollout.

The exam-relevant nuance is that these are not ranked from worst to best. Canary is not simply the best option — it requires meaningful traffic to produce a useful signal and monitoring good enough to detect a problem in a small slice. For a low-traffic internal service, rolling is the correct answer and canary is over-engineering.

Common use cases

  • Automatically building and testing every pull request before it can be merged.
  • Blocking any container image with a critical vulnerability from reaching production.
  • Promoting a single tested image through staging into production without rebuilding.
  • Rolling out a risky change to five per cent of traffic and automatically reverting if error rates rise.
  • Rebuilding an entire environment from version-controlled infrastructure definitions.

Certification relevance

Where this topic appears, and how deeply each exam goes into it. These are our own assessments based on published exam guides.

Practice questions

DevOps practice questions

5 original questions with full explanations.