Platform Engineering Core Fundamentals

This is the biggest domain on the CNPA exam — more than a third of every question you will see — and the most conceptual. It asks whether you understand what a platform is, why declarative beats imperative, what DevOps was actually trying to fix, how environments and infrastructure fit together, and where continuous integration ends and continuous delivery begins. CNPA is knowledge-based and multiple-choice, so your job here is not to build the thing — it is to state the thing crisply, and to spot the wrong answer when it is dressed up in plausible words.

How this domain is examined

☺ Like you’re 10: This is a written test, not a workshop. You have to explain the right answer, not build it.

The CNPA — Certified Cloud Native Platform Engineering Associate — is the associate-level, knowledge-based counterpart to the hands-on CNPE, and that single fact should reshape how you study. On a performance exam you practise until your fingers know the flags; here you practise until your vocabulary is precise, because most wrong answers are true statements attached to the wrong term. “Continuous deployment” and “continuous delivery” are not synonyms. “Portal” and “platform” are not synonyms. “Declarative” is not a synonym for “written in YAML.”

For context, the published curriculum splits the exam into six weighted domains: Platform Engineering Core Fundamentals 36% (this page), Platform Observability, Security, and Conformance 20%, Continuous Delivery & Platform Engineering 16%, Platform APIs and Provisioning Infrastructure 12%, IDPs and Developer Experience 8%, and Measuring your Platform 8%. Those six add up to 100% across 27 competencies — and seven of the twenty-seven live on this page, which is why one domain carries more than a third of the weight.

The seven competencies at a glance

The official curriculum lists exactly seven competencies for this domain. Here they are, with the one-sentence answer you should be able to produce on demand and where to go deeper:

What “know it” means on a knowledge exam

Associate exams reward definitions, distinctions and ordering: which description matches a term, which principle a scenario violates, what comes next in a sequence. Very little hinges on a command-line flag. When you revise, write the one-line definition from memory before checking — recognition feels like knowledge and isn’t.

On logistics, taking the Linux Foundation’s own CNPA listing as the source: the exam is delivered online with remote proctoring as a multiple-choice paper, is listed at 120 minutes, is priced at US$250 for the exam alone (a training bundle costs more), includes one retake, has no prerequisites, gives you a 12-month eligibility window to sit it, and certifies you for two years. The passing score is published — the Linux Foundation’s Multiple Choice Exam FAQ requires 75% or above, and gives the CNPA 120 minutes as its one named exception to the 90 that other multiple-choice exams get. What is genuinely not published is the exact question count — treat any number you see for that as folklore, and confirm everything else — prices and formats are revised — on the official Linux Foundation CNPA page before you register. Our certifications overview tracks how CNPA sits alongside KCNA, CKA and the rest, and the CNPA mock exam rehearses the format under time.

Declarative Resource Management

☺ Like you’re 10: Instead of listing every step to tidy your room, you show a photo of the tidy room and let a helper work it out — again and again, forever.

This competency comes first because it is the model everything else in cloud native is built on. Imperative management means issuing instructions — create this, then scale that. Each command is a verb, it happens once, and afterwards nothing remembers why. Declarative management means submitting a description of the end state — a noun, not a verb — and letting a controller work out the steps, repeatedly, for as long as the object exists.

Imperative vs declarative — the fork in the road

The exam’s favourite trap is to equate “declarative” with “YAML.” It isn’t the file format — a script full of kubectl create commands is imperative wherever you store it. What makes something declarative is that the artifact expresses a target state which something else is responsible for achieving and maintaining.

# Imperative — a sequence of verbs. Works once; leaves no reviewable record.
kubectl create deployment web --image=nginx:1.27
kubectl scale deployment web --replicas=3
kubectl set image deployment/web nginx=nginx:1.28

# Declarative — one noun, applied. Re-runnable, reviewable, diffable.
kubectl apply -f web.yaml
kubectl diff  -f web.yaml      # "what would change if I applied this?"

Desired state, actual state, and the reconciliation loop

