Building a CI/CD pipeline

Why this matters

The pipeline is where everything in this domain meets: source control triggers it, automation runs inside it, and it is how images, infrastructure and applications reach production.

It is also, quietly, one of the most privileged systems an organisation owns. A pipeline that can deploy to production holds credentials that can create, modify and destroy infrastructure, and it does so without a human present. That combination has made pipelines a favoured target, and the security half of this lesson matters as much as the mechanics.

CompTIA asks about building and managing CI/CD pipelines, which sets the depth: know the stages, know what each is for, know the failure modes.

The lesson

Continuous integration: build and test on every change, and the fast feedback it buys

Continuous integration means every change is merged to the mainline frequently — at least daily — and every merge triggers an automated build and test.

The problem it solves is integration pain. When developers work separately for weeks, merging produces a long, unpredictable period of conflict resolution and surprise breakage. Integrating continuously keeps each merge small, so conflicts are small and problems surface within minutes of the change that caused them, while the author still has it in mind.

What a CI stage typically does: fetch the change, build, run unit and integration tests, run static analysis and linting, scan dependencies for vulnerabilities, scan for secrets, and publish a versioned artefact.

The properties that make CI work rather than exist:

• Speed. Feedback within minutes. A build taking an hour stops being read; people carry on and check later, which removes the point. Optimise it deliberately — parallelism, caching, running the slowest tests separately.
• Reliability. Flaky tests are corrosive, because a suite that fails randomly teaches everyone to re-run rather than investigate — and then a real failure is re-run too. Fix or quarantine flaky tests promptly; this is worth more attention than it usually gets.
• A broken build is stopped work. If the mainline is broken, fixing it comes before new work, or the team builds on a broken base.
• It must actually run on every change, including infrastructure and configuration changes.

Continuous delivery against continuous deployment, and the gate between them

Two terms sharing an abbreviation, and the exam distinguishes them.

• Continuous delivery. Every change that passes the pipeline is deployable and is automatically deployed to a staging environment. The final promotion to production is a human decision — one click, but a decision.
• Continuous deployment. Every change that passes is automatically deployed to production, with no human gate.

Both automate the whole path; the difference is only whether a person approves the last step.

Continuous deployment demands a great deal of confidence in the tests, and it requires strong safety mechanisms: comprehensive automated testing, canary or progressive rollout (objective 3.1), automatic rollback on regression, feature flags so code can ship without being active, and observability good enough to detect a problem in minutes.

Continuous delivery is the right answer for most organisations, and especially where a regulatory regime requires an approval record. A scenario mentioning a change-approval requirement is describing continuous delivery; one mentioning deploying dozens of times a day with automatic rollback is describing continuous deployment.

The gate, where it exists, should be fast and informed — the approver needs to see what is changing, what the tests said, and what happened in staging. An approval step that takes three days for a form to be signed has reintroduced exactly the delay the pipeline removed, and it is where automation and change management have to be reconciled rather than fought.

Pipeline stages, artefacts, and promoting the same artefact through environments

A conventional pipeline, front to back:

1. Source. Triggered by a commit or a pull request.
2. Build. Compile, package, build the container image. Produces the artefact.
3. Test. Unit, integration, and whatever else runs quickly.
4. Scan. Dependencies, image, infrastructure code, secrets.
5. Publish. Push the artefact to the registry, tagged with the commit identifier.
6. Deploy to staging, then run smoke and acceptance tests.
7. Approve, for continuous delivery.
8. Deploy to production, progressively.
9. Verify, and roll back automatically on regression.

The principle that matters most is build once, promote the same artefact. The thing tested in staging must be the identical bytes deployed to production — identified by digest, not by tag (objective 4.3). Rebuilding per environment means the tested artefact and the deployed artefact are different builds, and the difference is precisely where an unrepeatable problem lives.

Configuration, therefore, is supplied per environment, not baked into the artefact — from the environment's own parameters and its secret store. That is the same discipline as objective 2.2's parameterisation, and it is what makes one artefact usable everywhere.

