Continuous Delivery & Platform Engineering

This is the domain where a platform stops being a diagram and starts moving software. The official CNPA curriculum lists five competencies here — Continuous Integration Pipelines Overview, Incident Response in Platform Engineering, CI/CD Relationship Fundamentals, GitOps Basics and Workflows, and GitOps for Application Environments — worth 16% of the exam. CNPA is knowledge-based and multiple-choice, so the goal here is not muscle memory: it is being able to state, quickly and correctly, what each piece is, what it is not, and which one a one-sentence scenario is describing.

What this 16% domain actually asks of you

☺ Like you’re 10: Five topics, and the exam mostly wants you to tell them apart — not to build them.

Every question in this domain is recall or recognition: a short scenario, then “which practice is this?”, “which tool category fits?”, or “which principle is being violated?”. So the highest-value study move is building crisp boundaries — CI is not CD, continuous delivery is not continuous deployment, a pipeline that runs kubectl apply is not GitOps, and an environment is not a cluster.

For context on where the 16% sits: the published curriculum weights its six domains 36% + 20% + 16% + 12% + 8% + 8% = 100% — Platform Engineering Core Fundamentals, Platform Observability, Security & Conformance, this domain, Platform APIs and Provisioning Infrastructure, IDPs and Developer Experience, and Measuring your Platform. The full map, with every competency listed in the curriculum’s own words, is on the CNPA hub; the neighbouring 36% domain also carries a “Continuous Delivery and GitOps” competency, so revise Core Fundamentals alongside this page rather than after it.

How CNPA phrases delivery questions

Four stems recur. “A team wants X — which practice or tool category?” tests vocabulary. “Which of these violates a GitOps principle?” tests the four principles as a checklist. “What is the first action during an incident?” rewards restore service over find root cause. And “what does the pipeline do last?” rewards publish an artifact and update desired state over deploy to the cluster. Learn those four reflexes and you have most of the 16%.

CI/CD Relationship Fundamentals

☺ Like you’re 10: One machine builds and checks the toy. A different machine hands it out. They are friends, but they are not the same machine.

Continuous Integration (CI) merges every developer’s work into a shared mainline frequently — many times a day — and proves after each merge that the system still works. Its outputs are a verdict (pass/fail) and an artifact, usually an immutably tagged container image. CI answers “is this change safe?”

Continuous Delivery (CD) keeps every successful build in a releasable state, with an automated, repeatable path to any environment — a human still chooses when. Continuous Deployment removes that human: every build passing the gates goes to production automatically. The exam cares that you can separate those two “CD”s.

The three terms, side by side

Where CI ends and CD begins — the handoff

The cleanest platform boundary, and the one the exam keeps circling, is this: CI pushes, CD pulls. A GitOps-aligned pipeline does not finish by running kubectl apply or helm upgrade against a cluster. It finishes with two safe writes — publish the image to a registry, then commit a change to the config repository that references the new image tag — and then it stops. A reconciler inside the cluster takes it from there.

Name the three things that boundary buys: the pipeline holds no cluster credentials (a compromised CI runner cannot reach production); every deployment is a reviewable, revertible commit; and “what is supposed to be running?” has exactly one answer, in one place.

Continuous Integration Pipelines Overview

☺ Like you’re 10: A pipeline is a checklist a robot runs the same way every single time, and it stops the moment something fails.

A pipeline is an automated, triggered sequence of stages run in a clean, reproducible environment. Three properties define it: event-triggered (a push, pull request, tag, schedule or webhook), fail-fast (cheapest checks first, so feedback arrives in minutes), and hermetic (each run starts from a known state, so the result depends on the commit and nothing else).

The stages you should be able to list

Name them in order and most “which stage does X?” questions answer themselves: source (check out the exact commit) → build (compile, produce a container image) → test (unit, integration, contract/e2e) → static analysis (lint, type-check, manifest validation) → security scan (dependency and image CVE scanning, secret detection, SBOM generation) → package & sign (tag immutably, sign with Sigstore cosign) → publish (push to a registry) → promote (write the new version into the config repo). Everything after publish is the baton pass to CD.

Two words travel with pipelines. Artifacts are a run’s durable outputs — images, SBOMs, test reports. Gates are conditions that must hold for the run to proceed; a gate that cannot fail the build is not a gate, it is a report.

Kubernetes-native pipelines: Tekton and Argo Workflows

