Exam Prep · CNPA · associate · concept reference

The CNPA Concept Reference

The CNPA doesn't test whether you can type a command — it tests whether you recognise an idea when it's dressed up in exam language, and can tell it apart from the plausible-sounding idea next to it. This page is the broad reference for that: every term worth knowing across all six domains, organised the way the blueprint is organised, each with a crisp definition and — wherever the exam likes to set a trap — the thing it's commonly confused with and how to tell them apart. It is deliberately wide rather than tight: this is the page you read from, not the list you cram the night before.

⚠ Study-time only — the CNPA is closed-book

Say this plainly so nobody mistakes it for something else: this page cannot come into the exam with you. Per the Linux Foundation's own certification resources policy, “candidates are NOT PERMITTED to access tools, resources or external sites when taking the Linux Foundation Multiple Choice ... Exams.” No kubernetes.io, no notes, no this page. That's the opposite of the CNPE, which is performance-based and lets you keep the official docs open — the CNPA gives you 120 minutes and a closed browser, and expects the six domains below to already be in your head. Use this page in the weeks before you sit, not the morning of.

☺ Explain it like I'm 10

Imagine a big test with six sections, and every section is really just a pile of vocabulary words dressed up as questions. The trickiest questions aren't “what is a golden path?” — they're “here are two things that sound almost the same, which one is this?” This page is a big dictionary sorted into the same six piles as the test, and next to every tricky word it also tells you the word's evil twin — the one the test loves to swap in to see if you were really paying attention.

🦉🐿️Your hosts for this topic: Professor Owl & Nutty the Squirrel — Owl sorts every idea into the six-domain blueprint so nothing floats free, and Nutty is the Guild's cataloguer, the one who notices when two words look alike and files a note explaining the difference before anyone gets fooled.

How this reference works — and how it differs from its two neighbours

☺ Like you're 10: There are three different helper pages and they're not the same thing. This one is the big shelf of dictionaries. Another one is the tiny index card you actually memorise. A third is the site's one giant dictionary for everything, not just this exam.

Three pages on this site look similar and do different jobs, and confusing them wastes study time. The site glossary is the whole course's A-to-Z dictionary — 330-odd terms across every CNPE and CNPA topic, alphabetical, exhaustive, not sorted by exam weight. This page is narrower and reorganised: only CNPA-relevant concepts, grouped under the six official CNPA domains in blueprint order, so you can read a whole domain's vocabulary in one sitting and see the confusions the exam actually sets. And Know Cold is narrower still — the tight, ruthless subset of this page that you should be able to recite with your eyes closed the morning of the exam, no elaboration, no confusions column, just the must-not-forget facts. The order to use them in: read a domain here first for breadth and context, distil your own shortlist into Know Cold as you go, and drill that shortlist in the final week.

Pair this page with the CNPA study plan for the calendar around it, and with the triage page when you're mid-question and need to work out which domain a stem belongs to. When a term below sends you deeper than a definition, it links to the full CNPA domain lesson or the underlying CNPE page that treats it properly.

◆ The whole idea

Breadth here, tightness there. This page's job is to make sure you've met every idea the blueprint can test and seen its nearest look-alike. Know Cold's job is to make sure the twenty or so facts you're most likely to blank on are burned in. Read this page five times over four weeks; read Know Cold every single day of the last one.

Domain 1 · Platform Engineering Core Fundamentals · 36%

☺ Like you're 10: This is the biggest pile of words, because it's the biggest slice of the test — more than a third of it. It's the vocabulary of "what is a platform and why declare things instead of doing them by hand."

More than a third of the paper lives here, spanning declarative resource management, DevOps practice, environments and infrastructure, platform architecture, platform goals, CI fundamentals, and CD with GitOps. The full domain lesson teaches all seven competencies properly; what follows is the vocabulary you should already recognise before you read it.

Platform vocabulary and goals

Platform engineeringThe discipline of building and operating an internal platform — self-service tooling, golden paths, and shared infrastructure — that removes toil from product teams so they ship faster and safer.

