CNPA Mock Exam · Set 2

A second complete sixty-question CNPA paper, weighted question-for-question to the six domains of the official CNPA curriculum — twenty-two on Core Fundamentals, twelve on observability, security and conformance, ten on continuous delivery, seven on platform APIs, five on IDPs and developer experience, four on measuring. Roughly half of this paper is material you will not have met on Set 1, Set 3, Set 4 or the practice banks; the rest deliberately revisits the same core propositions in different words. That overlap is designed, not accidental, and it is concentrated exactly where the blueprint is heaviest — Core Fundamentals alone is 36% of the exam, so twenty-two of these sixty questions come from one associate-level topic, and there are not four papers’ worth of genuinely distinct propositions in “what a platform is, declarative versus imperative, golden paths, reconciliation”. So treat the four sets as four sittings, not four disjoint question pools. Meeting an idea you have already answered is spaced retrieval practice, and it is a signal rather than a defect: if the answer arrives instantly, that knowledge has consolidated; if you hesitate, it was never as solid as your first score suggested. This set also has its own character: almost every question is a scenario — a team reports a symptom, a dashboard shows something odd, an audit turns up an awkward fact — and your job is to say what that tells you. That is much closer to how the CNPA phrases its harder questions than a straight definition ever is.

How to sit this paper

☺ Like you’re 10: Set a timer, shut every other tab, and answer all sixty without looking anything up — even the ones you are guessing.

A mock exam is only worth the discipline you bring to it. Look things up mid-paper and you have measured your search skills, not your recall; the CNPA is closed-book, so a tab you cannot open in the exam should not be open here either. Sit it as one uninterrupted block, decide on every question, and resist the urge to go back and change answers on a hunch. Nothing published suggests Linux Foundation multiple-choice exams penalise a wrong answer more than a blank one — treat that as an assumption to confirm on the official page rather than a fact you got here — but the advice survives either way: never leave a question unanswered. Eliminate the two options that are clearly wrong, then choose between what is left.

The protocol

1. Set a clock for 120 minutes. That is the published CNPA allowance: the Linux Foundation’s Multiple Choice Exam FAQ gives multiple-choice candidates 90 minutes and names CNPA as the one exception, at 120. The same FAQ states no question count — the sixty questions here are ours, a study convention — but spread 120 published minutes across them and you get two minutes a question — comfortable for a definition, about right for a scenario, and enough slack to flag three or four and come back to them. Drilling at 90 would train you to a pace a third faster than the one you will actually sit at.
2. Leave the domain chips on “All” for the first sitting. Filtering is a revision tool; using it during a mock turns the paper into six small quizzes and flatters your score.
3. Answer, then read the explanation — including when you were right. Every explanation in this set names the most tempting wrong answer as well as the right one, and in a scenario paper the near-miss is where the learning is.
4. Write down the topic of anything that surprised you, not the question. Questions do not repeat between exams; topics do.
5. Do not immediately re-sit. Read your two weakest domain pages first. A second pass an hour later measures short-term memory and nothing else.
6. Then re-sit by chip, with Shuffle / reset. Both the question order and the four options are reshuffled every time, so “it was the second one” is not a strategy that survives here.

What is different about Set 2

Set 1 leans on definitions and distinctions: what declarative means, who writes status, which four things are the DORA metrics. Set 2 assumes you have those and asks you to apply them under a symptom. You will be told that a manifest says three replicas while the cluster runs seven, that traces stop dead at a service boundary, that a node drain has hung on one Deployment — and asked what that means. The knowledge tested is identical and the blueprint weighting is identical; only the framing has moved. If Set 2 is noticeably harder for you than Set 1, that is a useful finding in itself: it usually means the vocabulary is memorised but not yet wired to anything.

What this paper deliberately is not

It is not a leaked, reconstructed or officially sanctioned exam, and the wording is ours rather than the CNCF’s. Three honest caveats. First, the duration here matches the published CNPA allowance of 120 minutes, but the real exam’s question count is set by the Linux Foundation and may not be the sixty used here — so the two minutes a question this paper gives you is an approximation of the real pace, not a promise of it. Second, a mock can only test what fits into four options — the CNPA also rewards being able to explain an idea in a sentence, which is why the blank-sheet drill on the CNPA hub belongs in your plan next to this paper. Third, multiple choice is the right shape of practice only because the CNPA is knowledge-based. It sits in the associate, knowledge-based tier next to KCNA, KCSA and CGOA. The performance-based exams — CKA, CKAD, CKS and the CNPE — drop you into a live terminal and grade the resulting cluster state, and no quantity of multiple choice prepares you for that. For those, the practice that counts is the lab track, the practice-task bank and a timed sitting of CNPE Mock Exam Set 1.

Reading a scenario question

☺ Like you’re 10: In a story question, two answers usually sound right. The trick is to spot which one only describes the problem and which one actually explains it.