Two phrases carry this competency. Desired state is what you declared; actual state is what is really running. A controller runs a loop — observe, diff, act — that shrinks the gap between them, forever. Kubernetes calls this the reconciliation loop, and it is level-triggered: it does not react to a one-off event and hope, it repeatedly compares current level to target. That is why the system is self-healing — kill a pod and the controller notices the level is wrong and makes another. Nobody was paged.

Reading a Kubernetes object: spec vs status

Every Kubernetes resource has the same top-level fields, and knowing which you write versus which the controller writes is a classic associate-level question. You write spec — desired state. The controller writes status — observed actual state. You never hand-edit status; you read it.

apiVersion: apps/v1          # which API group & version owns this object
kind: Deployment             # what kind of object it is
metadata:
  name: web                  # identity: name, namespace, labels, annotations
  labels: { app: web }
spec:                        # DESIRED state — written by you
  replicas: 3
  selector:
    matchLabels: { app: web }
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: nginx
          image: nginx:1.28  # pin a version — never :latest in a declared state
          resources:
            requests: { cpu: 100m, memory: 128Mi }
            limits:   { memory: 256Mi }
# status:                    # ACTUAL state — written by the controller, read by you
#   replicas: 3
#   readyReplicas: 3
#   observedGeneration: 7

Extending that idea to things Kubernetes has never heard of — databases, DNS records, whole clusters — is the Custom Resource and operator pattern, the subject of the Platform APIs domain.

DevOps Practices in Platform Engineering

☺ Like you’re 10: The people who build a thing and the people who look after it used to shout over a wall. DevOps knocked the wall down; platform engineering paves a road where the wall was.

DevOps began as a cultural answer to a structural problem: developers were measured on change and operators on stability, so they were paid to fight. The practices that emerged — shared ownership, automation, small frequent changes, fast feedback, blameless learning — are the bedrock CNPA assumes you accept. Platform engineering is what happened next, when “you build it, you run it” handed every product team an unmanageable pile of infrastructure decisions.

Shift left, then shift down

“Shift left” means moving concerns — testing, security, cost awareness — earlier, toward the developer. It works brilliantly until developers drown in the number of things that have shifted onto them. Shift down is the correction: rather than push a responsibility further left onto a person, move it down into the platform, where it is solved once and inherited by everyone. Encryption in transit, image scanning and audit logging should be properties of the road, not seven teams’ homework.

Automation, feedback loops, and small batches

Three practices recur. Automate the repeatable — anything a human does twice is a candidate for a pipeline or a controller. Shorten the feedback loop — a failing test at 30 seconds costs almost nothing; the same defect found by a customer costs a thousand times more. Ship small batches — small changes are easier to review, roll back and diagnose, which is why change failure rate goes down as deployment frequency goes up, a counter-intuitive finding Measuring your Platform will make you defend.

Blameless culture and shared ownership

The platform team does not take operations back. Product teams still own their services in production; the platform makes that ownership survivable with paved defaults, dashboards and runbooks. When something breaks the question is never “who did this” but “what made this easy to do and hard to notice.” See Team Topologies for who owns what.

Application Environments and Infrastructure Concepts

☺ Like you’re 10: Dev, staging and prod are a rehearsal room, a dress rehearsal and opening night — same play, different stakes, and you want them as alike as possible.

An environment is a named, reproducible place where a particular version of an application runs, with its own configuration, data and access rules. The classic set is development, staging and production, and the golden rule is parity: the closer staging resembles production, the more your rehearsal is worth. Divergence is where “it worked in staging” incidents are born.

What actually differs between environments

The artifact should not differ at all — build the image once and promote that exact image. What differs is configuration (endpoints, feature flags, replica counts, log levels), secrets (different credentials per environment, never plaintext in Git), scale and data. Separating code from configuration is a twelve-factor idea and the reason Kustomize overlays and Helm values exist.

The isolation ladder — namespace, cluster, account

Every rung up buys stronger isolation and costs money and effort. The exam-ready statement: namespaces are a soft boundary, clusters are a hard one — namespaces alone are not a security boundary between mutually distrusting tenants. Multi-cluster goes deeper.

Ephemeral and preview environments