CNPA is a cloud-native exam, so know that pipelines themselves can be Kubernetes resources. Tekton models CI as custom resources — a Task is a sequence of containerised steps, a Pipeline wires Tasks together, and TaskRun/PipelineRun objects are the executions. Argo Workflows is a container-native workflow engine (DAG or steps) used for CI and for data/ML jobs. Both run every step as a pod, so CI inherits Kubernetes RBAC, scheduling and autoscaling for free.

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-scan-publish
spec:
  params:
    - name: repo-url
    - name: image           # e.g. registry.example.com/checkout
    - name: revision        # immutable tag — a commit SHA or a version like 2.7.0
  workspaces:
    - name: source
  tasks:
    - name: fetch
      taskRef: { name: git-clone }
      workspaces: [{ name: output, workspace: source }]
      params:
        - name: url
          value: $(params.repo-url)
    - name: unit-tests
      runAfter: [fetch]                 # fail fast, cheapest first
      taskRef: { name: golang-test }
      workspaces: [{ name: source, workspace: source }]
    - name: build-image
      runAfter: [unit-tests]
      taskRef: { name: kaniko }         # daemonless image build
      params:
        - name: IMAGE
          value: $(params.image):$(params.revision)
    - name: scan
      runAfter: [build-image]
      taskRef: { name: trivy-scan }     # gate: fails on CRITICAL
    - name: bump-config-repo            # LAST step — commit, do not apply
      runAfter: [scan]
      taskRef: { name: git-cli }

Notice the final task: it opens a commit against the config repository and never talks to the production API server. That single design choice is what makes the rest of this domain work.

GitOps Basics and Workflows

☺ Like you’re 10: Write down how the room should look, and let a robot inside the room keep fixing it until it matches. Forever.

GitOps is an operating model in which the entire desired state lives in a version-controlled repository and software agents continuously reconcile the running system toward it. The CNCF’s OpenGitOps project (opengitops.dev) distils it to four principles, and the exam expects all four by name.

The four OpenGitOps principles

Two more terms carry exam weight. Drift is any divergence between actual and desired state — someone runs kubectl scale, an operator mutates a field, a node failure leaves a resource missing. Reconciliation is the loop that closes the gap. Kubernetes controllers are level-triggered: rather than reacting once to an event and hoping, they repeatedly compare current level to target level and act — which is exactly why the model self-heals.

The workflow, end to end

Say this sequence out loud until it is automatic: developer opens a pull request → CI builds, tests, scans and publishes an immutable image → CI (or an image-automation controller) commits a tag bump to the config repo → reviewers approve and merge → the in-cluster agent detects the commit on its next poll or via webhook → it renders manifests, diffs desired against actual, and applies → status becomes Synced and Healthy. To roll back, revert the commit and let the same loop run.

Two switches turn that loop from advisory into enforcing. Self-heal reverts out-of-band changes back to what Git says. Prune deletes live resources whose manifests were removed from Git, so a deletion in Git is a real deletion. The canonical Argo CD object with both on:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: checkout-prod
  namespace: argocd
spec:
  project: payments
  source:
    repoURL: https://github.com/acme/platform-config.git
    targetRevision: main
    path: apps/checkout/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: checkout
  syncPolicy:
    automated:
      prune: true      # remove live resources deleted from Git
      selfHeal: true   # revert manual drift back to Git
    syncOptions:
      - CreateNamespace=true

Flux expresses the same idea as a toolkit of small controllers: a GitRepository source plus a Kustomization or HelmRelease that reconciles it, each carrying its own interval. For the exam: both are CNCF graduated projects, both implement all four principles, and the difference is shape — Argo CD is application-centric with a rich UI; Flux is a composable set of controllers with no official UI.

GitOps for Application Environments

☺ Like you’re 10: Dev, staging and prod are three posters describing three rooms — mostly the same, with a few numbers changed.

An application environment is a named, isolated place where a version of the app runs with its own configuration, data and traffic — dev, test, staging, production, and increasingly short-lived preview environments. In a GitOps platform an environment is not a special deployment mode; it is a path in a repository that an agent reconciles into a namespace or cluster.

Modelling environments: overlays, not copies

The dominant pattern is a shared base of manifests plus per-environment overlays that patch only what differs — replica counts, resource limits, hostnames, feature flags, image tag. Kustomize does this natively; Helm does the same with one chart and per-environment values files. The rule either way: duplicate as little as possible, and never fork the base.

platform-config/                      # the CONFIG repo the agent watches
├── apps/
│   └── checkout/
│       ├── base/                     # identical everywhere
│       │   ├── deployment.yaml
│       │   ├── service.yaml
│       │   └── kustomization.yaml
│       └── overlays/
│           ├── dev/                  # image: 2.7.0  replicas: 1  debug on
│           ├── staging/              # image: 2.6.4  replicas: 2
│           └── prod/                 # image: 2.6.3  replicas: 8  HPA + PDB
├── infrastructure/                   # cluster add-ons: ingress, cert-manager, mesh
└── tenants/                          # one folder per team, fanned out automatically

Read the three overlays as a release train: prod is one version behind staging, staging one behind dev. Promotion is making a lower environment’s tag appear in a higher environment’s overlay — a two-line diff, reviewable and revertible. Critically, promotion does not rebuild the artifact: build once, promote the same immutable image everywhere. Rebuilding per environment means the thing you tested is not the thing you shipped.

Repo strategies and how they compare

Fan-out makes this scale. Argo CD’s ApplicationSet generates one Application per item from a generator — per folder (Git), per registered cluster (cluster), per open PR (pull request), or per combination (matrix). Onboarding a team becomes “add a folder,” and preview-per-PR becomes a template rather than a script.