Internal Developer Platform (IDP)The complete self-service layer a platform team builds: the APIs, tooling, and golden paths that let developers provision what they need without filing a ticket. Often confused with a developer portal: the portal is the UI on top; the platform is everything underneath it, portal or no portal.

Developer portalA single UI (commonly Backstage) that presents the platform's catalog, docs, and templates to developers. It is the platform's storefront, not the platform itself — you can have an IDP with no portal, just not the reverse in any useful sense.

Golden pathThe opinionated, supported, well-lit route through the platform: take it and CI, security, and observability come for free. Often confused with a mandate: a golden path can be left (you carry the extra load yourself); a mandate cannot be left at all.

Platform as a productTreating the platform's engineers as developers, not tickets — with a roadmap, user research, and success metrics — rather than a shared-services team that reacts to requests.

Cognitive load (intrinsic vs. extraneous)The total mental effort a developer spends to get work done. Intrinsic load is the actual problem they were hired to solve; extraneous load is everything else the environment forces them to learn. Platforms exist to move extraneous load off product teams and onto the platform team.

Self-serviceDevelopers provisioning what they need (a database, an environment, a pipeline) through an API or portal, without a human in the loop. The measurable outcome a golden path is supposed to produce.

Thinnest Viable Platform (TVP)Team Topologies' advice to start a platform as small as possible — sometimes a wiki page or a thin wrapper script — and grow it only as real developer demand proves it out, rather than building a grand platform nobody asked for.

ToilManual, repetitive, automatable operational work that scales with load and leaves nothing lasting behind — the "Ticket Swamp" a platform exists to drain. Distinct from incident response, which is reactive rather than routine.

Day-2 operationsEverything after the initial install: upgrades, scaling, backup, monitoring, incident response. Contrasted with day-1, the one-time bootstrap — a good platform automates day-2, not just day-1.

Declarative resource management and the Kubernetes floor

Declarative vs. imperativeDeclarative states the desired end result and lets a system figure out how to get there (a YAML manifest); imperative issues step-by-step commands (a shell script running kubectl create, then kubectl expose...). Kubernetes and GitOps are built around the declarative model because it's idempotent and diffable.

Desired state vs. actual stateDesired state is what you declared should exist; actual state is what's really running right now. Every controller's whole job is to shrink the gap between the two to zero, repeatedly.

Reconciliation loop (control loop)The observe → diff → act cycle every Kubernetes controller runs forever: read desired state, compare to actual state, take action, repeat. The mechanism underneath GitOps, operators, and autoscalers alike.

Level-triggered vs. edge-triggeredA level-triggered system re-checks the current state continuously and self-corrects even if it missed an event; an edge-triggered system reacts once to a specific change and can miss it if the event is dropped. Kubernetes controllers are deliberately level-triggered — that's why they self-heal.

NamespaceA virtual partition inside one cluster used to scope names, RBAC, and quotas for a team or app. Often confused with a separate cluster: a namespace shares the control plane and node pool with every other namespace; a cluster does not share anything.

PodThe smallest deployable unit in Kubernetes — one or more containers that share network and storage, scheduled together onto one node.

Deployment vs. ReplicaSetA ReplicaSet keeps a fixed number of identical Pod replicas running; a Deployment manages ReplicaSets on your behalf to support rolling updates and rollback. You almost always create a Deployment and let it own the ReplicaSet, not the other way round.

