KCNA: Kubernetes and Cloud Native Associate Study Guide
The Kubernetes and Cloud Native Associate (KCNA) is an entry-level, multiple-choice exam from the CNCF that validates foundational knowledge of Kubernetes and the broader cloud native ecosystem. It covers core Kubernetes architecture, container orchestration, cloud native design principles, observability, and application delivery. It is aimed at engineers, students, and IT staff who are new to cloud native and want a credential before pursuing hands-on certifications like the CKA or CKAD.
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.
- 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.
- 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.
- A service mesh (e.g., Istio, Linkerd) injects sidecar proxies like Envoy into Pods to provide transparent traffic management, observability, and mTLS between services.
- If a Service's selector matches no running/ready Pods it has no endpoints, so connections fail because there is nothing to load-balance to.
- 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.
- A DaemonSet runs one Pod per node (or per matching node); to schedule onto tainted nodes its Pod template must include a matching toleration.
- Containers that must share a network or filesystem (e.g., a sidecar) should be placed in the same Pod rather than separate Pods.
- A StatefulSet provides stable, ordered Pod names and per-Pod persistent storage for stateful workloads, unlike a Deployment whose Pods are interchangeable.
- The cluster orchestrates automated scaling, rollouts, and self-healing (restarting or rescheduling failed Pods) to keep workloads at desired state.
- Rollout management commands: 'kubectl rollout restart deployment/<name>', 'kubectl rollout undo deployment/<name>', and 'kubectl set image deployment/<name> <container>=<image>'.
Domain 3: 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.
- A container image is an immutable, packaged artifact bundling an application with its dependencies; a container registry (e.g., Docker Hub, Harbor) stores and distributes those images.
- Cloud native principles include declarative APIs with desired-state reconciliation and immutable infrastructure (replace components rather than modifying them in place).
- The HorizontalPodAutoscaler (HPA) adjusts a workload's replica count based on observed metrics such as CPU utilization, memory, or custom metrics, against a configured target.
- The Cluster Autoscaler adds nodes when Pods cannot be scheduled due to insufficient capacity and removes underutilized nodes, scaling the cluster size to match demand.
- Serverless means running code without managing servers and often scaling to zero when idle; examples include Knative and FaaS platforms like AWS Lambda.
- KEDA (Kubernetes Event-Driven Autoscaling) scales workloads - including to zero - based on event sources such as queue depth, message counts, or custom metrics.
- RBAC controls which users or ServiceAccounts can perform which verbs (get, list, create, etc.) on which resources; a Role/RoleBinding is namespaced while a ClusterRole/ClusterRoleBinding is cluster-wide.
- 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.
- Microservices enable independent deployment and scaling of services at the cost of added network and operational complexity compared with a monolith.
- Stateless apps scale horizontally behind a Service and keep session or state in an external store (cache or database) rather than in Pod memory, so any replica can serve any request.
- Admission control policy engines such as OPA Gatekeeper and Kyverno enforce governance rules (e.g., required labels, banned images) on objects before they are persisted.
- Useful RBAC commands: 'kubectl create role', 'kubectl create rolebinding', and 'kubectl auth can-i <verb> <resource>' to test whether an identity is authorized.
Domain 4: Cloud Native Observability
- 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 HTTP endpoint of each target and storing time-series data queried with PromQL.
- A Prometheus time series is uniquely identified by its metric name together with its set of key/value labels; its local storage is not designed for long-term, highly available retention without remote write.
- OpenTelemetry (OTel) is a vendor-neutral CNCF project (merging OpenCensus and OpenTracing) providing APIs, SDKs, and a collector to generate and export traces, metrics, and logs to backends like Jaeger or Prometheus.
- Jaeger is a distributed tracing backend used to visualize how a request flows across services; tracing relies on context propagation between services.
- A liveness probe detects an unrecoverable state (e.g., deadlock); on failure the kubelet kills and restarts the container per the Pod's restartPolicy.
- A readiness probe gates whether a Pod is in a Service's endpoints; on failure the Pod is removed from endpoints (no new traffic) but is not restarted.
- A startupProbe protects slow-starting containers by disabling liveness and readiness checks until startup succeeds, preventing premature restarts.
- A liveness probe configured too aggressively for a slow start can fail during startup, causing the kubelet to restart the container repeatedly in a crash loop before the app is ever ready.
- Metrics Server collects resource usage and powers 'kubectl top' and CPU/memory-based HPA decisions; it is not a long-term metrics store.
- If Pods have no CPU requests set, the HPA cannot compute a utilization percentage and cannot scale on CPU; requests must be defined.
- Container logs should be written to stdout/stderr where node-level agents collect them; node-local log files are rotated and lost when a Pod is deleted or a node is replaced unless shipped to a central backend.
- Use an HPA driven by metrics to scale on load - never rely on liveness probes to trigger scaling, since probes only restart containers.
- Good alerting practice is to alert on user-impacting symptoms (SLO violations) and make every alert actionable with clear ownership, rather than alerting on every low-level cause.
Domain 5: 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 a sealed-secrets or 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.
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.
- Memorize the control-plane components (kube-apiserver, etcd, kube-scheduler, kube-controller-manager) versus node components (kubelet, kube-proxy, container runtime) and exactly what each one does.
- 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.
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 five 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.
How long is the KCNA certification valid?
The KCNA certification is valid for two years from the date you pass. Your exam registration also includes one free retake if you do not pass on the first attempt.