Because environments are declared, they can be created on demand and thrown away. A preview environment is spun up per pull request, tested against, and destroyed on merge — the pattern Argo CD’s ApplicationSet pull request generator exists to serve. It kills the queue for the shared staging box, but only works if provisioning is fully declarative and automated. If creating an environment needs a ticket, it will never be ephemeral.

Immutable infrastructure — cattle, not pets

Finally, immutability: you never patch a running instance, you replace it with a new one built from a new artifact. Containers make this natural — an image is immutable, identified by a digest, and a “change” is a new image plus a rolling replacement. Pets are hand-tuned servers with names that you nurse back to health; cattle are identical, numbered and replaced without ceremony.

Platform Architecture and Capabilities

☺ Like you’re 10: A platform is not a shopping list of tools. It’s a set of jobs the platform does for you — and tools are just who happens to be doing each job today.

The CNCF’s Platforms White Paper, from TAG App Delivery, defines a platform for cloud native computing as an integrated collection of capabilities, defined and presented according to the needs of the platform’s users. Both halves are examinable: integrated rules out a wiki page listing twelve unrelated tools, and according to the needs of its users rules out a platform designed for the platform team’s convenience.

Capabilities, not tools

A capability is a job the platform performs: “provision a database,” “deliver a change safely,” “tell me why my service is slow.” Tools are interchangeable implementations. Argo CD and Flux both provide the delivery capability; Prometheus and a hosted vendor both provide metrics. Thinking in capabilities lets you swap a tool without redesigning the platform, and is why the reference architecture is drawn as slots rather than logos.

The five planes

The community draws those capabilities as five planes. Three form a flow from intent to running software; two are cross-cutting, because you cannot bolt them onto one layer and skip the rest. (Names vary: the white paper’s own figure labels the cross-cutting bottom band the monitoring and logging plane, where most people now say observability plane. Same plane, and either wording is safe.)

Control plane vs data plane

One more distinction the exam likes. A control plane decides and instructs; a data plane carries the actual work. In Kubernetes the API server, scheduler, etcd and controller-manager are the control plane; kubelets and running pods are the data plane. In a service mesh, the mesh control plane configures the sidecar proxies, and the proxies moving your bytes are the data plane. Why it matters: a control plane can often fail without stopping traffic, whereas a data-plane failure is an outage immediately.

Platform Engineering Goals, Objectives, and Approaches

☺ Like you’re 10: The point of the art room is that more good posters get made. If people stop coming, the room is failing — however tidy the paint is.

Ask “why does this platform exist?” and the honest answer must be about its users. The goal is to reduce cognitive load on product teams so they can spend attention on the domain problem, and to increase flow — the rate at which valuable change reaches users safely. Every other claimed benefit is downstream of those two.

Cognitive load and the paved road

A developer has only so much head-space. Intrinsic load is the domain problem you were hired to solve; extraneous load is everything else the environment makes you learn — the Terraform module, the ingress annotation, the certificate rotation. Platform engineering is the deliberate transfer of extraneous load from many teams to one. A golden path is the opinionated, supported, well-lit route through the platform: take it and you get CI, observability, security and deployment for free. Crucially it is a path, not a wall — teams may leave it, they just carry the load themselves.

Platform as a product

The most examinable approach is product thinking: the platform has users, they are internal developers, and adoption is voluntary. That implies a roadmap, user research, documentation, versioning and support — and gives you the sharpest success metric there is, adoption you did not have to mandate. Start with the thinnest viable platform: the smallest thing that removes real pain, sometimes a good README and one automated path rather than a portal. See Platform as a Product and Developer Experience.

Approaches: build, buy, assemble

Almost nobody builds a platform from scratch and nobody buys one whole. The dominant approach is assemble: compose CNCF projects and managed services behind a consistent interface, writing only the glue specific to your organisation. Evolve iteratively — the CNCF Platform Engineering Maturity Model describes movement from provisional and operational through scalable to optimising — and resist the two failure modes: the platform nobody asked for, and the platform that is really a ticket queue with a nicer form. Anti-patterns catalogues the rest.

Continuous Integration Fundamentals

