Domain 1: Kubernetes Fundamentals
- A Pod is the smallest deployable unit in Kubernetes; Kubernetes manages Pods, not individual containers, and containers in a Pod share the same network namespace (IP) and can share storage volumes.
- etcd is a distributed, highly available key-value store that holds all cluster state - every Deployment, Service, ConfigMap, Secret, and other object is persisted there.
- The kube-apiserver is the front end of the control plane and the single entry point all users and components use to read and write cluster state.
- The kube-scheduler watches for newly created Pods with no assigned node and selects a node based on resource requests, taints/tolerations, affinity, and other constraints.
- The kube-controller-manager runs reconciliation control loops (e.g., the Deployment, ReplicaSet, and Node controllers) that drive actual state toward the declared desired state.
- The kubelet is the per-node agent that reads PodSpecs from the API server and ensures the described containers are running and healthy on that node.
- Kubernetes is declarative: you describe the desired state in manifests and controllers continuously reconcile the actual state to match it, rather than running imperative steps.
- The Container Runtime Interface (CRI) is the standard API between the kubelet and the container runtime; compliant runtimes include containerd and CRI-O (Docker is no longer used directly).
- A node is a worker machine (VM or physical) managed by the control plane that runs Pods via its kubelet, container runtime, and kube-proxy.
- Namespaces provide a logical partition for grouping and isolating resources (and applying quotas/RBAC) within a single cluster; they do not isolate nodes.
- A ReplicaSet (usually managed by a Deployment) ensures a specified number of identical Pod replicas are running at all times; a Deployment adds rollout and rollback on top.
- ConfigMaps store non-confidential configuration data, while Secrets hold sensitive data that is only base64-encoded by default (not encrypted unless encryption-at-rest is enabled on etcd).
- Labels are key/value metadata used to select and group objects (e.g., a Service's selector matches Pods by label); annotations hold non-identifying metadata.
- The three health probes differ: a liveness probe restarts a stuck container, a readiness probe gates whether a Pod receives Service traffic, and a startup probe protects slow-starting containers until they are up.
- Common kubectl commands: 'kubectl get/describe' to inspect resources, 'kubectl logs' to view container logs, 'kubectl apply -f' to create/update from manifests, and 'kubectl exec -it' to run commands inside a container.
Domain 2: Container Orchestration
- The Container Network Interface (CNI) is a CNCF spec defining a plugin interface for pod networking; the kubelet calls the CNI plugin to set up a Pod's network namespace and assign its IP.
- The Container Storage Interface (CSI) is a gRPC-based standard letting third-party storage vendors integrate with Kubernetes (dynamic provisioning, attach, mount, delete) without changing core code.
- A Service gives a stable network identity - a ClusterIP virtual IP and DNS name - and load-balances traffic across the Pods selected by its label selector (a plain key/value map under spec.selector).
- kube-proxy runs on each node, watches Service and EndpointSlice changes, and programs iptables or IPVS rules to forward Service traffic to backing Pods.
- Service types: ClusterIP (internal only, default), NodePort (exposes a port on every node), and LoadBalancer (provisions an external cloud load balancer); 'kubectl expose' creates a Service.
- An Ingress defines host/path-based HTTP/HTTPS routing into cluster Services but does nothing without a running ingress controller (e.g., NGINX) to fulfill its rules.
- NetworkPolicies are default-allow: all ingress and egress traffic is permitted until a policy selects a Pod; best practice is a default-deny policy plus explicit allow rules.
- RBAC controls which users or ServiceAccounts can perform which verbs (get, list, create) on which resources; a Role/RoleBinding is namespaced while a ClusterRole/ClusterRoleBinding is cluster-wide.
- Authentication, then authorization (RBAC), then admission control is the order every API request passes through before an object is persisted.
- A PersistentVolume (PV) is a piece of cluster storage; a PersistentVolumeClaim (PVC) requests it, and a StorageClass enables dynamic provisioning so a PV is created on demand.
- Access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) and reclaim policies (Retain vs Delete) govern how volumes are mounted and what happens to data when a claim is released.
- Troubleshooting relies on 'kubectl describe' and events plus Pod states: ImagePullBackOff (bad image/credentials), CrashLoopBackOff (container keeps exiting), OOMKilled (over memory limit), and Pending (unschedulable).
- A DaemonSet runs one Pod per node; a StatefulSet gives stable, ordered Pod identity and per-Pod storage for stateful workloads, unlike interchangeable Deployment Pods.
- The cluster orchestrates automated scaling, rollouts, and self-healing (restarting or rescheduling failed Pods) to keep workloads at desired state.
Domain 3: Cloud Native Application Delivery
- Helm is the Kubernetes package manager; a chart bundles templated manifests with metadata and a default values file, and charts are versioned, installable, upgradable, and rollback-able.
- Helm commands: 'helm install <name> ./chart' to install, 'helm upgrade --install <name> ./chart' to install-or-upgrade idempotently, and 'helm rollback <name> <revision>' to revert a release.
- Kustomize is a template-free customization tool (built into kubectl) that uses a kustomization.yaml to layer overlays and strategic-merge/JSON patches over base manifests per environment.
- GitOps treats Git as the single source of truth for desired state, and a reconciling agent continuously syncs the live cluster to match the repo, providing audit trails and pull-request-based changes.
- Argo CD and Flux are the leading CNCF GitOps continuous-delivery tools; if someone changes the cluster manually, the agent reverts it back to the state declared in Git.
- RollingUpdate is the default Deployment strategy: it incrementally replaces old Pods with new ones, gated by maxSurge (extra Pods allowed) and maxUnavailable (Pods that can be down) for little or no downtime.
- The Recreate strategy terminates all old Pods before creating new ones, causing downtime but guaranteeing that two versions never run simultaneously.
- Blue-green deployment runs the new version alongside the old and switches traffic at cutover; it requires roughly double the resources during the switch.
- Canary deployment routes a small percentage of traffic to the new version first to limit blast radius, then promotes or rolls back based on metrics and traffic-splitting.
- A rolling update can stall if a surge Pod cannot be scheduled (insufficient resources) while maxUnavailable prevents removing an old Pod first, leaving the rollout stuck.
- Roll back a bad Deployment with 'kubectl rollout undo deployment/<name>'; validate manifests before applying with 'kubectl apply -f app.yaml --dry-run=server'.
- Per the Twelve-Factor App methodology, store configuration in the environment (not in code) and treat backing services like databases as attached, swappable resources.
- Inject sensitive values via Secrets - ideally managed by sealed-secrets or an external secrets manager - and reference them at runtime rather than baking them into images.
- Manifests are applied as declarative YAML/JSON (often templated by Helm or generated by Kustomize) using 'kubectl apply' or pulled in by a GitOps agent.
Domain 4: Cloud Native Architecture
- The CNCF (Cloud Native Computing Foundation) is a Linux Foundation project that hosts cloud native projects (Kubernetes, Prometheus, Envoy) and tracks them through Sandbox, Incubating, and Graduated maturity levels.
- The Open Container Initiative (OCI) standardizes the container image format and runtime behavior so images built by any tool (Docker, Podman, Buildah) run on any compliant runtime.
- Cloud native principles include declarative APIs with desired-state reconciliation and immutable infrastructure (replace components rather than modifying them in place).
- Microservices enable independent deployment and scaling of services at the cost of added network and operational complexity compared with a monolith; stateless apps keep state in an external store so any replica can serve any request.
- Custom Resource Definitions (CRDs) extend the Kubernetes API with new resource types, and the Operator pattern pairs a CRD with a custom controller to automate day-2 operations.
- The HorizontalPodAutoscaler (HPA) adjusts a workload's replica count based on observed metrics such as CPU utilization; the Cluster Autoscaler adds or removes nodes so unschedulable Pods can run and idle nodes are reclaimed.
- Serverless means running code without managing servers and often scaling to zero when idle; Knative provides serverless workloads on Kubernetes and KEDA drives event-driven autoscaling (including to zero).
- The three pillars of observability are logs (discrete timestamped events), metrics (numeric time series like request rate and latency), and traces (the path of a request across services).
- Prometheus is the CNCF de facto standard for metrics; it uses a pull model, scraping the /metrics endpoint of each target and storing time series queried with PromQL, where each series is identified by its name plus labels.
- OpenTelemetry (OTel) is a vendor-neutral CNCF project providing APIs, SDKs, and a collector to generate and export traces, metrics, and logs to backends such as Jaeger or Prometheus.
- Jaeger is a distributed tracing backend that visualizes how a request flows across services and relies on context propagation between them.
- Metrics Server collects resource usage and powers 'kubectl top' and CPU/memory-based HPA decisions; it is not a long-term metrics store.
- Container logs should be written to stdout/stderr where node-level agents collect and ship them centrally; node-local log files are rotated and lost when a Pod or node is replaced.
- Good alerting practice is to alert on user-impacting symptoms (SLO violations) with clear ownership and actionability, rather than alerting on every low-level cause; the CNCF community governs projects through open, collaborative processes.
KCNA exam tips
- KCNA is multiple choice with no hands-on tasks, but you should still recognize what common kubectl, helm, and probe configurations do - study commands and their effects, not just definitions.
- Kubernetes Fundamentals is by far the largest domain (44%) - prioritize core objects, cluster architecture (control-plane vs node components), scheduling, and containerization there.
- Know the CNCF project landscape and what each tool is for: Prometheus (metrics), Jaeger/OpenTelemetry (tracing), Argo CD/Flux (GitOps), Helm (packaging), Envoy/Istio/Linkerd (service mesh), KEDA/Knative (event-driven/serverless).
- Be precise about the three health probes: liveness restarts a container, readiness removes it from Service endpoints without restarting, and startup gates the other two during slow boots.
- Watch for cloud native principles wording - declarative desired-state reconciliation, immutable infrastructure, and standard interfaces (CRI, CNI, CSI, OCI) are recurring exam themes.
Study guide FAQ
How is the KCNA exam structured and scored?
KCNA is a 90-minute, online proctored, multiple-choice exam (typically around 60 questions). It is scored out of 1000 with a passing score of 750. Unlike the CKA/CKAD/CKS, it is not a hands-on lab exam.
What are the KCNA exam domains and their weights?
The current KCNA has four domains: Kubernetes Fundamentals (44%), Container Orchestration (28%), Cloud Native Application Delivery (16%), and Cloud Native Architecture (12%). Observability, cloud native principles, and community/governance topics sit within the Cloud Native Architecture domain.
Do I need hands-on Kubernetes experience to pass KCNA?
No deep hands-on experience is required, since the exam is multiple choice. However, you should understand what core kubectl, helm, and YAML configurations do conceptually, so practicing with a local cluster (minikube, kind) or a free playground greatly helps with retention.
What's the difference between KCNA and the CKA?
KCNA is an associate-level, knowledge-based exam covering broad cloud native concepts across four domains. The CKA (Certified Kubernetes Administrator) is a performance-based, hands-on exam where you operate a real cluster from the command line. KCNA is a good stepping stone before tackling the CKA, CKAD, or CKS.