Practice · Core Fundamentals

Twenty-four multiple-choice questions on the single biggest thing on the CNPA blueprint: Platform Engineering Core Fundamentals, worth 36% of the paper — more than a third of your score from one domain, and the conceptual one. This is a practice bank, not a mock: no timer, no weighting across six domains, no pretence of simulating a sitting. It drills one domain until the distinctions inside it are automatic — what a platform is and is not, capabilities versus tools, golden paths versus mandates, declarative versus imperative, reconciliation loops, Kubernetes as substrate, maturity, tenancy, and why a leaky abstraction is a design event rather than an inconvenience. Answer cold; every question tells you why the right answer is right and why the tempting wrong one is wrong.

What this domain rewards

☺ Like you’re 10: This part of the test isn’t about tools. It’s about knowing what things are, so you can tell two lookalikes apart.

Core Fundamentals is the domain candidates most often assume they already know, and it is the domain that most often decides the result. It is 36% of the paper — a bigger share than Platform APIs (12%), IDPs & DevEx (8%) and Measuring (8%) put together. And because it is the conceptual domain, you cannot revise it the way you revise a tool: there are no flags to memorise, only distinctions to sharpen.

Thirty-six percent, and what sits inside it

The official curriculum lists seven competencies under this domain: Declarative Resource Management, DevOps Practices in Platform Engineering, Application Environments and Infrastructure Concepts, Platform Architecture and Capabilities, Platform Engineering Goals, Objectives, and Approaches, Continuous Integration Fundamentals, and Continuous Delivery and GitOps. This bank leans deliberately on the first five, because CI and GitOps get their own drilling in the Continuous Delivery domain and in the site’s deeper GitOps lesson — but the concepts underneath them, especially declarative intent and reconciliation, are examined here too, so they are here as well.

Knowledge-based, which changes how you practise

The CNPA is a knowledge-based, multiple-choice associate exam across six weighted domains — 36 / 20 / 16 / 12 / 8 / 8. That is not the same animal as the professional CNPE, which is performance-based: roughly 15–20 hands-on tasks in 120 minutes, with 64% to pass, graded on the cluster state you leave behind. On a performance exam you drill until your fingers know it. On a knowledge exam you drill until your sentences know it — which is exactly what a bank of tight, distinction-shaped questions is for.

How to work this bank

☺ Like you’re 10: Answer first, look it up after. Being wrong now is cheap; being wrong in the exam is not.

A bank is used differently from a mock exam. The mock is a measurement — one cold pass, no notes, the whole blueprint in proportion. A bank is a tool: you come back to it, you re-sit one chip at a time, and you use the explanations as the lesson. Working it properly takes about forty-eight minutes the first time — twenty-four questions at two minutes each, which is the CNPA rhythm the rest of this site drills at — and five minutes on every visit afterwards.

The protocol

1. First pass: leave the chips on “All 24” and go straight through. Commit to an answer even when you are guessing — a guess you got right for the wrong reason is worth finding now.
2. Read every explanation, including the ones you got right. Half the value here is the sentence explaining why the other option was attractive; that sentence is the actual exam skill.
3. Write down the sub-topic of every miss, not the question. Six chips, six possible diagnoses. Three misses in one chip is a reading assignment; one miss in each of three chips is just noise.
4. Go and read, then re-sit that chip alone. The last section on this page maps every chip to the lesson that fixes it.
5. Use Shuffle / reset — question order and answer options are reshuffled every time, so you cannot pass by remembering which one was third.

What the chips are for

Every question here belongs to the same exam domain, so the chips split it by sub-topic instead: Platform & Capabilities, Product & Golden Paths, Cognitive Load & Teams, Declarative & Reconciliation, Kubernetes & the Landscape, and Maturity & Tenancy. That is a revision aid, not an official sub-structure — the CNCF publishes seven competencies, not six chips. But when you drop four marks it is far more useful to know that they were all about abstraction and product thinking than to know they were all “Core Fundamentals.”

The bank — twenty-four questions

☺ Like you’re 10: Pick an answer. It goes green or red straight away and tells you why.

Click an option to lock it in: the correct answer is marked, your mistake is marked, and the explanation appears underneath. The counter and bar track how far through you are and how many you have right; the chips filter by sub-topic, and Shuffle / reset starts a fresh attempt with everything reshuffled. Your attempt count and best score per chip are remembered in this browser only — nothing leaves your machine.

What the examiners are really testing here

☺ Like you’re 10: They almost never ask “what does this word mean.” They ask “which of these two nearly-identical things is the real one.”

If you look back at what you just answered, almost nothing was recall. That is not an accident of how this bank was written — it reflects what a well-built associate paper does with a conceptual domain. There are only so many ways to ask “define a golden path,” and the definition is one sentence long. So the questions move instead to the edges of the concept, where a half-understanding falls over.

Distinctions, not definitions