Scenario questions fail candidates who know the material perfectly well, because they are answered under a different instinct. A definition question rewards recognition; a scenario question rewards elimination. The general technique lives on the practice-questions page; what follows is the short version, tuned to this paper.

Four moves, in order

1. Name the domain before you read the options. “Traces stop at a boundary” is observability; “nobody has migrated to the golden path” is goals and approaches. Naming it narrows the answer space before the distractors get a chance to work on you.
2. Say the answer in your own words first. Then look for it. Reading the four options cold lets the best-written one win rather than the correct one.
3. Delete the two that are true but irrelevant. Scenario distractors are rarely false. They are usually accurate statements that answer a question you were not asked.
4. Between the final two, ask which one explains the symptom. One of them almost always restates it. “The tests are wrong” restates a failure; “configuration differs between environments” explains one.

The three traps this set uses on purpose

The plausible mechanism. An option names a real thing that really does something — an SBOM, an HPA, a NetworkPolicy — but not the thing in the scenario. You beat it by asking what that mechanism actually enforces, and at which point.

The tempting escalation. Adoption is low, so mandate it. Alerts are noisy, so raise the threshold. Policy blocks a deploy, so relax the policy. These options all restore order and all make the underlying problem worse — and they show up repeatedly in this paper because they show up repeatedly in real platform teams.

The half-truth. “Git makes it declarative.” “mTLS means the traffic is authorised.” “Synced means healthy.” Each is one careful word away from correct, and each is the exact distinction a domain page spends a section on.

How the sixty questions are weighted

☺ Like you’re 10: The questions are shared out the way the real exam shares out its marks — the biggest topic gets the most questions.

The six published weights — 36, 20, 16, 12, 8 and 8 — sum to exactly 100%, and each domain’s share of this paper tracks its weight as closely as sixty whole questions allow. Applied to sixty questions the raw shares are 21.6, 12.0, 9.6, 7.2, 4.8 and 4.8, and only one of those is a whole number — so five of the six have to be rounded, and the rounding has to leave the paper at exactly sixty. Core Fundamentals (21.6) and Continuous Delivery (9.6) round up to 22 and 10; Platform APIs (7.2) rounds down to 7. That leaves the two 8% domains tied at 4.8 apiece: rounding both up would give 61 questions and both down would give 59, so the tie is broken by hand — IDPs & DevEx takes 5 and Measuring takes 4. There is nothing principled in which one won; it is the arithmetic of hitting sixty. The result, 22 · 12 · 10 · 7 · 5 · 4, is the same split all four papers use, deliberately, so the scores are directly comparable.

Two domains — Core Fundamentals and observability/security — are 56% of the paper between them, so the shape of your result matters more than the total. A 75% assembled from “strong everywhere except Core Fundamentals” is a far more dangerous outcome than the same 75% built from “solid everywhere, thin on Measuring,” because one domain carries four and a half times the weight of the other. Fix in weight order, not in the order you happened to notice the mistakes.

The paper — sixty questions

☺ Like you’re 10: Pick an answer. It goes green or red straight away and tells you why — including why the answer you were tempted by is wrong.

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 at the top track progress and score; the chips filter by domain; Shuffle / reset reshuffles the questions and the options and starts a fresh attempt. Your best score on this device is remembered in this browser’s local storage under lpe.cnpa.mock2.v1 and never leaves the machine — a private window or a different laptop starts you clean, which makes for an honest re-test.

Marking yourself against the associate bar

☺ Like you’re 10: Your score is a thermometer, not a verdict. The list of things you got wrong is the actual result.

Score yourself twice: once overall, and once per domain using the chips. For the overall number, the bar is published: the Linux Foundation’s Multiple Choice Exam FAQ states that a score of 75% or above is required to pass, and the CNPA is a multiple-choice exam. On a sixty-question paper that is forty-five right. What is not calibrated is this paper’s difficulty — our wording is not the CNCF’s and our questions are not theirs — so 75% here is not the same event as 75% there. Treat the bands below as a pattern, aim well clear of the line, and re-check the official figure before you book, because these things do change.

Reading the two sets together

If you have already sat Set 1, the gap between the two scores is more informative than either number. Scoring well on Set 1 and poorly here usually means recall without application — you can define the terms but cannot yet use them on a symptom, which is the failure mode that costs marks on the real paper. The reverse, doing better here, usually means good engineering instincts with thin vocabulary: you reasoned your way to the right answer without being certain of the term, and a question phrased as a bare definition will catch you. Both are fixable in a few evenings, but the fixes are opposite — the first needs scenarios, the second needs flashcards and the glossary.

What to do with your wrong answers

☺ Like you’re 10: For each one you missed, write down why your answer was wrong — not why the right one was right.

This is the single highest-value twenty minutes in the whole exercise, and almost nobody does it. Reading the correct answer produces recognition; writing down why your answer failed produces the discrimination that survives to exam day. Do it question by question, in one sentence each, and you will find the same three or four confusions behind a dozen mistakes.

