KCNA — The Kubernetes and Cloud Native Associate Cheatsheet.

KCNA is the conceptual foundation of the Kubestronaut path: a 90-minute, online, proctored, multiple-choice exam with no prerequisites. Its current blueprint is Kubernetes Fundamentals 44% · Container Orchestration 28% · Cloud Native Application Delivery 16% · Cloud Native Architecture 12%. The exam rewards correct mental models and scenario judgment, not memorized command flags. Ask: which component owns this responsibility, which object expresses the intent, and which cloud-native principle explains the design?

0. Exam map and question strategy

Domain	Weight	What must be automatic
Kubernetes Fundamentals	44%	Architecture, API objects, reconciliation, scheduling, containers
Container Orchestration	28%	Networking, security, storage, troubleshooting
Application Delivery	16%	Declarative delivery, rollout, GitOps, debugging
Cloud Native Architecture	12%	Observability, CNCF landscape, principles and community

1. Kubernetes core model

Kubernetes is a declarative control system. You submit desired state to the API; controllers continuously compare desired state with observed state and act to close the gap. This loop is reconciliation. Objects are durable intent, not one-time commands.

Component	Responsibility	Common distractor
kube-apiserver	Authentication, authorization, admission and API front door	It does not schedule Pods
etcd	Strongly consistent store for cluster state	Applications should not use it directly
scheduler	Chooses a node for an unscheduled Pod	It does not start containers
controller manager	Runs reconciliation controllers	It does not proxy Service traffic
kubelet	Node agent that makes PodSpecs run	It is not the cluster scheduler
container runtime	Pulls images and runs containers through CRI	Docker is not required
kube-proxy / dataplane	Implements Service reachability	CNI handles Pod connectivity

# read desired and observed state side by side
kubectl get deploy web -o yaml
kubectl get pods -l app=web -o wide
kubectl describe pod <pod>     # conditions + events
kubectl api-resources           # discover object kinds and scope

Objects and controllers

Need	Choose	Reason
One disposable process	Pod	Smallest schedulable unit; usually managed by a controller
Stateless replicated app	Deployment	Rollouts, rollback and replica management
Stable identity and storage	StatefulSet	Ordered identity, stable DNS and per-Pod PVCs
One copy per eligible node	DaemonSet	Agents such as log collectors or CNI components
Finite work	Job	Runs to completion with retry semantics
Scheduled finite work	CronJob	Creates Jobs on a cron schedule

Labels identify and group objects. Selectors connect controllers and Services to Pods. Annotations hold non-identifying metadata. Namespaces create administrative scope, but are not by themselves a hard security boundary.

2. Scheduling and self-healing

• requests influence placement; limits constrain runtime consumption.
• nodeSelector / required affinity attracts only to matching nodes; preferred affinity expresses a soft preference.
• taints repel Pods; tolerations allow—but do not force—placement.
• pod anti-affinity and topology spread distribute replicas across failure domains.
• Controllers replace failed Pods; the kubelet restarts failed containers according to restart policy.

3. Container fundamentals

A container image is an immutable, layered OCI artifact. A registry stores and distributes images; a runtime pulls and executes them. Containers share the host kernel, unlike virtual machines with separate guest kernels. Kubernetes talks to runtimes through CRI, networks through CNI, and storage implementations through CSI.

• Image tag is mutable; a digest such as @sha256:… identifies exact content.
• ENTRYPOINT defines the executable; CMD supplies defaults. Kubernetes command and args override them.
• Init containers run sequentially before app containers. Sidecars support the main app in the same Pod and share network/volumes.
• Containers in one Pod share the network namespace and can reach each other on localhost.

4. Networking, Services and DNS

The Kubernetes network model expects every Pod to have an IP and for Pods to communicate without NAT inside the cluster. A CNI plugin realizes that model. Pod IPs are ephemeral, so a Service supplies a stable virtual IP and DNS name over a changing endpoint set.

Resource	Use
ClusterIP	Stable in-cluster access; default Service type
NodePort	Exposes a high port on each node
LoadBalancer	Requests an external load balancer from an integration/provider
Ingress / Gateway API	Layer-7 HTTP routing; requires a controller
NetworkPolicy	Controls allowed Pod ingress/egress when the CNI enforces it

kubectl get svc,endpointslices
kubectl get pods --show-labels
kubectl run dns --image=busybox:1.36 --rm -it --restart=Never -- \
  nslookup web.default.svc.cluster.local

5. Security and storage

Cloud native security is layered: cloud/infrastructure → cluster → container → code. Kubernetes authentication establishes identity, authorization decides allowed actions, and admission evaluates requests before persistence. RBAC grants verbs on resources through Roles and bindings.

• ConfigMap stores non-sensitive configuration; Secret represents sensitive data but base64 alone is not encryption.
• SecurityContext controls UID/GID, privilege escalation, Linux capabilities, read-only root filesystems and seccomp.
• Pod Security Standards define Privileged, Baseline and Restricted profiles.
• ServiceAccount is a workload identity; avoid broad permissions and unnecessary token mounting.