Control plane vs. data planeThe control plane makes decisions (API server, scheduler, controllers, etcd); the data plane does the actual work the decisions describe (kubelets, running containers, a mesh's sidecar proxies). The same split recurs in service meshes.

etcdThe consistent key-value store that holds all of a cluster's desired and observed state — the single source of truth the API server reads and writes.

kubeletThe node agent that talks to the container runtime to actually start, stop, and health-check the containers a Pod's spec describes — the last hop between the API and reality.

DevOps, CI fundamentals, and CD with GitOps

DevOpsThe cultural and technical movement to break down the wall between building software and running it, so the people who write code also feel the pain (and own the fix) of running it in production. Platform engineering is a more prescriptive, tooling-heavy way of achieving DevOps' goals at scale, not a replacement for it.

CI (Continuous Integration)Automatically building and testing every code change as it merges, so integration problems surface in minutes, not weeks. The first half of a CI/CD pipeline.

Continuous Delivery vs. Continuous DeploymentBoth automate everything up to a release-ready artifact. Delivery stops there — a human still clicks to release. Deployment removes that click and ships every passing change straight to production. The exam loves swapping these two.

Build, release, deployThree distinct steps often blurred together: build compiles/packages an artifact; release decides an artifact is fit to ship; deploy actually puts it where users hit it. GitOps automates deploy from a release decision recorded in Git.

GitOpsUsing a Git repository as the single source of desired state, with an in-cluster agent that continuously pulls and reconciles the cluster to match it. Often confused with "CI runs kubectl apply on every merge": that's push-based and only reconciles at merge time — it satisfies two of the four OpenGitOps principles but not all four.

OpenGitOps four principlesDeclarative, versioned & immutable, pulled automatically, continuously reconciled. All four must hold for a system to count as "real" GitOps — see GitOps Workflows for the long version.

Push vs. pull deploymentPush: an external actor (a CI job) reaches into the cluster to change it, requiring the pipeline to hold cluster credentials. Pull: an agent inside the cluster reaches out to Git and updates itself, so the pipeline never needs cluster access. GitOps is the pull model.

Environment (dev/staging/prod)A distinct deployment target with its own config and (usually) its own infrastructure, used to test changes with increasing confidence before they reach users. Modelled with Kustomize overlays or Helm values on top of a shared base, not by copy-pasting manifests.

Immutable infrastructureNever patching a running server or container in place — instead building a new image/version and replacing the old one wholesale. Pairs naturally with declarative, Git-tracked desired state.

Domain 2 · Platform Observability, Security & Conformance · 20%

☺ Like you're 10: This pile is "how do we watch the platform for trouble" plus "how do we stop the wrong things from happening in the first place" plus "can we prove it's all set up correctly."

The second-largest domain, spanning the four observability signals, secure service communication, policy engines, Kubernetes security essentials, and security in CI/CD — plus conformance, proving the platform is provably standard rather than merely "working on our cluster." The full domain lesson covers each competency in depth; see also Observability & Operations and Security & Policy Enforcement.

The four signals and how to collect them

MetricA cheap numeric measurement sampled over time (request count, CPU percent) — good for dashboards, alerts, and trends. Often confused with a log: a metric can't tell you which request failed, only that the error rate rose.

LogA timestamped, discrete record of one event, usually with free-text detail. Cheap to produce, expensive to query at volume compared to a metric — the two are complementary, not substitutes.

TraceA record of one request's journey across multiple services, built from linked spans, showing where time was actually spent. Answers "why was this one request slow," which neither a metric nor a log can do well.

Event (Kubernetes)An object the API server or a controller emits narrating a state change (scheduling failure, image pull error). The fastest place to look when a Pod won't start — distinct from application logs, which come from the container itself.

OpenTelemetry (OTel)The CNCF standard and toolkit (SDKs, a collector) for producing and shipping metrics, logs, and traces in a vendor-neutral format, so you can swap backends without re-instrumenting code.

RED method vs. USE methodRED (Rate, Errors, Duration) is request-focused — the right lens for a service. USE (Utilization, Saturation, Errors) is resource-focused — the right lens for a node, disk, or queue. Picking the wrong one for the question is a common exam trap.

Golden signalsGoogle SRE's four: latency, traffic, errors, saturation — the minimum set worth alerting on for any user-facing service.

SLI / SLO / SLAAn SLI is the measured indicator (e.g. p99 latency); an SLO is the internal target for it (e.g. 99.9%); an SLA is the external, often contractual, promise with consequences for missing it. The error budget is 100% minus the SLO.

Secure service communication and policy engines

mTLS (mutual TLS)Both sides of a connection present and verify a certificate, so service A proves its identity to service B and vice versa. Often confused with plain TLS, where only the server proves its identity (as in a browser visiting a website).

Service meshAn infrastructure layer (Istio, Linkerd) that transparently adds mTLS, retries, and traffic control between services, usually via sidecar proxies, without changing application code.

NetworkPolicyA Kubernetes object that whitelists allowed traffic between pods at L3/L4 (IP and port). Often confused with a service mesh's L7 policy: NetworkPolicy can't see HTTP paths or methods, only IPs and ports — it needs a CNI that enforces it.

Admission controllerCode inside the API server's request path that runs after authentication/authorization but before an object is persisted, letting it validate or mutate the object. The plug-in point behind policy engines and Pod Security.

Validating vs. mutating webhookA validating webhook accepts or rejects an object unchanged. A mutating webhook can rewrite the object before it's stored (injecting a sidecar, adding a label). Mutating webhooks always run before validating ones.

Policy engineA general-purpose admission-time rule evaluator (Kyverno, OPA/Gatekeeper) that enforces "all Deployments must set resource limits" as code instead of a wiki page nobody reads.

RBAC: Role vs. ClusterRoleA Role grants permissions within one namespace; a ClusterRole grants them cluster-wide (or for cluster-scoped resources). Bound to a subject with a RoleBinding or ClusterRoleBinding respectively.

Pod Security AdmissionThe built-in Kubernetes mechanism that enforces one of three baked-in profiles (privileged, baseline, restricted) at the namespace level. Distinct from a pod's own securityContext, which sets the actual security settings PSA then checks against the profile.

Supply chain and conformance

SBOM (Software Bill of Materials)A structured inventory of every package and dependency inside an artifact — what you scan for known vulnerabilities and what you'd hand an auditor.

Image signing / cosignCryptographically signing a container image so its origin can be verified before it's allowed to run — cosign is the common Sigstore tool for this. Complements, but doesn't replace, vulnerability scanning.

Provenance / attestationA signed statement about how an artifact was produced ("built by this pipeline, from this commit") that admission control can require before allowing a deploy — the evidence layer above a signature.

Shift leftMoving a check (a vulnerability scan, a policy test) earlier in the pipeline — into CI or even the developer's IDE — so it's caught before it's expensive to fix, rather than at admission or in production.

Conformance (CNCF Certified Kubernetes)A cluster passing the CNCF's conformance test suite, proving its API behaves per spec — the guarantee that a workload written against "Kubernetes" behaves the same on any conformant distribution.

Audit logA chronological record of every request made to the Kubernetes API server — who did what, when — used for compliance evidence and post-incident forensics.

Domain 3 · Continuous Delivery & Platform Engineering · 16%

☺ Like you're 10: This pile is where a platform stops being a diagram and starts actually shipping software — the pipeline, the way changes roll out gradually, and what happens when something breaks anyway.

Covers CI pipelines overview, the CI/CD relationship, GitOps basics and workflows, GitOps for application environments, and incident response. Heavily paired with Domain 1's "CD and GitOps" competency — expect the exam to test the same ideas from both directions. The full domain lesson and CI/CD & Progressive Delivery go deeper.

Pipelines and repo structure

Pipeline stagesThe standard sequence a CI/CD pipeline runs a change through: build, test, scan, package, then (in CD) release and deploy. Kubernetes-native tools like Tekton and Argo Workflows model each stage as a container step.

App repo vs. config repoThe app repo holds source code, the Dockerfile, and CI; the config repo holds the manifests a GitOps reconciler watches. Keeping them separate stops "which repo do I edit to change replicas" confusion and lets app and platform teams own different review policies.

Overlay (Kustomize) vs. values file (Helm)Two different ways to vary one base manifest per environment: a Kustomize overlay patches a shared base; a Helm values file fills in a chart's templates. Both answer "how do dev, staging, and prod differ without three copies of the YAML."

ApplicationSetAn Argo CD controller that templates many Application objects from a generator (list, cluster, Git-directory, matrix, pull-request), so onboarding a new team can be "add one folder" instead of hand-writing an Application.

Progressive delivery and rollback

Rolling updateReplacing old Pods with new ones a few at a time, keeping the service available throughout — Kubernetes Deployments do this by default. The baseline strategy every other one is compared against.

Blue/green deploymentRunning two complete environments (blue = current, green = new) and flipping all traffic at once. Rollback is instant — flip back — but it costs double the infrastructure while both are up. Often confused with canary: blue/green is all-or-nothing; canary is gradual.

Canary deploymentShifting a small slice of live traffic to the new version, watching its metrics, then ramping up gradually — limiting the blast radius of a bad release. Argo Rollouts and Flagger both automate this against real metrics.

Feature flag vs. canaryA feature flag toggles behaviour inside one running version, instantly, for any subset of users you define in code. A canary shifts traffic between two deployed versions. They solve different problems and are often used together, not interchangeably.

Rollback in a GitOps worldBecause desired state is versioned in Git, the correct rollback is git revert on the commit that changed things — not a manual kubectl edit, which self-heal would immediately undo anyway.

Incident response lifecycleDetect → triage → mitigate → resolve → postmortem. The platform's job during an incident is mitigation speed (often "roll back," thanks to GitOps) before root-cause analysis.

MTTR (Mean Time To Restore/Repair)The average time from an incident starting to service being restored — one half of the DORA stability pair (see Domain 6), and the number progressive delivery and fast rollback are built to shrink.

Domain 4 · Platform APIs & Provisioning Infrastructure · 12%

☺ Like you're 10: This pile explains the trick that makes self-service possible: teams can invent brand-new kinds of object for Kubernetes to manage, then write a tireless robot that makes each one real.

Covers the reconciliation loop (recapped from Domain 1 with an APIs lens), CRDs as self-service APIs, infrastructure provisioning with Kubernetes, and the operator pattern. The full domain lesson, Platform APIs & Operators, and Crossplane go deeper.

Extending the API

CRD (CustomResourceDefinition) vs. CR (Custom Resource)A CRD registers a brand-new kind with the API server — the schema, like a class. A CR is one instance of that kind — like an object. You define the CRD once; developers create many CRs against it.

Controller vs. operatorA controller is any process running a reconciliation loop against a resource type, built-in or custom. An operator is specifically a CRD plus a controller that together package the operational knowledge of a human expert — the name comes from the person who used to hold that runbook.

Watch, informer, work queueThe mechanics under every controller: a watch streams change notifications from the API server; an informer caches objects locally so the controller doesn't hammer the API; a work queue de-duplicates and paces the resulting reconcile calls.

API aggregation layerAn alternative to CRDs where a custom API server registers its own API group behind the main one, appearing as a native endpoint. Rarer, and reserved for cases a CRD's schema model can't express.

Provisioning infrastructure through Kubernetes

Kubernetes as a universal control planeThe idea that once the API is extensible, nothing restricts a "resource" to workloads — a Kubernetes object can represent an S3 bucket, a managed Postgres instance, or a whole cluster, gaining the same RBAC, audit trail, and GitOps workflow as any Deployment.

Crossplane: XRD vs. Composition vs. ClaimAn XRD declares a new platform API's shape (like a CRD, but for a composite). A Composition is the implementation — the recipe that turns the abstract request into real cloud resources. A Claim is the namespaced, developer-facing request ("I want a database") that triggers it.

Managed Resource vs. Composite Resource (XR)A Managed Resource represents one real external cloud resource (one RDS instance). A Composite Resource is Crossplane's internal object bundling several Managed Resources into the one thing a Claim asked for. Developers see the Claim; the platform team designs the Composition and XR.

Provider / ProviderConfigA Provider installs the controllers for one cloud or system (AWS, GCP); its ProviderConfig supplies the credentials those controllers use to act on your behalf.

One-shot IaC vs. a reconciling control planeClassic infrastructure-as-code (Terraform apply) runs once per change and stops — drift between runs goes unnoticed until the next apply. A Kubernetes-native provisioner (Crossplane) reconciles continuously, the same way any controller does, so drift is corrected automatically rather than waiting for the next scheduled run.

Cluster API (CAPI)A Kubernetes sub-project that manages the lifecycle of Kubernetes clusters themselves — create, scale, upgrade, delete — declaratively via CRDs, treating clusters as cattle rather than pets.

Domain 5 · IDPs & Developer Experience · 8%

☺ Like you're 10: This pile is about what the machinery feels like from the outside — the storefront, the catalog, and where AI is (and isn't) allowed to help.