The wrong-answer log

Group the log by domain when you are done. Three entries in one domain is a revision session; three entries spread across six domains is just a normal day, and you should book the exam.

Turning a wrong answer into twenty minutes of hands-on

☺ Like you’re 10: The CNPA does not make you touch a cluster — but touching one for twenty minutes makes the ideas stick for good.

The CNPA is knowledge-based, so none of this is required. It is, however, the fastest way to convert a concept you keep getting wrong into one you cannot get wrong, and every command below runs against a throwaway local cluster — kind or minikube, set up in the lab track — in a few minutes. Do the one that matches your worst domain.

If you missed the declarative questions

Apply the same manifest twice and watch the second apply do nothing. That is idempotence, and it is the property the whole model rests on.

kubectl create deployment web --image=nginx:1.27 --replicas=2 --dry-run=client -o yaml > web.yaml
kubectl apply -f web.yaml
kubectl apply -f web.yaml
kubectl scale deployment/web --replicas=5
kubectl diff -f web.yaml
kubectl apply -f web.yaml
kubectl get deployment web -o jsonpath='{.spec.replicas}{"\n"}'

The second apply reports unchanged. The scale creates drift, kubectl diff shows it as a diff against your file, and the next apply erases it — which is exactly what a GitOps reconciler does for you, continuously, without anyone typing.

If you missed the spec-versus-status questions

Read the API instead of reading about it. kubectl explain is served from the same schema the API server validates against.

kubectl explain deployment.spec.replicas
kubectl explain deployment.status
kubectl get deployment web -o jsonpath='{.status.conditions}' | tr ',' '\n'
kubectl get events --sort-by=.lastTimestamp | tail -20

Notice that nothing you wrote appears under status, and that the conditions are machine-readable — which is why kubectl wait, dashboards and other controllers can all consume them.

If you missed anything about network or identity controls

Apply a default-deny policy, watch DNS break, then fix it with the companion rule. Ten minutes here is worth an hour of reading. This needs a CNI that actually enforces policy — Cilium or Calico will do; the default kind networking will not.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: demo
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: demo
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

kubectl create namespace demo
kubectl -n demo run probe --image=nicolaka/netshoot --restart=Never -- sleep 3600
kubectl apply -f default-deny.yaml
kubectl -n demo exec probe -- nslookup kubernetes.default
kubectl apply -f allow-dns.yaml
kubectl -n demo exec probe -- nslookup kubernetes.default

The first nslookup hangs and fails; the second succeeds. That failure is the single most common self-inflicted outage on a newly hardened namespace, and having caused it once you will never mis-answer a question about it.

If you missed the CRD questions

Create a custom resource kind with no controller behind it, and watch the object sit there being perfectly valid and completely inert.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: widgets.platform.example.com
spec:
  group: platform.example.com
  scope: Namespaced
  names:
    plural: widgets
    singular: widget
    kind: Widget
  versions:
    - name: v1alpha1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              required: ["size"]
              properties:
                size:
                  type: string
                  enum: ["small", "medium", "large"]

kubectl apply -f widget-crd.yaml
kubectl explain widget.spec.size
kubectl create -f - <<'EOF'
apiVersion: platform.example.com/v1alpha1
kind: Widget
metadata:
  name: demo
  namespace: default
spec:
  size: enormous
EOF

The last command is rejected by the API server before anything is stored, because enormous is not in the enum — that is the OpenAPI schema doing validation you never had to write. Change it to large and the object is accepted, stored, RBAC-controlled, watchable, and still does nothing at all, because no controller is watching that kind. That is the whole CRD-versus-operator distinction in one terminal session.

Where each domain is taught

☺ Like you’re 10: Every question here comes from one of six pages. Go back to the page, not to a search engine.

Nothing in this paper is examined that is not taught in the sub-course. The six domain pages are the answer key at exam depth, and the CNPA hub maps each of them to the deeper CNPE lessons on the same ground if you want more than the associate exam asks for.

Where Set 2 sits in the CNPA kit

☺ Like you’re 10: Two full papers, a technique page, a schedule and six domain pages. Use them in that order and nothing is left to chance.

This paper is one piece of a set, and it is the second-to-last thing you should touch, not the first. The sensible sequence is: read the six domain pages, follow the study plan so the reading is spaced rather than crammed, learn the question anatomy and the traps on the practice-questions page, then sit Set 1 cold. Revise what it found. Then sit this paper, a week later, under the same conditions — far enough apart that you are testing knowledge rather than memory of a session.

And if the CNPE is where you are heading next, remember that everything above prepares the conceptual half only. The other half is reps: the lab track, the practice-task bank, and a timed CNPE mock exam where you are graded on cluster state rather than answers. The certifications overview maps the rest of the shelf.