☺ Like you’re 10: Everyone puts their homework into the same folder every day, and a robot checks straight away that it all still fits together.

Continuous integration is the practice of every developer merging work into a shared main branch frequently — at least daily — with each merge automatically built and verified. Say that out loud, because the distractors will offer “a tool that builds containers” or “running tests before release,” and neither is CI. CI is a team behaviour about merge frequency; the server only makes the behaviour cheap.

Trunk-based development and why branches rot

Long-lived feature branches are the enemy CI was invented to kill: the longer a branch lives, the further it drifts from trunk and the more painful the eventual merge. Trunk-based development keeps branches short-lived and hides unfinished work behind feature flags rather than behind branches — which is also what makes continuous delivery possible, because trunk is always releasable.

The stages of a pipeline

A CI pipeline is an ordered set of stages, arranged so the fastest and most likely to fail run first — don’t spend four minutes building an image whose linting was already broken.

# A CI pipeline is just ordered stages with the cheapest feedback first.
stages:
  - lint            # seconds — style, schema, manifest validity
  - unit-test       # ~1 min  — pure logic, no network, no cluster
  - build           # build ONCE; tag with the commit SHA
  - scan            # dependency + image CVE scan, generate an SBOM
  - sign            # cosign signature — provenance for the supply chain
  - integration     # ephemeral environment, real dependencies
  - publish         # push image + SBOM + signature to the registry
  - promote         # open a PR that bumps the tag in the config repo

Notice the last stage: in a GitOps world the pipeline’s job ends at a commit — it never touches the cluster.

Build once, promote the same artifact

The rule that ties CI to environments: build the artifact exactly once and promote that identical, immutable image through dev, staging and production, changing only configuration. Rebuilding per environment means the thing you tested is provably not the thing you shipped. With signing and an SBOM, build-once gives you a supply chain you can reason about — which Observability, Security & Conformance will press you on.

Continuous Delivery and GitOps

☺ Like you’re 10: Continuous delivery means the cake is always ready to serve. Continuous deployment means it gets served automatically. GitOps is the recipe book the kitchen keeps checking itself against.

Here is the set the exam will absolutely test, so learn it as a set rather than as separate facts:

Both continuous delivery and continuous deployment can be implemented with GitOps — GitOps is the mechanism, not the policy. Whether a merge to the production overlay needs an approving review is where delivery ends and deployment begins.

The four OpenGitOps principles

The CNCF OpenGitOps project reduces GitOps to four principles you should be able to recite: desired state is declarative; it is stored versioned and immutable with a complete history; software agents pull it automatically; and those agents continuously reconcile actual state toward desired state. Half-measures fail the last two — “we run kubectl apply from a CI job on every merge” is declarative and versioned, but pushed, and it reconciles only at merge time. That is CI-driven deployment, not GitOps.

Push versus pull, and why pull is safer

In a push model an external system reaches into the cluster, so CI must hold powerful cluster credentials. In a pull model an agent inside the cluster reaches out to Git, so those credentials never leave the cluster and a compromised pipeline has a far smaller blast radius. Two switches turn the agent from advisory into enforcing: self-heal reverts out-of-band drift back to what Git says, and prune deletes live resources whose manifests were removed from Git.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: checkout
  namespace: argocd
spec:
  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       # a deletion in Git becomes a real deletion
      selfHeal: true    # a hand-edit in the cluster is reverted

CNPA will only ask you to recognise that shape — which agent pulls, what prune and selfHeal mean — but it sticks far better once you have run it: the Argo CD page takes the object apart field by field, and the GitOps lab makes you break and repair a live sync.

Deploy is not release

The last idea, and the bridge into Continuous Delivery & Platform Engineering: deploying code and releasing it to users are separable events. Progressive delivery exploits that gap — a canary sends a slice of traffic to the new version and watches the metrics before widening; blue/green runs two stacks and flips traffic in one move; feature flags release to a cohort with no deploy at all. All three make the cost of a bad change small enough that shipping often is the safe option.

That is 36% of the exam in one lesson. Next, what the platform must see and enforce — Platform Observability, Security, and Conformance — and the CNPA hub keeps the running map of all six domains.