The reliable shape is a pair of ideas that share vocabulary and differ in substance: a capability and a tool, a path and a fence, a portal and a platform, a manifest and a script, project maturity and platform maturity, a namespace and a boundary. You can hold a fluent-sounding conversation about platform engineering while confusing every one of those pairs — which is precisely why they are examinable. The test for yourself is brutal and simple: say the difference in one sentence, without the word “basically.”

Judgement inside a scenario

The second shape hands you a situation and asks what it indicates, or what you should do next. Nine of eleven teams have not adopted the platform. Every team employs someone maintaining pipeline YAML. Someone resized the database in the console. These reward the same knowledge as a definition question, but they punish the candidate who memorised words without ever asking what the words are for. Read the stem for the actor and the consequence: who is affected, and what does the situation cost them?

The three traps this bank sets on purpose

The reasonable-sounding governance answer. Approve the release, mandate the migration, restrict who may request it. These read as responsible engineering and are, almost always, a queue being reintroduced where self-service belonged.

The sophisticated non-answer. “All abstractions leak.” “It depends on your context.” True enough to feel wise, empty enough to be wrong, because the examinable question is what a platform team does about it.

The adjacent true fact. An option that states something entirely correct which does not answer the question asked — cost per engineer really does matter; requests equal to limits really does give you Guaranteed QoS. Neither is the reason in the stem. When two options both look true, re-read the question, not the options.

The distinctions this bank keeps returning to

☺ Like you’re 10: Here are the lookalike pairs, side by side, so you stop mixing them up.

Everything above collapses into one table. If you can produce the right-hand column from memory, this domain is done.

Seeing it at the keyboard

☺ Like you’re 10: The exam doesn’t make you type anything — but typing it once makes the words stop being words.

The CNPA never puts you at a terminal. Twenty minutes on a throwaway cluster is still the fastest way to make three of the distinctions above permanent, because you get to watch them rather than agree with them. Everything below runs against kind or minikube.

Imperative and declarative, side by side

These two blocks reach the same end state. The difference is entirely in what survives afterwards.

Imperative — the intent exists only in your shell history
kubectl create deployment web --image=nginx:1.27
kubectl scale deployment/web --replicas=3
kubectl set image deployment/web nginx=nginx:1.27.1

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.27.1
          ports:
            - containerPort: 80

Declarative — the intent exists in a file you can review, diff and revert
kubectl apply -f web.yaml
kubectl diff -f web.yaml
kubectl apply -f web.yaml --dry-run=server

Notice what kubectl diff implies: there is a target to compare against. No equivalent question can be asked of the imperative block, because it never recorded a target — only a journey. That is the whole distinction, and it is why storing that first block in Git changes nothing about which category it belongs to.

Watching desired state win

Create drift by hand and then re-assert the file. In a plain cluster you are the reconciler; wire the same manifest to Argo CD or Flux with self-heal and Recon does it for you, on a loop, forever.

kubectl scale deployment/web --replicas=7
kubectl get deployment web -o jsonpath='{.spec.replicas}{"\n"}'
kubectl apply -f web.yaml
kubectl get deployment web -o jsonpath='{.spec.replicas}{"\n"}'

Seven, then three. Nothing about the second apply knew that a human had scaled the deployment, and it did not need to — it computed the gap between the file and reality and closed it. Run it a third and fourth time and nothing further happens, which is idempotency you can see rather than recite.

spec, status, and the shape of a leak

Ask the object what it thinks about itself. spec is what you asked for; status is what the controller observed and is willing to say publicly.

kubectl explain deployment.spec.replicas
kubectl explain deployment.status.conditions
kubectl get deployment web -o jsonpath='{range .status.conditions[*]}{.type}={.status} {.reason}{"\n"}{end}'

Those conditions — Available, Progressing and their reasons — are the built-in controller doing what a good platform abstraction must do: reporting its own health in its own vocabulary. Now compare that with what a leak looks like. Make a pod unschedulable and read the events:

kubectl patch deployment web --type=merge -p '{"spec":{"template":{"spec":{"nodeSelector":{"disktype":"nvme"}}}}}'
kubectl get pods -l app=web
kubectl get events --field-selector reason=FailedScheduling --sort-by=.lastTimestamp

The failure message is written in the substrate’s language — nodes, selectors, taints. That is fine here, because you asked Kubernetes a Kubernetes question. It stops being fine the moment a platform offers a developer a Service resource and then hands them that message when it fails. The abstraction did not break; it simply declined to translate, and the developer now has to learn the layer you promised to hide. Undo it with kubectl apply -f web.yaml and the deployment converges again.

If you missed these, read this

☺ Like you’re 10: Find the chip you dropped marks in, read the page next to it, then do that chip again.

Nothing in this bank is examined that is not taught somewhere on this site. Take your misses one chip at a time — the middle column is the shortest path back to the mark, and the right-hand column is where the idea is explained properly rather than quickly.

Where to go from here

☺ Like you’re 10: One domain is done. Do the other five, then take the whole test in one go.

This bank is one domain of six. Work the rest the same way — a chip at a time, explanations read even when you were right — and only then sit a full paper, because a mock is a measurement and measurements are wasted on material you have not revised yet.