Two further points:

• Artefacts must be immutable and retained. You cannot roll back to a version that has been deleted, and retention should outlast the longest plausible rollback window.
• Infrastructure has its own pipeline with the same shape — validate, policy scan, plan, approve, apply — and the plan output is what the approver reads.

Automated testing in the pipeline, including security and policy checks

Testing in a pipeline is a ladder from fast-and-narrow to slow-and-broad, and the ordering is deliberate: fail cheaply and early.

• Unit tests. Seconds. Run on every commit.
• Integration tests. Minutes, against real dependencies or good substitutes.
• Contract tests, where services integrate, confirming that each side still honours the agreed interface (objective 5.4).
• End-to-end tests. Slow and the most prone to flakiness. Keep few and focused on critical journeys.
• Performance tests, at least for significant changes, and compared against a baseline (objective 3.3).
• Smoke tests after deployment, which are the ones that actually protect production.

The security and policy checks belong in the same ladder, and they are the "shift left" idea in practice:

• Static application security testing — analysing source for security flaws.
• Dependency and software-composition scanning, which finds most real vulnerabilities because most code is dependencies.
• Secret scanning (objective 5.2).
• Infrastructure-as-code policy scanning (objective 2.2) — no public buckets, no unencrypted storage, no over-broad roles.
• Container image scanning (objective 4.3).
• Dynamic testing against a running instance in staging.

Gate on these sensibly. A gate that fails the build on every medium finding stops all delivery and gets disabled or bypassed, which leaves you worse off than a gate that fails only on critical-and-exploitable with a documented exception path. A control that gets turned off protects nothing — that judgement is itself examinable.

Pipeline credentials, and the pipeline as a high-value target in its own right

The pipeline can deploy to production. Therefore compromising the pipeline is compromising production, without touching production directly — and attacks on build systems have become a standard supply-chain route precisely because of this.

The controls, and they are the part of this lesson most worth carrying:

• No long-lived credentials. Use federated workload identity: the pipeline presents a token proving which repository and which branch it is running for, and exchanges it for short-lived cloud credentials. This removes the stored deployment key entirely, and it is the single most valuable improvement available here.
• Least privilege, scoped per environment. The pipeline deploying an application does not need permission to alter the network or identity policies. Separate credentials per environment, so a compromise of the development path does not reach production.
• Protect the production path. Deployment to production should be possible only from the protected main branch, only from the reviewed pipeline definition, and ideally requiring an approval that a single person cannot self-grant.
• The pipeline definition is code and must be reviewed. A pipeline file that anyone can edit in a feature branch — and that then runs with deployment credentials — is an obvious escalation path, and it is a real and common misconfiguration.
• Pin and vet third-party actions and plugins. Pipeline steps pulled from public sources execute with your credentials. Pin them by immutable revision rather than a moving tag, and treat adding one as a supply-chain decision.
• Isolate runners. Jobs from different trust levels should not share a runner or its caches. Ephemeral runners destroyed after each job are the strong pattern; a persistent shared runner accumulates whatever previous jobs left behind.
• Log everything, and alert on unusual pipeline activity — deployments outside working hours, changes to the pipeline definition, unexpected credential use.

The summary worth remembering: the pipeline is production infrastructure. Treat it with the access control, review and monitoring you would apply to a production system, because in every way that matters to an attacker it is one.

What to take into the exam

• CI = merge and test on every change, with fast feedback. Flaky tests are corrosive; a broken mainline is stopped work.
• Continuous delivery = automated to staging, human approves production. Continuous deployment = no human gate, and it requires canary rollout, automatic rollback, feature flags and strong observability.
• Build once and promote the same artefact by digest. Configuration is supplied per environment; artefacts are immutable and retained long enough to roll back to.
• Shift security left: dependency, secret, IaC and image scanning in the pipeline — gated sensibly, because a control that gets bypassed protects nothing.
• The pipeline is a production system. Use federated short-lived credentials, least privilege per environment, reviewed pipeline definitions, pinned third-party steps, and ephemeral isolated runners.