Releasing gradually: rolling, blue/green and canary

Getting a version into production is not the same as giving it all the users. Know three strategies by name. A rolling update (a Deployment’s default) replaces pods in batches governed by maxSurge and maxUnavailable. Blue/green stands up a complete second version alongside the first and flips traffic in one step — instant rollback, double the resources. A canary shifts a small slice of traffic (1%, 5%, 25%…) to the new version, checks metrics at each step, and either proceeds or aborts. Argo Rollouts and Flagger automate canaries with metric-based analysis, usually against Prometheus. Collectively: progressive delivery — releasing to a growing audience under automated supervision, with an automatic abort.

Incident Response in Platform Engineering

☺ Like you’re 10: When something breaks, first make it stop hurting. Understand why afterwards — and don’t blame the person who pressed the button.

Fast delivery and safe operations are the same subject: a platform that ships forty times a day must be able to un-ship in minutes. An incident is an unplanned disruption or degradation of a service — not simply “a bug,” and not defined by whose code caused it.

The lifecycle you must be able to sequence

Detect — an alert fires, ideally tied to a symptom users feel (an SLO burn rate, error ratio or latency percentile) rather than a machine-level cause. Triage — assess impact, assign a severity, page the right people. Coordinate — someone becomes incident commander, owning decisions and the timeline but not the keyboard; a communications lead updates stakeholders and the status page; experts investigate. Mitigate — restore service by the fastest safe means. Resolve — confirm recovery and stand down. Learn — write a blameless postmortem with a timeline, contributing factors and owned, dated action items.

The step people get wrong, in exams and in life, is the order of mitigate and diagnose. Restoring service comes first; root cause analysis is a postmortem activity, not an outage activity.

Rollback in a GitOps world

This is where the domain closes its own loop, and the most likely place for a question spanning two competencies. Because desired state is versioned, rollback is git revert: revert the commit that changed the tag, and the reconciler drives production back to the last known-good state through exactly the path every other change takes. Argo CD can also roll back to an earlier revision from its sync history (argocd app rollback), but note the trap — and note that Argo CD refuses that command outright while syncPolicy.automated is enabled, precisely because the controller would immediately sync forward again. If selfHeal is on and Git still holds the bad version, the agent re-applies the bad version. The fix must land in Git.

# mitigate first: put the last known-good desired state back
git revert --no-edit 4f9c1ab        # the commit that bumped checkout to 2.7.0
git push origin main                # agent reconciles prod back to 2.6.3

# observe the reconciler doing it
argocd app get checkout-prod        # SYNC STATUS / HEALTH STATUS
kubectl -n checkout rollout status deploy/checkout

# a canary that is failing analysis can be aborted immediately
kubectl argo rollouts abort checkout -n checkout

The platform team’s actual job during incidents

A platform team rarely owns the failing application, so its contribution is capability, not heroics: make rollback a single reviewed commit; make canaries abort themselves before a human notices; ship golden signals and structured logs by default so every team can answer “is it me or is it the platform?”; publish runbooks next to the alert that fires; and run the on-call and severity conventions that stop every incident being improvised. Then reduce incidents structurally — smaller batches, automated gates, progressive rollouts. As Reliability & Incidents covers, teams that deploy more frequently in small increments recover faster and fail less, because small changes are easy to reason about and easy to reverse.

Exam-day recall sheet for this domain

☺ Like you’re 10: The short list of sentences that answer most of the questions in this 16%.

• CI proves a change is safe and emits an immutable artifact. Continuous delivery keeps every green build releasable; continuous deployment releases it automatically.
• A pipeline is triggered, staged, fail-fast and hermetic, and its last act in a GitOps platform is a commit, not an apply.
• CI pushes, CD pulls. The pipeline holds no cluster credentials.
• The four OpenGitOps principles: declarative; versioned & immutable; pulled automatically; continuously reconciled.
• Drift is divergence from desired state; self-heal reverts it; prune deletes resources removed from Git.
• Argo CD and Flux are both CNCF graduated GitOps engines — application-centric with a UI, versus a composable controller toolkit.
• Environments are paths of desired state; promotion moves a tag between overlays. Build once, promote the same image.
• Rolling replaces in batches; blue/green flips all at once; canary shifts a slice and watches metrics. Together: progressive delivery.
• Incident order: detect → triage → coordinate → mitigate → resolve → learn. Mitigate before you diagnose; postmortems are blameless.
• In GitOps, rollback is a revert — and it must land in Git, or self-heal will undo your manual fix.

With this domain cold, continue from the CNPA hub to the neighbouring domains — start with Core Fundamentals, which restates continuous delivery and GitOps at 36% — then pressure-test yourself against the CNPA mock exam. Reach for the deeper CNPE pages (GitOps Workflows, CI/CD & Progressive Delivery, Release Engineering, Reliability & Incidents) whenever a one-line answer here leaves you wanting the machinery behind it, and keep the one-line versions warm with Know Cold and Flashcards.