KCNA cheat sheet
104 key facts across 4 exam domains, distilled from the full KCNA revision notes — with the exam pattern behind each topic. Skim it the week of your exam.
Updated
Kubernetes Fundamentals
44% of the examKubernetes Core Concepts: Architecture, Pods, Deployments, and Services
- A Pod is the smallest deployable unit; its containers share one network namespace (one IP) and can share volumes.
- The kube-apiserver is the front door: kubectl, the kubelet, and all controllers talk to the cluster only through it.
- etcd is the cluster's key-value datastore and single source of truth; only the API server reads and writes it directly.
- The kube-scheduler only picks a node for each Pod; the kubelet on that node actually starts the containers via the runtime.
- A ReplicaSet keeps N identical Pods alive; a Deployment manages ReplicaSets to add rolling updates and rollbacks.
- A Service gives a stable virtual IP and DNS name to an ever-changing set of Pods selected by labels.
- Namespaces scope names, access, and quotas; labels plus selectors are the glue that connects Services and controllers to Pods.
- Kubernetes is declarative: controllers continuously reconcile observed state toward the desired state stored in etcd, which is what self-healing means.
How the exam tests this
KCNA probes this topic almost entirely at recognition depth: expect questions of the form which component stores cluster state, which object is the smallest deployable unit, or what a Deployment adds on top of a ReplicaSet. Watch for trigger phrases: front door or single point of entry points to the kube-apiserver, key-value store points to etcd, assigns Pods to nodes points to the scheduler, and node agent points to the kubelet. Scenario stems about a stable address for changing Pods want a Service, and anything about self-healing or desired versus observed state wants the controller reconciliation loop. Distractors often swap the scheduler for the kubelet or claim kubectl talks to etcd directly - both are wrong.
Kubernetes Administration: kubectl, RBAC, Namespaces, and Resource Quotas
- Every kubectl command is an HTTPS request to the kube-apiserver; kubectl never talks to nodes or etcd directly.
- kubectl apply is declarative and idempotent; create, run, scale, and expose are imperative one-off commands with no file as source of truth.
- A Role grants permissions inside one namespace; a ClusterRole grants them cluster-wide or on cluster-scoped resources like nodes.
- RoleBindings and ClusterRoleBindings attach a Role or ClusterRole to subjects: users, groups, or ServiceAccounts.
- RBAC is additive and allow-only: there are no deny rules, and anything not explicitly granted is forbidden.
- ServiceAccounts are the API identities of workloads; users and groups represent humans and are not Kubernetes API objects.
- A ResourceQuota caps a namespace's total consumption; a LimitRange sets per-container defaults, minimums, and maximums.
- Namespaces scope names, access, and quotas, but they do not isolate the network - that requires NetworkPolicies.
How the exam tests this
Administration questions on KCNA are matching exercises: pair the RBAC object with its scope (Role and RoleBinding to one namespace, ClusterRole and ClusterRoleBinding to the whole cluster), pair kubectl apply with declarative and create, run, and scale with imperative, and pair ResourceQuota with namespace totals versus LimitRange with per-container bounds. Trigger words to watch: across all namespaces or on nodes signals a ClusterRole, identity used by a Pod signals a ServiceAccount, and safe to run repeatedly or stored in Git signals kubectl apply. Remember that kubectl only ever talks to the kube-apiserver, and that RBAC has no deny rules - options describing an explicit deny are distractors.
Kubernetes Scheduling: Requests, Node Affinity, Taints and Tolerations
- The kube-scheduler works in two phases: filter out infeasible nodes, then score the feasible ones and bind the Pod to the winner.
- Requests drive scheduling and reserve capacity; limits are enforced at runtime and play no part in placement.
- A container over its CPU limit is throttled; one over its memory limit is OOMKilled.
- Affinity and nodeSelector attract Pods to nodes; taints repel Pods; a toleration permits but never forces placement on a tainted node.
- requiredDuringScheduling rules are hard filters; preferredDuringScheduling rules only influence scoring and can be ignored.
- NoExecute is the only taint effect that evicts already-running Pods; NoSchedule only blocks new ones.
- A DaemonSet runs exactly one Pod on every eligible node; new nodes get the Pod automatically.
- A Pod stays Pending when no single node passes filtering; kubectl describe pod shows the reason in its events.
How the exam tests this
KCNA questions on scheduling are pure recognition: which component assigns Pods to nodes (kube-scheduler), whether requests or limits drive placement, and what each mechanism does. Expect trigger phrases like 'repel Pods from a node' (taints), 'schedule onto a tainted node' (tolerations), 'one Pod per node' (DaemonSet), and 'required versus preferred' (hard versus soft affinity). The Pending-Pod scenario appears as a which-of-these-causes-this question, so tie Pending to filtering failures such as insufficient requests, unmatched selectors and untolerated taints.
Containerization: Images, Container Runtimes, CRI and the OCI Explained
- A container is an isolated process on a shared host kernel: namespaces control what it sees, cgroups control what it uses.
- Containers virtualize the operating system; VMs virtualize the hardware and each carry their own guest kernel.
- Images are immutable stacks of read-only layers; tags are mutable pointers, digests are immutable content hashes.
- The kubelet drives the container runtime through the CRI; containerd and CRI-O are the mainstream CRI runtimes, and both delegate to runc.
- Kubernetes deprecated the Dockershim in 1.20 and removed it in 1.24; Docker-built images still run because they are OCI images.
- The OCI publishes the image, runtime and distribution specs; runc is the reference runtime implementation.
- Podman is a daemonless, rootless-friendly alternative to Docker with a compatible CLI, producing the same OCI images.
- Containers in one Pod share a network namespace and one IP, talking to each other over localhost.
How the exam tests this
KCNA probes containerization with definitional questions: which kernel features containers are built on (namespaces and cgroups), containers versus VMs (shared kernel is the trigger), and which body standardizes image and runtime formats (OCI, not CNCF or CRI). Expect the Dockershim question in some form, with wrong answers implying Docker images stopped working; the correct framing is that only Docker Engine as a kubelet-driven runtime was removed in 1.24. Distractors also swap CRI and OCI, or containerd and runc, so know which layer each name lives at.
Container Orchestration
28% of the examKubernetes Networking: Services, kube-proxy, CNI, DNS, and Ingress
- Every Pod gets its own IP address, and Pods communicate across nodes without NAT; that flat model is implemented by the CNI plugin, not by Kubernetes itself.
- A Service provides a stable virtual IP and DNS name in front of ephemeral Pods, selected by labels and tracked through EndpointSlices.
- kube-proxy runs on every node and programs iptables or IPVS rules that make Service IPs deliver traffic to real Pod endpoints.
- ClusterIP is internal-only and the default; NodePort opens a high port (30000-32767) on every node; LoadBalancer provisions a cloud load balancer on top of NodePort.
- A headless Service (clusterIP: None) returns Pod IPs directly in DNS; ExternalName returns a CNAME to an outside hostname.
- CoreDNS resolves names like api.shop.svc.cluster.local; short names work within the same namespace.
- Ingress defines layer 7 host and path routing but does nothing without an Ingress controller; the Gateway API is its emerging successor.
- Pods are default-allow until a NetworkPolicy selects them; then everything not explicitly allowed in the covered direction is denied, and enforcement requires a CNI plugin that supports policies.
How the exam tests this
KCNA tests networking as component-to-job matching: expect questions like which component implements Services (kube-proxy), which assigns Pod IPs (the CNI plugin), which resolves service names (CoreDNS), and which object routes HTTP by host and path (Ingress, which needs a controller). Trigger words include flat network, without NAT, ClusterIP, NodePort range, headless, CNAME, and default-allow versus default-deny. Scenario stems often ask you to pick the right Service type for a described exposure need, or to predict what happens once a NetworkPolicy selects a Pod.
Kubernetes Security: The 4Cs, RBAC, Secrets, and Pod Security Admission
- The 4Cs are Cloud, Cluster, Container, Code: nested layers of defense in depth, where each inner layer depends on the security of the layers outside it.
- RBAC is additive and allow-only: Roles and ClusterRoles grant verbs on resources, bindings attach them to subjects, and anything not granted is denied.
- A ServiceAccount is a Pod's API identity; give workloads dedicated minimal ServiceAccounts and disable token automounting when the API is not needed.
- Secrets are base64-encoded, not encrypted, by default; enable encryption at rest with an EncryptionConfiguration and restrict Secret access with RBAC.
- PodSecurityPolicy was removed in Kubernetes 1.25; Pod Security Admission enforces the Privileged, Baseline, and Restricted standards via namespace labels in enforce, audit, or warn mode.
- Core securityContext hardening: runAsNonRoot, allowPrivilegeEscalation: false, readOnlyRootFilesystem, drop ALL capabilities, and a RuntimeDefault seccomp profile.
- NetworkPolicies convert default-allow networking into explicit allow-lists that block lateral movement, and are enforced by the CNI plugin.
- Supply chain security means scanning images for CVEs, signing them for provenance, keeping an SBOM, and using minimal base images from trusted registries.
How the exam tests this
KCNA probes security with true-or-false style facts and layer classification: expect stems about Secrets being base64-encoded rather than encrypted, PodSecurityPolicy being removed in 1.25 in favor of Pod Security Admission, and which of the 4Cs a given control belongs to. Trigger words include least privilege, defense in depth, encryption at rest, Privileged, Baseline, Restricted, runAsNonRoot, SBOM, and admission controller. Scenario questions typically describe a risky Pod spec or an over-broad RBAC grant and ask which control or setting fixes it.
Troubleshooting Kubernetes: Pod Status, Events, Logs, and Probes
- The five Pod phases are Pending, Running, Succeeded, Failed, and Unknown; the STATUS column of kubectl get pods shows more specific reasons like CrashLoopBackOff.
- ImagePullBackOff means the image cannot be pulled (bad name, tag, or credentials); CrashLoopBackOff means the image ran but the container keeps exiting.
- OOMKilled means the container exceeded its memory limit and was killed, classically with exit code 137.
- kubectl describe ends with the Events section, where scheduling failures (FailedScheduling), mount failures (FailedMount), and probe failures (Unhealthy) are recorded.
- kubectl logs --previous shows output from the last terminated container instance, the key to diagnosing a crash loop; -c selects a container in multi-container Pods.
- A failing liveness probe restarts the container; a failing readiness probe only removes the Pod from Service endpoints; a startup probe delays both for slow-booting apps.
- A Service with no endpoints usually means its label selector matches no Pods or the matching Pods are not ready.
- A NotReady node means the kubelet stopped reporting healthy; describe node shows MemoryPressure, DiskPressure, and PIDPressure conditions.
How the exam tests this
KCNA tests troubleshooting as symptom-to-cause recognition: expect questions that show a Pod status like ImagePullBackOff, CrashLoopBackOff, or a persistent Pending and ask what it means or which command to run next. Trigger words include Events section, kubectl describe, kubectl logs --previous, no endpoints, and NotReady. Probe questions hinge on one distinction: liveness failures restart the container, readiness failures only remove the Pod from Service endpoints. You will not be asked to fix a cluster, only to match statuses, commands, and probe behaviors to the situations they diagnose.
Kubernetes Storage: Volumes, PersistentVolumes, PVCs, and CSI
- A Volume is declared in the Pod spec and (for ephemeral types like emptyDir) lives and dies with the Pod; emptyDir survives container restarts but not Pod deletion.
- PersistentVolumes are the cluster-scoped supply of storage; PersistentVolumeClaims are namespaced requests that bind to them one-to-one, and Pods reference the claim, never the PV.
- The four access modes are ReadWriteOnce (RWO), ReadOnlyMany (ROX), ReadWriteMany (RWX), and ReadWriteOncePod (RWOP).
- ReadWriteOnce limits the volume to one node, not one Pod; only ReadWriteOncePod guarantees a single Pod, and it requires CSI.
- Reclaim policy Retain keeps the PV and its data (status Released, manual cleanup); Delete removes the PV and the underlying storage, and is typical for dynamically provisioned volumes.
- A StorageClass defines a provisioner and parameters; a PVC referencing it triggers dynamic provisioning, and a default class serves PVCs that specify none.
- CSI is the standard interface storage vendors implement, alongside CRI for runtimes and CNI for networking; it replaced in-tree volume plugins.
- StatefulSet volumeClaimTemplates create one PVC per replica (like data-db-0), and those PVCs are kept by default when Pods are rescheduled or scaled down.
How the exam tests this
KCNA probes storage as role recognition: which object requests storage (PVC) versus supplies it (PV), what a StorageClass adds (dynamic provisioning), and which interface vendors implement (CSI, offered beside CRI and CNI as distractors). Expect the access-mode abbreviations RWO, ROX, RWX, and RWOP, with the one-node-versus-one-Pod distinction for ReadWriteOnce as the standard trap, and Retain versus Delete reclaim behavior. Trigger words include emptyDir, hostPath, binding, Released, default StorageClass, and volumeClaimTemplates for StatefulSets.
Cloud Native Application Delivery
16% of the examCloud Native Application Delivery: GitOps, Helm, and Deployment Strategies
- RollingUpdate is the default Deployment strategy; Recreate stops all old Pods first and causes downtime
- Blue-green and canary are patterns, not strategy field values; canary traffic splitting typically needs a service mesh or Argo Rollouts
- kubectl rollout status watches a Deployment rollout and kubectl rollout undo rolls back to the previous revision
- GitOps keeps desired state in Git and an in-cluster controller pulls and reconciles it; Argo CD and Flux are the graduated CNCF GitOps tools
- In GitOps, deploys are merges and rollback is git revert; manual cluster edits show up as drift and are reconciled away
- A Helm chart plus values produces a release; helm upgrade and helm rollback move a release between numbered revisions
- Kustomize customizes plain YAML with bases and overlays, no templates, and runs via kubectl apply -k
- CI push model: the pipeline holds cluster credentials and applies changes; GitOps pull model: the agent inside the cluster fetches from Git
How the exam tests this
KCNA tests this topic with recognition questions: which strategy is the Deployment default, which pattern runs two full environments and switches traffic at once, and which tools implement GitOps. Trigger words include single source of truth, pull-based reconciliation, and drift (GitOps); chart, values, and release (Helm); and template-free overlays (Kustomize). Expect at least one question distinguishing the CI/CD push model from the GitOps pull model, and one matching blue-green or canary to its description.
Debugging Application Delivery: Stuck Rollouts, Failed Releases, and Rollbacks
- A rolling update only progresses as new Pods pass readiness probes; a bad release stalls while the old ReplicaSet keeps serving
- kubectl rollout status hangs on a stuck rollout; kubectl get replicasets shows the telltale two-ReplicaSet picture
- ProgressDeadlineExceeded (default progressDeadlineSeconds 600) marks Progressing=False but Kubernetes never rolls back automatically
- Bad image tags show as ImagePullBackOff; failing readiness probes show Running but 0/1 Ready; capacity problems show Pending
- kubectl rollout undo returns to a previous revision; revisionHistoryLimit (default 10) bounds how many old ReplicaSets are kept, and 0 disables rollback
- helm history shows revision states (deployed, superseded, failed, pending-upgrade) and helm rollback recovers a failed release
- helm upgrade --atomic auto-rolls-back on failure; without --wait, Helm can report success while the underlying rollout is stuck
- After any deploy, verify with observability signals: error rate and latency against the pre-deploy baseline, and logs from the new Pods
How the exam tests this
KCNA frames this topic as scenario questions: a rollout that hangs, one new Pod in ImagePullBackOff while old Pods keep serving, and what command recovers it. Trigger words include rollout status, rollout undo, ProgressDeadlineExceeded, revisionHistoryLimit, and helm rollback. Expect to be tested on the facts that Kubernetes never rolls back automatically, that readiness probe failures block rollout progress, and that the old ReplicaSet keeps serving while the new one is unhealthy.
Cloud Native Architecture
12% of the examObservability in Cloud Native: Metrics, Logs, and Traces
- Metrics measure trends over time, logs record discrete events, traces follow one request across services.
- Prometheus pulls metrics by scraping HTTP endpoints and stores them as labeled time series queried with PromQL.
- Alertmanager, not Prometheus itself, deduplicates, groups, and routes alert notifications.
- metrics-server powers kubectl top and the HPA with current CPU and memory only; it keeps no history and is not Prometheus.
- Containers log to stdout and stderr; a node-level DaemonSet agent like Fluentd or Fluent Bit ships logs to a central store.
- OpenTelemetry is vendor-neutral telemetry instrumentation; Jaeger is a backend that stores and visualizes traces.
- Prometheus, Fluentd, and Jaeger are CNCF graduated projects; exporters adapt third-party systems to Prometheus.
- Comparing requested resources with actual usage metrics is how you right-size workloads and control cluster cost.
How the exam tests this
KCNA probes observability at recognition depth: expect questions matching a pillar or tool to a scenario, such as which pillar shows where a request spent its time (traces) or which project collects logs (Fluentd or Fluent Bit). Trigger words include scrape and pull-based (Prometheus), PromQL, exporter, Alertmanager, kubectl top and HPA (metrics-server), stdout and DaemonSet (logging), and spans, context propagation, vendor-neutral instrumentation (OpenTelemetry) versus trace storage and visualization (Jaeger). Watch for distractors that swap Prometheus for metrics-server or OpenTelemetry for Jaeger.
Cloud Native Principles and the CNCF Ecosystem
- The CNCF definition names five techniques: containers, service meshes, microservices, immutable infrastructure, and declarative APIs.
- Cloud native systems aim to be loosely coupled, resilient, manageable, and observable, with change driven by automation.
- Microservices trade operational complexity for independent scaling, deployment, and team autonomy; monoliths are simpler to run and debug.
- Immutable infrastructure means replace, not patch: ship a new container image instead of modifying a running instance.
- Declarative APIs express desired state; reconciliation loops continuously drive actual state toward it, which enables self-healing.
- HPA scales Pod replicas, VPA right-sizes Pod requests, Cluster Autoscaler changes node count, and KEDA scales on events down to zero.
- Serverless means no server management and scale-to-zero; Knative brings request-driven and event-driven serverless to Kubernetes.
- CNCF projects mature from sandbox to incubating to graduated; Kubernetes was the first CNCF project and Prometheus the second.
How the exam tests this
KCNA tests these principles by recognition: expect to identify the five techniques in the CNCF definition, match each autoscaler to what it scales, and pick the cloud native practice over the legacy one in a scenario. Trigger words include desired state and reconciliation (declarative APIs), replace not patch and configuration drift (immutability), scale to zero and FaaS (serverless, Knative, KEDA), and sandbox, incubating, graduated (CNCF maturity). Distractors often swap HPA and VPA or claim cloud native requires a public cloud, which the definition contradicts.
CNCF Community, Project Maturity Levels, and Open Source Governance
- The CNCF is a project of the Linux Foundation and a vendor-neutral home for cloud native open source; Kubernetes was its first hosted project.
- CNCF projects have exactly three maturity levels, in order: Sandbox, Incubating, Graduated.
- Sandbox means early and experimental; Incubating means growing with real production users; Graduated means stable, widely adopted, and production-ready.
- The Technical Oversight Committee (TOC) governs project acceptance and advancement between maturity levels.
- Kubernetes was the first CNCF project to reach Graduated status.
- The CNCF landscape maps the ecosystem into functional categories and shows each hosted project's maturity level.
- Kubernetes organizes community work through Special Interest Groups (SIGs), each owning an area like network, storage, or security.
- Contributors help a project, maintainers lead it, end users run it in production, vendors sell around it, and ambassadors advocate for it.
How the exam tests this
KCNA probes this topic with pure recognition questions. Expect to match a described signal to a maturity level (experimental means Sandbox, production-ready means Graduated), to name the body that governs advancement (the Technical Oversight Committee), and to identify the CNCF as a Linux Foundation project whose first hosted project was Kubernetes. Trigger words include Sandbox, Incubating, Graduated, TOC, vendor-neutral, landscape, SIG, Code of Conduct, ambassador, and KubeCon; distractor options often invent maturity levels or credit the wrong body with graduation decisions.