Joint-smallest domain, tied with Measuring, but tested crisply: simplified access to platform capabilities, API-driven service catalogs, developer portals for platform adoption, and AI/ML in platform automation. The full domain lesson and Self-Service & Golden Paths go deeper.

Catalogs, portals, and the AI boundary

Service catalogThe platform's inventory of every service, its owner, its docs, and its dependencies — the map a developer or an on-call engineer consults to find "who owns this and how do I talk to it."

API-driven service catalogA catalog populated and kept current by an API (entities registered programmatically, descriptor files read from each repo) rather than hand-edited in a wiki. "API-driven" is the load-bearing word — a catalog that's manually curated isn't one, however complete it looks today.

catalog-info.yaml (entity descriptor)A small metadata file living beside the code it describes (in Backstage, this exact filename) so a service's catalog entry updates automatically as the repo changes, instead of drifting from a portal edited separately.

BackstageThe open-source developer-portal framework (built at Spotify, donated to the CNCF) unifying a software catalog, golden-path software templates, and docs-as-code behind one UI — the most common concrete answer to "developer portal" on this domain.

Software template (scaffolder)A golden path made executable: fill in a few parameters in the portal and it generates a new repo, wires up CI, and often opens a PR against a config repo — the click-button version of "clone the last service and rename things."