Storage separates request from implementation. A PVC is a workload's claim, a PV is provisioned storage, and a StorageClass defines dynamic provisioning and policy. emptyDir follows Pod lifetime; a persistent volume survives Pod replacement according to reclaim policy.

6. Cloud native application delivery

• Declarative delivery: store desired state, review changes, reconcile continuously.
• CI: build and test artifacts. CD: safely deliver them. GitOps uses Git as the reviewed desired-state source and an agent reconciles the cluster.
• Rolling update gradually replaces replicas; blue/green switches traffic between complete environments; canary sends limited traffic to a new version.
• Helm packages parameterized Kubernetes resources. Kustomize layers patches over declarative bases.

kubectl rollout status deploy/web
kubectl rollout history deploy/web
kubectl rollout undo deploy/web
kubectl logs deploy/web --all-containers
kubectl get events --sort-by=.lastTimestamp

7. Observability and cloud native architecture

Monitoring checks known conditions; observability lets you investigate unknown behavior from system outputs. The core signals are metrics, logs and traces. Prometheus collects time-series metrics, OpenTelemetry standardizes telemetry generation and transport, and tracing follows a request across services.

Principle	Meaning
Loose coupling	Components communicate through explicit contracts and fail independently
Elasticity	Capacity scales with demand
Resilience	Redundancy, recovery and bounded failure
Immutability	Replace versioned artifacts instead of patching them in place
Automation	Repeatable APIs and reconciliation replace manual snowflakes

CNCF hosts projects across orchestration, observability, networking, storage, security and delivery. Know the category and job, not every logo: Prometheus (metrics), Envoy (proxy), containerd (runtime), CoreDNS (DNS), Helm (packaging), Argo (delivery/workflows), Fluent Bit (logs), OpenTelemetry (telemetry), Cilium (networking/security), Rook (storage orchestration).

8. Troubleshooting decision tree

1. Read status and events: Pending suggests scheduling/PVC; CrashLoopBackOff suggests process/config/probe; ImagePullBackOff suggests image/auth.
2. Check desired vs actual: controller replicas, selectors, labels, resources and mounts.
3. Check logs: current container, then --previous after a restart.
4. Walk the network: Pod → EndpointSlice → Service → DNS → policy → ingress/gateway.
5. Change one layer: verify after every change instead of guessing across the stack.

9. API anatomy, lifecycle and scaling

Every Kubernetes object has apiVersion, kind, metadata and usually spec. The user declares spec; controllers and components report status. metadata.generation changes when desired state changes, while status.observedGeneration shows what the controller has processed. Finalizers delay deletion until cleanup finishes; owner references let garbage collection remove dependents.

Scaling mechanism	Signal	Changes
HPA	CPU, memory or custom/external metrics	Workload replica count
VPA	Observed resource usage	Container requests, often with Pod replacement
Cluster Autoscaler	Unschedulable Pods / underused nodes	Node count

These mechanisms solve different bottlenecks. HPA cannot help when Pods are Pending because the cluster has no capacity; Cluster Autoscaler can add nodes when the infrastructure integration supports it. Requests must be meaningful for percentage-based CPU HPA behavior.

10. CNCF community, project maturity and collaboration

Cloud native is also an open-source operating model. CNCF provides neutral governance, conformance programs, community processes and a home for projects. Project maturity—Sandbox, Incubating, Graduated—communicates governance, adoption and sustainability signals; it is not a simple feature or security ranking.

• Kubernetes conformance gives users portability expectations across conformant distributions.
• Special Interest Groups (SIGs) own Kubernetes areas; enhancement proposals document substantial changes.
• Maintainers steward projects; contributors use issues, pull requests, reviews and community meetings.
• Open standards and APIs reduce vendor lock-in, but portability still depends on storage, networking and cloud-provider integrations.
• The CNCF Landscape is a discovery map, not a recommendation to deploy one tool from every category.

11. Rapid scenario checks

• Every node needs a log agent? DaemonSet.
• Database replicas need stable names and disks? StatefulSet.
• Service has no endpoints? Selector/readiness mismatch.
• Pod is unschedulable despite idle CPU? Check requests, taints, affinity and unbound PVCs.
• Need least-privilege namespace access? Role + RoleBinding.
• Need HTTP host/path routing? Ingress or Gateway API plus its controller.
• Need exact immutable image? Pin the digest.
• Need telemetry across services? Distributed tracing, commonly instrumented with OpenTelemetry.

12. Seven-day study order

1. Day 1: architecture, API objects, reconciliation and kubectl reading.
2. Day 2: workloads, scheduling and container fundamentals.
3. Day 3: Services, DNS, CNI and NetworkPolicy.
4. Day 4: RBAC, Pod security, Secrets and storage.
5. Day 5: delivery strategies, Helm/Kustomize and GitOps.
6. Day 6: observability, CNCF project categories and architecture principles.
7. Day 7: timed scenario questions; explain why every wrong option is wrong.

Official sources & freshness

This guide was checked against the official Linux Foundation exam page and CNCF curriculum on 19 July 2026. Exam versions and policies can change; re-check the source page before booking.

• Linux Foundation — KCNA certification and current domains
• CNCF — open certification curricula
• CNCF — Kubestronaut requirements and renewal FAQ