A free, open study guide for the Kubernetes and Cloud Native Associate (KCNA) (KCNA) exam: revision notes for every domain, side-by-side comparisons of commonly confused services, a glossary, 20 worked sample questions, and the official syllabus as a checklist with a full free lesson for every topic.
Maintained by SaveMyCert, where you can read every lesson free, practice with explained questions and take timed mock exams.
- Exam at a glance
- Exam domains
- What is in this repo
- Syllabus checklist
- How to study for KCNA
- Sample questions
- Free resources
| Exam code | KCNA |
| Level | Foundational |
| Questions | 60 |
| Time limit | 90 min |
| Passing score | 75% |
| Format | Multiple choice |
| Exam fee | $250 |
| Valid for | 2 years |
Exam details change. Always confirm them in the official KCNA certification page and curriculum from The Linux Foundation.
| # | Domain | Weight | Topics |
|---|---|---|---|
| 1 | Kubernetes Fundamentals | 44% | 4 |
| 2 | Container Orchestration | 28% | 4 |
| 3 | Cloud Native Application Delivery | 16% | 2 |
| 4 | Cloud Native Architecture | 12% | 3 |
That is 4 domains and 13 topics. Spend your time in proportion to the weights: the heaviest domain decides more of your score than the lightest.
| File | What it gives you |
|---|---|
| Domain 1 notes | Kubernetes Fundamentals: condensed revision notes per topic |
| Domain 2 notes | Container Orchestration: condensed revision notes per topic |
| Domain 3 notes | Cloud Native Application Delivery: condensed revision notes per topic |
| Domain 4 notes | Cloud Native Architecture: condensed revision notes per topic |
| Commonly confused services | Side-by-side tables of the services questions set against each other |
| Glossary | Every in-scope term and service in one sentence |
| Sample questions | 20 worked questions with answers and reasoning |
| Exam-day guide | Booking, testing options, scoring, results and retakes |
Tick each topic off once you can explain it without notes. The "Must know" facts are the ones questions turn on. Each lesson link goes to the complete, free lesson.
Weight: 44%. The Kubernetes object model, cluster administration, scheduling, and containerization. Official weighting 44%.
📝 Revision notes: Domain 1: Kubernetes Fundamentals
- Kubernetes Core Concepts
The Kubernetes architecture and object model: control plane vs worker nodes, the API server and etcd, controllers and desired-state reconciliation, and the core resources (Pods, ReplicaSets, Deployments, Services, namespaces) with declarative configuration.- 📖 Lesson: Kubernetes Core Concepts: Architecture, Pods, Deployments, and Services
- Must know: A Pod is the smallest deployable unit; its containers share one network namespace (one IP) and can share volumes such as an emptyDir.
- Must know: The kube-apiserver is the front door: kubectl, the kubelet, and all controllers talk to the cluster only through it.
- Administration
Managing a Kubernetes cluster: kubectl and the API, the cluster components (kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy), role-based access control (RBAC) basics, namespaces, and resource quotas.- 📖 Lesson: Kubernetes Administration: kubectl, RBAC, Namespaces, and Resource Quotas
- Must know: Every kubectl command is a request to the kube-apiserver; for logs and exec the API server relays to the kubelet on the Pod's node (port 10250), so a blocked path to one kubelet breaks only those commands.
- Must know: kubectl config use-context rewrites current-context in the kubeconfig file and switches cluster, user, and namespace together.
- Scheduling
How the scheduler places Pods onto nodes: resource requests and limits, node selectors, affinity and anti-affinity, taints and tolerations, and scheduling constraints.- 📖 Lesson: Kubernetes Scheduling: Requests, Node Affinity, Taints and Tolerations
- Must know: The kube-scheduler filters out infeasible nodes, sums weighted plugin scores for the rest, and binds the Pod to the winner; setting spec.nodeName bypasses it entirely.
- Must know: Requests drive scheduling and are compared with allocatable minus already-requested capacity; limits are enforced at runtime and play no part in placement.
- Containerization
Container fundamentals underpinning Kubernetes: images and registries, container runtimes and the Container Runtime Interface (CRI), Open Container Initiative (OCI) standards, and building and running containers.- 📖 Lesson: Containerization: Images, Container Runtimes, CRI and the OCI Explained
- Must know: A container is an isolated process on a shared host kernel: namespaces control what it sees, cgroups control what it uses, seccomp and AppArmor control what it may do.
- Must know: Containers virtualize the operating system; VMs virtualize the hardware. A base image supplies user-space files only, never a kernel.
Weight: 28%. Networking, security, troubleshooting, and storage for orchestrated workloads. Official weighting 28%.
📝 Revision notes: Domain 2: Container Orchestration
- Networking
The Kubernetes networking model: Pod-to-Pod networking, Services and kube-proxy, cluster DNS, the Container Network Interface (CNI), Ingress, and network policies.- 📖 Lesson: Kubernetes Networking: Services, kube-proxy, CNI, DNS, and Ingress
- Must know: Every Pod gets its own IP address, and Pods reach each other across nodes without NAT and without a Service; that flat model is implemented by the CNI plugin, and kubeadm leaves nodes NotReady until you install one.
- Must know: A Service provides a stable virtual IP and DNS name in front of ephemeral Pods; any running Pod whose labels match becomes an endpoint, whichever controller created it, and a Pod without a readiness probe counts as ready once running.
- Security
Cloud-native and Kubernetes security basics: the 4Cs of cloud-native security, RBAC and service accounts, Secrets, and the container, network, and policy security surface.- 📖 Lesson: Kubernetes Security: The 4Cs, RBAC, Secrets, and Pod Security Admission
- Must know: The 4Cs are Cloud, Cluster, Container, Code, outermost to innermost: nested layers of defense in depth where a weakness in an outer layer undermines the inner ones.
- Must know: RBAC is additive and allow-only; a RoleBinding can reference a Role in its own namespace or a ClusterRole, granting its rules only in that namespace, while a ClusterRoleBinding grants cluster-wide.
- Troubleshooting
Diagnosing workloads and clusters: reading Pod status and events, kubectl logs / describe / exec, and identifying common failure modes across Pods, Services, and nodes.- 📖 Lesson: Troubleshooting Kubernetes: Pod Status, Events, Logs, and Probes
- Must know: The five Pod phases are Pending, Running, Succeeded, Failed, and Unknown; containers have their own states (Waiting, Running, Terminated), and kubectl shows a Succeeded Pod as Completed.
- Must know: Images are pulled by the kubelet only after the Pod is bound to a node; imagePullPolicy Always contacts the registry on every container start, IfNotPresent uses a cached copy, and Never fails with ErrImageNeverPull when the image is absent.
- Storage
Kubernetes storage: Volumes, PersistentVolumes and PersistentVolumeClaims, StorageClasses and dynamic provisioning, and the Container Storage Interface (CSI).- 📖 Lesson: Kubernetes Storage: Volumes, PersistentVolumes, PVCs, and CSI
- Must know: A Volume is declared once in spec.volumes and is visible only to containers that mount it via their own volumeMounts; emptyDir survives container restarts but not Pod deletion.
- Must know: Secrets are the object for sensitive values (own RBAC, optional encryption at rest, tmpfs-backed volumes), but their data is only base64-encoded by default; ConfigMap and Secret keys can also be consumed as environment variables.
Weight: 16%. Delivering and debugging applications on cloud-native platforms. Official weighting 16%.
📝 Revision notes: Domain 3: Cloud Native Application Delivery
- Application Delivery
Delivering applications on Kubernetes: deployment strategies and rollouts, GitOps and CI/CD fundamentals, package management with Helm, and the application definition and image-build landscape.- 📖 Lesson: Cloud Native Application Delivery: GitOps, Helm, and Deployment Strategies
- Must know: RollingUpdate is the default Deployment strategy; no RollingUpdate setting guarantees old and new versions never overlap, so only Recreate does - at the cost of downtime
- Must know: maxSurge sets the ceiling (replicas + surge, percentages round up) and maxUnavailable the floor (replicas - unavailable, percentages round down); both cannot be 0, and on a full cluster use maxSurge 0
- Debugging
Debugging application delivery: inspecting Deployments and rollouts, diagnosing failed releases, and using observability signals during delivery.- 📖 Lesson: Debugging Application Delivery: Stuck Rollouts, Failed Releases, and Rollbacks
- Must know: A rolling update only progresses as new Pods become available; a bad release stalls while the old ReplicaSet keeps serving
- Must know: maxSurge and maxUnavailable default to 25% (surge rounds up, unavailable rounds down), so a broken 4-replica rollout freezes at 3 old + 2 new Pods
Weight: 12%. Observability, cloud-native principles and the CNCF ecosystem, and community collaboration. Official weighting 12%.
📝 Revision notes: Domain 4: Cloud Native Architecture
- Observability
Observability pillars — metrics, logs, and traces; Prometheus and the observability tooling landscape; and cost and performance monitoring.- 📖 Lesson: Observability in Cloud Native: Metrics, Logs, and Traces
- Must know: Metrics measure trends over time, logs record discrete events, traces follow one request across services; Kubernetes Events record what the cluster did to objects and expire after about an hour.
- Must know: Prometheus pulls metrics by scraping HTTP endpoints, keeps 15 days of local history by default, and is queried with PromQL; short-lived batch jobs push to a Pushgateway that Prometheus scrapes.
- Cloud Native Ecosystem and Principles
Cloud-native principles (autoscaling, serverless, microservices, immutability, declarative APIs) and the CNCF project and ecosystem landscape.- 📖 Lesson: Cloud Native Principles and the CNCF Ecosystem
- Must know: The CNCF definition names five techniques: containers, service meshes, microservices, immutable infrastructure, and declarative APIs. GitOps and serverless are popular practices, not among the five.
- Must know: Cloud native systems aim to be loosely coupled, resilient, manageable, and observable, with change driven by automation.
- Cloud Native Community and Collaboration
How the cloud-native community works: CNCF project maturity levels (Sandbox, Incubating, Graduated), governance, open-source collaboration, and the roles and personas in the ecosystem.- 📖 Lesson: CNCF Community, Project Maturity Levels, and Open Source Governance
- Must know: 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 and first to graduate.
- Must know: CNCF projects climb three maturity levels in order: Sandbox, Incubating, Graduated. Archived is a status for inactive projects, not a fourth level.
- Read the lesson for each topic in the checklist above, starting with the heaviest domain. Every lesson is free on the KCNA revision notes.
- Practice straight after reading. Answer KCNA practice questions on the topic you just read. Each option comes with an explanation of why it is right or wrong.
- Review what you got wrong, re-read that lesson section, and tick the topic off only when you get its questions right.
- Take a full-length KCNA mock exam under the real time limit. Aim to pass mocks comfortably before you book.
- On the last day, skim the KCNA cheat sheet instead of starting anything new.
sample-questions.md has 20 worked KCNA questions with the answer, why each option is right or wrong, and the reasoning steps.
- KCNA certification page and curriculum: the official source (The Linux Foundation)
- KCNA certification overview
- KCNA revision notes: every lesson, free to read
- KCNA practice questions: with an explanation on every option
- KCNA mock exams: full-length and timed
- KCNA cheat sheet: the key facts on one page
- All certification study guides
Spotted an error or an out-of-date fact? Open an issue with the topic and a link to the official source. See CONTRIBUTING.md.
This guide is licensed under CC BY 4.0. You can reuse and adapt it, including commercially, as long as you credit SaveMyCert with a link to https://www.savemycert.com/.
This is an independent study resource. It is not affiliated with or endorsed by The Linux Foundation. Kubernetes and Cloud Native Associate (KCNA) and KCNA are trademarks of their respective owner. Exam domains and weights are taken from the official exam guide linked above.