Paved road vs. escape hatchThe paved road is the supported golden path; the escape hatch is the deliberate, sanctioned way to leave it when a team's needs genuinely don't fit — carrying the extra maintenance burden themselves rather than being blocked outright.

Golden cage (anti-pattern)A "golden path" that's secretly a mandate — technically self-service, but so rigid or so heavily gated that teams can't actually leave it when they need to, defeating the whole point of a path over a wall.

AI/ML in platform automationTwo distinct directions the curriculum tests separately: AI for the platform (an assistant that suggests a fix, drafts a manifest, summarises an incident — human approves) versus the platform for AI/ML (serving GPU workloads, model registries). The exam trap is an AI given autonomous write access across a trust boundary with no human in the loop.

Domain 6 · Measuring your Platform · 8%

☺ Like you're 10: The smallest pile, but it's the one that answers "did any of this actually work?" — with a number, not a feeling.

Just two competencies — platform efficiency and team productivity, and DORA metrics for platform initiatives — making this the best points-per-page ratio on the paper. The full domain lesson, DORA & SPACE, and FinOps go deeper.

Efficiency, productivity, and honest measurement

Output vs. outcome vs. vanity metricOutput counts activity (commits shipped); outcome measures the effect that activity had (lead time dropped); a vanity metric looks impressive but doesn't connect to either (lines of code written). The exam consistently rewards outcome over output.

Showback vs. chargebackShowback reports each team's cloud/Kubernetes cost without billing them for it; chargeback actually bills the owning cost center. Showback changes behaviour through visibility; chargeback changes it through budget pressure.

SPACE frameworkA model of developer productivity across five dimensions — Satisfaction, Performance, Activity, Communication, Efficiency — deliberately multi-dimensional so no single number (like commit count) stands in for "productive."

DevEx (Developer Experience)The qualitative and quantitative experience of getting work done on the platform — feedback-loop speed, cognitive load, flow state. Distinct from DORA: DevEx is about how it feels and how fast feedback arrives; DORA is about delivery outcomes.

Goodhart's Law"When a measure becomes a target, it ceases to be a good measure." The reason surveys and metrics get gamed once someone's bonus depends on them — a standing caution anywhere this domain measures people.

DORA metrics for platform initiatives

Deployment frequencyHow often an organization successfully releases to production — a speed metric. Higher generally reflects smaller, safer, more automated releases.

Lead time for changesThe time from a commit landing to that change running in production — the other speed metric, measuring the pipeline's end-to-end friction.

Change failure rateThe percentage of production deployments that cause a failure requiring remediation (rollback, hotfix, patch) — a stability metric. Lower is better.

Time to restore service (MTTR)How long it takes to recover from a failed deployment or outage once it happens — the other stability metric. The four DORA keys pair two speed metrics with two stability metrics deliberately, so neither can be improved by sacrificing the other.

Performance cohorts (elite/high/medium/low)The four bands DORA research groups organizations into based on all four keys together — used to benchmark a platform initiative's effect on a team over time, not to shame an individual sprint.

Baseline, segment, trendThe three moves that make DORA evidence honest for "a platform initiative" specifically: record the keys before it ships (baseline), compare onboarded vs. not-yet-onboarded teams (segment), and read direction over months rather than one quarter (trend).

Using this reference to build your Know Cold list

☺ Like you're 10: You won't memorise all ninety-something of these — and you don't need to. Pick the ones that trip you up, and put only those on your tiny final list.

This page is intentionally too long to memorise wholesale — that's what makes it a reference and not a cram sheet. The way to use it: read one domain section at a time, close the page, and write from memory the terms you couldn't confidently define or disambiguate. Whatever you couldn't produce is what belongs on the Know Cold list — the tight, no-elaboration version you actually drill daily in the final week. If you find yourself wanting to copy most of a domain's terms onto Know Cold, that's a signal to re-read the full domain lesson, not just this glossary — a definition without the surrounding story rarely survives a reworded exam stem.

Three more pages close the loop. The triage page is what you reach for mid-question, when you recognise a term here but aren't sure which domain the stem is really testing. The docs map matters less for the CNPA than the CNPE, precisely because the CNPA is closed-book — but it's worth knowing which official pages these terms trace back to, for when you want the primary source instead of our paraphrase. And the study plan is the calendar that tells you when, in a four-week schedule, to read each domain section here.

🎬 At the Platform Guild
🦊Foxy: Ninety-something terms feels like a lot for an "associate" exam.
🦉Professor Owl: It's wide on purpose. You don't memorise a reference — you read it once per domain, notice what surprised you, and only that goes on the tight list.
🐿️Nutty: And half the questions aren't "define this term" — they're "which of these two similar-sounding things is it." That's why I filed the confusions right next to the definitions instead of in a separate table nobody reads.
👺Gizmo: Or just keep this tab open during the exam. Who's gonna check? 🤑
🐢Timmy: The proctor, Gizmo. The CNPA is fully closed-book — no tabs, no notes, nothing. This page exists to be memorised out of, not smuggled in.
🦆Dot: I just want to know which page to open first. This one, right? Before the tight list?
🦉Professor Owl: Exactly that order. Breadth, then tightness. Read wide, drill narrow.

🐢 Timmy's checkpoint

1. Why is this page organised by CNPA domain instead of alphabetically like the site glossary? 2. Name the difference between an Internal Developer Platform and a developer portal. 3. A question describes CI running kubectl apply on every merge and calls it GitOps — which two OpenGitOps principles does it fail, and why? 4. What's the difference between a Composition and a Claim in Crossplane? 5. Why does DORA pair two speed metrics with two stability metrics instead of just tracking deployment frequency? 6. Can you bring this page into the CNPA exam? Why or why not?

Check your answers

Because the CNPA blueprint weights domains very unevenly (36% down to 8%), and studying vocabulary in blueprint order keeps your reading time proportional to what's actually being tested — the site glossary, by contrast, is exhaustive and alphabetical across the whole course, not weighted to this one exam.
The IDP is the whole self-service layer — APIs, tooling, golden paths. The portal is the UI on top of it (commonly Backstage). You can have a platform with no portal; a portal with no platform underneath is just a pretty page with nothing to click through to.
It fails pulled automatically and continuously reconciled: a human-triggered CI job pushes changes at merge time, but nothing re-checks or corrects drift that happens between merges — it satisfies declarative and versioned, but not the other two.
A Composition is the platform team's recipe — the implementation mapping an abstract request to concrete Managed Resources. A Claim is the developer-facing, namespaced request that triggers a Composition to run — the front door, not the recipe behind it.
So that a platform can't look good on paper by trading one for the other — e.g. deploying constantly (high frequency) while breaking things constantly (high change failure rate). Pairing speed with stability catches that gaming.
No. The Linux Foundation's certification resources policy states plainly that candidates may not access any tools, resources, or external sites during Linux Foundation Multiple Choice Exams, and the CNPA FAQ confirms it is fully closed-book. This page is a study-time tool only.