RoleMath Study Track for Certified Kubernetes Administrator (CKA) (CKA)
A free study companion keyed to the officially published exam domains of Certified Kubernetes Administrator (CKA) (CKA): what each domain covers in plain language, clearly labeled free resources, a guided lab outline for every domain, and interactive self-checks from our own question bank. CNCF CKA exam curriculum + Linux Foundation exam page
A free, source-cited study companion built on the CNCF's published Certified Kubernetes Administrator (CKA) curriculum and the official Linux Foundation exam page — not official training, not a pass guarantee. CKA is a performance-based, entirely hands-on exam: you solve real tasks at the command line in a live Kubernetes cluster, so speed with kubectl and imperative commands matters as much as knowing the concepts. Every hands-on lab here runs only on a local kind cluster you create and own; verify the current curriculum version on the official page before your exam.
A complete free Certified Kubernetes Administrator (CKA) program pinned to the CNCF's currently published curriculum (targeting Kubernetes v1.35, last revised 2025-02-18), sequenced the way the concepts build rather than in numeric order — the cluster-architecture spine first, then workloads and storage, then services and networking, with troubleshooting practiced continuously as a running thread because it is the single heaviest domain at 30% — and every hands-on lab run on a local kind (Kubernetes-in-Docker) or minikube cluster you create and own, verifying your kubectl context before every command and deleting the cluster when finished. Because CKA is a performance-based, entirely hands-on exam that gives you roughly seven minutes per task, this program treats imperative-kubectl speed as a first-class skill. This is not a first cert: it assumes Linux command-line fluency, container/Docker basics, and comfort with YAML, and it rechecks the official curriculum before any exam scheduling. It does not predict a score, confer experience, or serve as a credential.
This draft exposes RoleMath’s authored sequence and evidence plan. The current labs are guided outlines, not yet a fully fixture-backed course, and objective-leaf coverage has not passed the gold-standard gate. Completion does not predict an exam result.
Modules
5
Labs
5
Concept checks
10
Resource mix
5 official / 0 community
Choose an outcome
Three routes through the same evidence
Choose provisionally. Change routes when the work tells you something new about fit, time, or readiness.
Certification-focused
Administrators and experienced practitioners who already have Linux command-line fluency, container/Docker basics, and YAML comfort and want one current, dependency-ordered CKA sequence across all five domains, with every lab run on a local kind or minikube cluster they own and a recheck of the official curriculum before scheduling.
Completion emphasis: Complete every phase, run each lab only on a local cluster you own (with the kubectl context verified before every command and the cluster deleted afterward), correct every missed check, drill imperative kubectl until you are fast enough for a seven-minute-per-task exam, finish the integrated timed capstone on your own cluster, and diff the current curriculum before booking the exam — never inferring a score from coverage.
Required phases: Cluster architecture foundation: the control-plane model, RBAC, and a cluster you own, Workloads, scheduling, and durable storage, Services, DNS, Ingress, and NetworkPolicy, Troubleshooting mastery, kubectl speed, and the integrated timed capstone
Admin skills first
Career changers with prior IT, Linux, or DevOps experience who want reviewable evidence that they can stand up RBAC, deploy and scale workloads, give a pod durable storage, wire up and protect Services, and diagnose a broken cluster against the clock on a cluster they own, whether or not they sit the exam soon.
Completion emphasis: Retain a labeled command transcript plus the YAML manifests for each domain — a verified least-privilege RBAC setup, a rollout-and-rollback plus scheduling record, a bound-PVC durability proof, a Service/DNS/NetworkPolicy record, and a root-cause-and-fix note for a set of broken workloads — plus the capstone transcript and a note confirming every kind cluster was deleted.
Required phases: Cluster architecture foundation: the control-plane model, RBAC, and a cluster you own, Workloads, scheduling, and durable storage, Services, DNS, Ingress, and NetworkPolicy, Troubleshooting mastery, kubectl speed, and the integrated timed capstone
Career-fit sprint
Learners deciding whether Kubernetes administration — the control-plane mental model, the imperative-kubectl command work, and the against-the-clock troubleshooting of a performance-based exam — is a direction worth deeper investment before committing to the full CKA grind, given that it is an administrator-level exam and not a first cert.
Completion emphasis: Complete the diagnostic and the cluster-architecture foundation phase with its RBAC lab on a local cluster you own, sample the workloads work, then choose a next Kubernetes experiment or a full exam commitment rather than inferring job readiness or a pass from partial coverage.
Required phases: Cluster architecture foundation: the control-plane model, RBAC, and a cluster you own
Start safely
Prerequisite diagnostic
Confirm you meet the not-a-first-cert bar and can run a local Kubernetes cluster before the CKA labs; this diagnostic is not a Linux Foundation prerequisite, a cost promise, or an exam prediction, and CKA is a performance-based administrator-level exam that assumes Linux, container, and YAML fluency rather than teaching them.
Are you comfortable working in a Linux command line — navigating the filesystem, running tools, reading output, editing text, and using pipes and redirection — since every CKA task and lab is command-line first and the exam is entirely hands-on?
Ready when: Yes, or you will practice Linux CLI fundamentals in parallel while using each lab's documented commands, because the whole exam is typed kubectl at a terminal under time pressure.
If not yet: Build basic Linux CLI fluency first (a free Linux fundamentals resource or the Linux+ track), because every CKA lab and the exam itself assume it and CKA does not re-teach it.
Do you already understand containers and basic Docker — what an image is, how a container runs, and how to pull and run one — since Kubernetes orchestrates containers and kind runs Kubernetes inside Docker?
Ready when: Yes, or you will review container and Docker basics before the first lab, because kind (Kubernetes-in-Docker) and every workload you deploy assume the container mental model.
If not yet: Spend time on container and Docker fundamentals first; without them the CKA object model and the kind lab environment will not make sense.
Are you comfortable reading and writing YAML — indentation, key/value structure, and lists — since every Kubernetes object is declared in YAML and you will read, edit, and generate manifests throughout?
Ready when: Yes, or you will lean on imperative kubectl with --dry-run=client -o yaml to generate manifests while you build YAML comfort, which is a good exam habit anyway.
If not yet: Practice basic YAML (a short YAML primer) before the labs, because misindented YAML is a common and time-wasting source of failure on a timed exam.
Can you install and run Docker plus kind (or minikube) and kubectl on your own machine — with enough RAM and disk for a single- or multi-node local cluster — or will you use a browser-based alternative instead?
Ready when: Yes, with Docker running and kind/minikube plus kubectl installed and on your PATH, or a plan to use the free killercoda CKA scenarios in a browser when local install is impractical.
If not yet: Start on the free killercoda browser scenarios (no local install) while you sort out a local Docker + kind setup, since they reach the same hands-on outcomes and evidence.
Have you chosen a pace whose weekly hours you can realistically protect across roughly 100 to 200 total hours depending on your prior Kubernetes, Linux, and container experience?
Ready when: Yes, with a pace selected and the imperative-kubectl speed drills, the continuous troubleshooting practice, and the timed capstone left uncompressed.
If not yet: Pick the steady pace if you are newer to containers and reserve the intensive pace for learners already fluent in Linux and Docker; never compress the hands-on labs or the timed capstone to save time, because the exam is entirely hands-on.
Plan, then adapt
Pace options
Steady
12 weeks 8-10 hours/week
A planning estimate of roughly 100-120 hours for a learner who already has Linux command-line fluency and container/Docker basics: one phase at a time, every lab run only on a local kind or minikube cluster you own with the kubectl context verified and the cluster deleted afterward, plus continuous troubleshooting practice, the timed capstone, and a curriculum recheck before scheduling. A beginner still building Docker and Linux fluency should expect closer to 150-200 hours and start with the steady pace.
Standard
8 weeks 10-12 hours/week
A planning estimate for learners with some hands-on Kubernetes or DevOps exposure that pairs the CNCF-cited domain study with one retained command transcript and manifest set per domain, builds imperative-kubectl speed for a seven-minute-per-task exam, and preserves the continuous troubleshooting thread, the missed-check corrections, and a curriculum-diff block before any exam logistics.
Intensive
6 weeks 14-16 hours/week
Roughly 100-140 hours for an experienced learner already fluent in Linux, Docker, and YAML and possibly working with Kubernetes day to day; do not compress the imperative-kubectl speed drills, the continuous break-it-then-fix-it troubleshooting practice, the RBAC and NetworkPolicy verification, or the kubeadm install/upgrade and full etcd save/restore work that needs a real-node scenario platform such as killercoda or killer.sh rather than a single-node kind cluster.
Evidence-gated sequence
Program roadmap
1
Cluster architecture foundation: the control-plane model, RBAC, and a cluster you own
Build the conceptual spine everything else hangs on (Domain 4, Cluster Architecture, Installation & Configuration, 25%): how the control-plane components (API server, scheduler, controller-manager, etcd) and the kubelet fit together, how the cluster is stood up and kept healthy with kubeadm, and how RBAC decides who can do what — then prove it hands-on by standing up a kind cluster you own, building and verifying a least-privilege RBAC setup with kubectl auth can-i, walking the etcd snapshot drill, and routing kubeadm install/upgrade to a real-node scenario platform kind cannot host.
Complete the diagnostic (Linux CLI, container/Docker, YAML, run-Docker-and-kind-locally, and study-time), choose a pace you can protect, and stand up a local kind or minikube cluster you own — verifying kubectl config current-context points at your own throwaway cluster before touching anything.
Complete the Domain 4 RBAC lab on your own cluster: apply the namespace, ServiceAccount, least-privilege Role, and RoleBinding, then verify with kubectl auth can-i that the ServiceAccount can read pods but cannot delete them, and be able to explain the Role vs ClusterRole and binding model.
Walk the etcd snapshot save/status drill, state why its live endpoints need a real control-plane node, and identify killercoda and the two killer.sh sessions (bundled with exam registration) as where you practice kubeadm init/join/upgrade and the full etcd save/restore that a single-node kind cluster cannot host.
Attempt every authored Cluster Architecture check and correct each miss against its cited source before moving to workloads, then delete the kind cluster so nothing persists.
2
Workloads, scheduling, and durable storage
Learn to run, update, scale, place, and give durable storage to applications — the objects you manipulate in almost every task. First take Workloads & Scheduling (Domain 3, 15%): Deployments and rollouts, ConfigMaps and Secrets, scaling and self-healing, and the scheduler's placement controls (requests/limits, taints/tolerations, nodeSelector/affinity), practiced imperatively so the exam clock does not beat you. Then take Storage (Domain 1, 10%): the PersistentVolume/PersistentVolumeClaim object model, StorageClasses and dynamic provisioning, access modes, and reclaim policies — a self-contained slice that builds cleanly on the workloads you just deployed.
Complete the Domain 3 workloads lab on a multi-node kind cluster you own: perform a rolling update and a kubectl rollout undo imperatively, apply resource requests and limits, place a pod onto a tainted node via a toleration and another onto a labeled node via nodeSelector, and create a HorizontalPodAutoscaler after installing metrics-server.
Complete the Domain 1 storage lab on a cluster you own: apply the storage fixture, watch the PVC move from Pending to Bound, read a written file back out of the mounted volume, inspect the bound PV's reclaim policy and access modes, and prove the storage outlives the pod by deleting the pod while the PVC stays Bound.
Retain a rollout/rollback-and-scheduling command transcript with its manifests and a bound-PVC durability proof, both produced only on a local cluster you own with the kubectl context verified before every command and the cluster deleted afterward.
Attempt every authored Workloads & Scheduling and Storage check and correct each miss against its cited source, and be able to explain when to choose a Deployment, DaemonSet, or StatefulSet and why a PVC stays Pending until a matching volume or default StorageClass exists.
3
Services, DNS, Ingress, and NetworkPolicy
Connect and protect the workloads you can now run (Domain 5, Services & Networking, 20%): the flat pod networking model, Services and their Endpoints with the empty-endpoints diagnosis, ClusterIP/NodePort/LoadBalancer types, Ingress and the newer Gateway API, CoreDNS resolution, and NetworkPolicy — including the subtlety that once a policy selects a pod it is default-deny for that direction. Practice on a kind cluster you own, using a policy-capable CNI (or killercoda) so a NetworkPolicy actually enforces, and confirm both the allowed and the blocked path.
Complete the Domain 5 networking lab on a cluster you own: apply the network fixture (a frontend and backend namespace, a backend Deployment and Service, and an allow-backend-only NetworkPolicy), confirm the Service has non-empty endpoints, and resolve api.backend.svc.cluster.local through CoreDNS.
Demonstrate the NetworkPolicy allowing an in-namespace request and blocking a cross-namespace request on a policy-enforcing CNI or on killercoda, and be able to run the empty-endpoints check (kubectl get endpoints) and explain that an empty endpoints list usually means the selector matches no pods.
Demonstrate the Service types and an Ingress rule, inspect the CoreDNS Corefile, and retain a Service/DNS/NetworkPolicy record — produced only on a local cluster you own with the context verified and the cluster deleted afterward.
Attempt every authored Services & Networking check and correct each miss against its cited source, tracing how Services, DNS, Ingress/Gateway API, and NetworkPolicy fit together and why a policy makes selected pods default-deny for its direction.
4
Troubleshooting mastery, kubectl speed, and the integrated timed capstone
Master the single heaviest and most time-pressured domain (Domain 2, Troubleshooting, 30%) and prove speed under a clock. You have practiced breaking and fixing workloads all along; now consolidate a repeatable diagnostic method — kubectl describe, kubectl logs --previous, kubectl get events, kubectl top, and the empty-endpoints check — for ImagePullBackOff, CrashLoopBackOff, OOMKilled, Pending pods, dead control-plane components, and broken Services, and drill imperative kubectl until you are fast enough for a seven-minute-per-task exam. Then run the integrated timed capstone spanning all five domains on your own kind cluster.
Complete the Domain 2 troubleshooting lab on a cluster you own: diagnose an ImagePullBackOff, a CrashLoopBackOff (using kubectl logs --previous), and a Pending pod from their events, fix each, and find and fix a broken Service via the empty-endpoints check — writing a one-line root cause and fix for each.
Demonstrate a repeatable, fast diagnostic method with a fixed toolkit (describe, logs --previous, get events, top, get endpoints) and imperative-kubectl speed drills (kubectl create/expose/scale/run and --dry-run=client -o yaml) so you can work under a seven-minute-per-task clock.
Complete the integrated timed capstone spanning cluster architecture and RBAC, workloads and scheduling, storage, services and networking, and troubleshooting against your own kind cluster under a self-imposed clock, then delete the cluster and confirm nothing persists.
Diff the current CNCF CKA curriculum (verify the targeted Kubernetes version and the 2025-02-18 revision), record remaining gaps, and choose a continue, practice, defer, Kubernetes experiment, or exam-scheduling next decision rather than inferring a pass from coverage.
Before a lab
Environment, access, and safety
Required and optional setup
Required
A browser plus text and diagram tools for the CNCF CKA curriculum and the kubernetes.io documentation (which is allowed during the real exam), and for recording each lab's commands, YAML manifests, kubectl output, and cluster-deletion confirmation
Docker Desktop or Docker Engine (free) on your own machine, plus kind (Kubernetes-in-Docker) or minikube (free) to create throwaway single- and multi-node clusters you own, and kubectl (free) on your PATH — the exact command-line tool the entirely-hands-on exam uses
The free, official add-ons and images the labs use — metrics-server for kubectl top and the HorizontalPodAutoscaler, the public nginx and busybox images, and a policy-capable CNI such as Calico when you want a NetworkPolicy to actually enforce — used only on a local cluster you own
A kubectl-context and cluster-deletion checklist recording, for each lab, that kubectl config current-context was verified as your own kind/minikube cluster before every command and that the cluster was deleted (kind delete cluster) when finished
Optional
The two killer.sh CKA simulator sessions bundled with exam registration, for realistic timed practice on a real-node cluster you are authorized to break (only relevant once you register for the exam)
The kubernetes.io documentation open in a browser as the reference you are permitted to use during the exam, so you build the habit of navigating it fast
A free community CKA video walkthrough (for example the freeCodeCamp 2026 update) as an alternate explanation after the official curriculum — a video is a survey, not the hands-on depth the performance-based exam demands, so pair it with real kubectl practice (verify it is free and current before relying on it)
Accounts and accessibility routes
Accounts
The local kind or minikube route requires no account and no payment: Docker, kind, minikube, and kubectl are free downloads, and every lab runs on your own machine.
The free killercoda CKA scenarios may require a free account but need no card and no paid tier for the browser-based practice used here (verify the free label before relying on it, since paid options exist elsewhere).
No lab requires a paid subscription, a cloud account, or a card; the two killer.sh simulator sessions are the only paid element and they come bundled with exam registration, not with this program, so they are optional and never required to complete a lab.
Equivalent routes
When installing Docker and kind or minikube locally is impractical for account, device, memory, motor, or visual reasons, use the free killercoda CKA scenarios — browser-based terminals on real clusters (including policy-enforcing CNIs for the NetworkPolicy lab and real nodes for kubeadm/etcd tasks kind cannot host) — which reach the same enumeration, deployment, networking, RBAC, and troubleshooting outcomes and the same command-transcript evidence with no local setup.
Every lab is command-line and text driven, so the whole program is keyboard-operable with plain-text kubectl output a screen reader can read linearly; the fixtures are plain YAML with labeled fields, and the killercoda alternative is a keyboard-navigable browser terminal.
In low-bandwidth conditions run the local kind or minikube labs, which run on your own machine after the initial image pulls and generate little further traffic, and record every command and manifest in a local document; the killercoda alternative is a lightweight browser terminal suitable for low bandwidth.
Safety baseline
Run every lab ONLY on a local kind (Kubernetes-in-Docker) or minikube cluster you create yourself on your own machine, or on a browser scenario platform (killercoda, or the killer.sh sessions bundled with exam registration) that explicitly authorizes breaking its clusters — never a production, shared, employer, school, or any cluster you do not own.
Verify kubectl config current-context before EVERY command and confirm it names your own throwaway cluster (for example kind-cka-arch); a stray kubectl context pointed at the wrong cluster is the single most common way people accidentally change a cluster they should not touch, and RBAC, taint, and NetworkPolicy changes are exactly the kind of change you never want to make there.
Never run etcdctl, kubeadm, or a destructive kubectl command against a real cluster's control plane unless you own and are explicitly authorized to administer it; practice kubeadm install/upgrade and the full etcd save/restore on a real-node scenario platform (killercoda/killer.sh), not on a single-node kind cluster and never on a live cluster you do not own.
Use only throwaway lab data and public images (nginx, busybox); never place real credentials, tokens, Secrets, kubeconfigs, or personal data into any pod, ConfigMap, Secret, or volume, and treat an unenforced NetworkPolicy on a default kind CNI as a learning exercise, not real protection.
Delete the kind cluster after every lab with kind delete cluster (or minikube delete) so nothing persists — a kind cluster is disposable, so there is no snapshot to keep; leave no stray clusters, containers, or NodePort mappings running when you finish.
Show your work
Module evidence and missed-check protocol
Module exit evidence
A labeled command transcript plus the YAML manifests for each domain tied to its module: a verified least-privilege RBAC setup with the yes/no kubectl auth can-i results (Domain 4); a rollout, rollback, resource-limit, and scheduling record (Domain 3); a bound-PVC durability proof with the PV's reclaim policy and access modes (Domain 1); a Service/CoreDNS/NetworkPolicy record with the allowed and blocked paths (Domain 5); and a root-cause-and-fix note for a set of deliberately-broken workloads and a broken Service (Domain 2).
A plain-language explanation of the concept, the kubectl command that revealed or fixed it, the authorization boundary the lab stayed inside (a local cluster you own, context verified), and — for the troubleshooting work — the diagnostic order you followed and how quickly you reached the fix, since the exam is timed.
All authored checks for the domain attempted, with each miss corrected against its cited source and re-applied to a fresh scenario, plus a recorded confirmation that the kubectl context was verified before every command and the kind cluster was deleted when finished.
After a missed check
Identify whether the question tests cluster architecture and RBAC, workloads and scheduling, storage, services and networking, or troubleshooting before reviewing the answer.
Write why the distractor was plausible and which specific mechanism distinguishes the correct answer — the Role/binding subject, the rollout or scheduling control, the PVC binding or access mode, the Service selector or NetworkPolicy direction, or the failure state and its diagnosing command.
Because the exam is timed, also note the fastest imperative-kubectl path to the correct action (for example kubectl create/expose/scale or --dry-run=client -o yaml), then change one detail — the namespace, the image, the resource request, the selector, or the policy direction — and explain whether the correct answer changes.
Completing this policy demonstrates current-curriculum CKA coverage and hands-on Kubernetes-administration practice inside RoleMath on clusters you own or are authorized to break; it does not predict an exam score, confer any authorization to administer clusters you do not own, establish professional Kubernetes experience, or serve as a RoleMath credential. Because CKA is performance-based and time-pressured, treat your kubectl speed and diagnostic reflexes, not coverage alone, as the honest signal of readiness.
Integrated practice
Integrated timed CKA scenario on your own kind cluster, spanning all five domains
Run one integrated, methodology-ordered, timed scenario against a kind cluster you own that touches every CKA domain — build a workload with durable storage, expose it with a Service and restrict it with a NetworkPolicy, set up least-privilege RBAC, take an etcd snapshot, then diagnose and fix an injected fault — all under a self-imposed clock, then delete the cluster, proving you can operate across cluster architecture, workloads, storage, networking, and troubleshooting the way a performance-based exam demands.
Workflow
Stand up a kind (or minikube) cluster you own — a multi-node one if you want to exercise scheduling — verify kubectl config current-context names your own throwaway cluster, and start a self-imposed clock (aim for roughly seven minutes per task) so the whole scenario is practiced under exam-like time pressure.
Cluster architecture and RBAC (Domain 4): create a namespace and a ServiceAccount, build a least-privilege Role and RoleBinding, and verify with kubectl auth can-i that the ServiceAccount can perform its intended action and nothing more; take an etcd snapshot (etcdctl snapshot save) on a real-node platform if you are running one, or record the snapshot drill and why its endpoints need a real control-plane node.
Workloads and scheduling (Domain 3): deploy an application as a Deployment imperatively, set resource requests and limits, and place it deliberately (a toleration onto a tainted node or a nodeSelector onto a labeled node), then perform a rolling update and confirm you can kubectl rollout undo it.
Storage (Domain 1): give the workload durable storage by creating a PersistentVolumeClaim, confirm it binds (Pending to Bound) and mounts, write and read back a file to prove durability, and note the bound PV's reclaim policy and access modes.
Services and networking (Domain 5): expose the workload with a Service, confirm its endpoints are populated and that CoreDNS resolves its cluster DNS name, then apply a NetworkPolicy that permits only the intended traffic and confirm both the allowed and the blocked path (on a policy-enforcing CNI or killercoda).
Troubleshooting under the clock (Domain 2): inject a fault into the running system — a wrong image, a crashing container, an impossible resource request, or a broken Service selector — then diagnose it with your fixed toolkit (describe, logs --previous, get events, top, get endpoints), state the root cause, and fix it before the clock runs out.
Write a short integrated run record: for each domain, the commands and manifests you used, the evidence (the auth can-i results, the rollout history, the bound PVC, the DNS lookup and policy behavior, and the root cause and fix), and how long each task took against your seven-minute target.
Diff the current CNCF CKA curriculum against what you practiced (verify the targeted Kubernetes version and the 2025-02-18 revision), flag any uncovered topic as an explicit gap, crosswalk every artifact to the five domain IDs, then delete the kind cluster (kind delete cluster) and confirm nothing persists on your machine.
Retained artifacts
A verified RBAC record: the namespace, ServiceAccount, least-privilege Role and RoleBinding, and the yes/no kubectl auth can-i results, plus the etcd snapshot drill note
A workloads-and-scheduling record: an imperative Deployment with resource limits, a placement via toleration or nodeSelector, and a rolling update with a kubectl rollout undo shown in the revision history
A storage record: a PVC that moved from Pending to Bound and mounted, a file written and read back, and the bound PV's reclaim policy and access modes
A services-and-networking record: a Service with populated endpoints, a successful CoreDNS lookup, and a NetworkPolicy with both the allowed and the blocked path confirmed on a policy-enforcing CNI
A troubleshooting record: the injected fault, the diagnosing commands, the root cause, the fix, and the time each task took against a seven-minute-per-task target
The integrated run record with a five-domain crosswalk, a curriculum diff flagging any gaps, and a confirmation that the kind cluster was deleted and nothing persists
Review checklist
The scenario ran entirely on a kind or minikube cluster the learner owns (or an explicitly-authorized platform), with kubectl config current-context verified before every command and no action ever taken against a production, shared, or employer cluster.
Cluster architecture and RBAC are demonstrated with a least-privilege Role verified by kubectl auth can-i returning yes for the intended action and no for a denied one, and the etcd snapshot drill is recorded with an accurate note on why its endpoints need a real control-plane node.
Workloads and scheduling are demonstrated with an imperative Deployment, applied resource limits, a deliberate placement via toleration or nodeSelector, and a rolling update that was rolled back via kubectl rollout undo.
Storage is demonstrated with a PVC that bound and mounted, a file written and read back to prove durability, and the bound PV's reclaim policy and access modes recorded.
Services and networking are demonstrated with a Service backed by populated endpoints, a successful CoreDNS resolution, and a NetworkPolicy whose allowed and blocked paths were both confirmed on a policy-enforcing CNI (not an unenforced default kind CNI treated as real protection).
Troubleshooting is demonstrated by diagnosing and fixing an injected fault with a repeatable describe/logs --previous/get events/top/get endpoints method, and the run was timed against a seven-minute-per-task target to reflect the performance-based exam.
The current CNCF CKA curriculum was rechecked (targeted Kubernetes version and 2025-02-18 revision) and any changed objective invalidates the affected mapping or review.
All five current CKA domains map to at least one artifact; uncovered topics remain explicit gaps rather than implied completion, and the kind cluster was deleted with nothing left behind.
The packet does not claim exam success, official Linux Foundation or CNCF approval or training beyond linked sources, any authorization to administer clusters the learner does not own, professional Kubernetes experience, or a RoleMath credential.
Safety boundary: Run the entire capstone ONLY on a local kind or minikube cluster you own (or an explicitly-authorized scenario platform such as killercoda/killer.sh) — never a production, shared, employer, school, or any cluster you do not own. Verify kubectl config current-context before every command, keep etcdctl and kubeadm work to a real-node platform you are authorized to break, use only throwaway data and public images, treat an unenforced NetworkPolicy as a learning exercise rather than real protection, and delete the kind cluster (kind delete cluster) when finished so nothing persists.
Finish honestly
Completion, portfolio, and maintenance
Completion evidence
All five current CKA domain modules have been covered and checked against the official CNCF CKA curriculum, including a recheck of the current curriculum (the targeted Kubernetes version and the 2025-02-18 revision) before any exam scheduling.
Every domain lab has been run only on a local kind or minikube cluster the learner owns or an explicitly-authorized scenario platform — with the kubectl context verified before every command and the cluster deleted afterward — and its command transcript and manifests retained.
Imperative-kubectl speed and a repeatable troubleshooting method (describe, logs --previous, get events, top, get endpoints) have been drilled to reflect a performance-based exam that gives roughly seven minutes per task.
Every authored knowledge check has been attempted and each miss has a cited correction plus a fresh scenario.
The CNCF curriculum, the kubernetes.io documentation, and the free tool and browser-scenario resources have been used within their current free-access terms, with any community walkthrough reconciled to the official curriculum.
The integrated timed capstone passes its context-verification, RBAC, workloads, storage, networking, troubleshooting, timing, and five-domain-coverage review, with the kind cluster deleted and nothing left behind.
The learner has recorded remaining curriculum gaps and a next Kubernetes-practice or exam-scheduling decision; completion is not represented as an exam result, a credential, authorization to administer clusters the learner does not own, job readiness, or professional Kubernetes experience.
Portfolio candidates
A sanitized RBAC record: a namespace, ServiceAccount, least-privilege Role and RoleBinding, and the kubectl auth can-i yes/no results, with any real cluster identifiers removed
A workloads-and-scheduling record: the imperative Deployment commands and manifests, applied resource limits, a toleration or nodeSelector placement, and a rollout history showing a rollback
A storage record: the PVC and pod manifest, the Pending-to-Bound transition, the file read back from the mounted volume, and the PV's reclaim policy and access modes
A services-and-networking record: the Service and its endpoints, the CoreDNS lookup, and a NetworkPolicy with the allowed and blocked paths confirmed on a policy-enforcing CNI
A troubleshooting record: the deliberately-broken workloads, the diagnosing commands (describe, logs --previous, get events), the root cause and fix for each, and the empty-endpoints Service diagnosis
The integrated capstone run record with a five-domain crosswalk, a curriculum diff, task timings against a seven-minute target, and a confirmation the kind cluster was deleted
Present the packet as self-directed CKA lab work done only on clusters you own or an explicitly-authorized platform. Do not call it production Kubernetes administration, Linux Foundation or CNCF approval, authorization to administer any cluster you do not own, professional Kubernetes experience, or a RoleMath credential, and never publish a real cluster, kubeconfig, or credential.
Freshness controls
Objective source checked 2026-07-10. Recheck objectives every 30 days and resources every 90 days.
Stop and re-verify when
The CNCF or Linux Foundation changes the CKA curriculum, domain set, weight ranges, exam code, format, passing score, allowed in-exam documentation, eligibility window, retake policy, or recommended experience.
Kubernetes/curriculum version bump: the CKA curriculum retargets a new Kubernetes version, is revised away from the 2025-02-18 revision, or an object, command, or interface the labs rely on (for example a Service, NetworkPolicy, Gateway API, or RBAC field) changes behavior across a release.
A tool or add-on the labs use — Docker, kind, minikube, kubectl, metrics-server, a policy-capable CNI such as Calico, or the public nginx/busybox images — changes URL, access, version, behavior, or reuse terms.
A browser scenario platform (killercoda free CKA scenarios, or the killer.sh sessions bundled with exam registration) changes URL, access, its free tier, or its authorization to break its clusters.
A lab can no longer be run on a self-owned local kind/minikube cluster within the free tier, or its context-verification, cluster-deletion, own-cluster-only, or imperative-kubectl-speed guarantees no longer hold.
A cluster-architecture, workloads-and-scheduling, storage, services-and-networking, or troubleshooting concept materially changes, or a topic (for example the Gateway API) is added to or removed from the curriculum.
Any module, lab, check, phase, capstone step, account instruction, safety guardrail, or curriculum diff fails technical, source, Kubernetes-domain, administrator-level, safety, authorization, privacy, accessibility, currency, or claims review.
20%Services & NetworkingCNCF CKA exam curriculum + Linux Foundation exam page (2026-07-10)
15%Workloads & SchedulingCNCF CKA exam curriculum + Linux Foundation exam page (2026-07-10)
10%StorageCNCF CKA exam curriculum + Linux Foundation exam page (2026-07-10)
Suggested study order
CKA weights the five domains as Storage 10%, Troubleshooting 30%, Workloads & Scheduling 15%, Cluster Architecture, Installation & Configuration 25%, and Services & Networking 20%, and unlike a linear exam we do not recommend studying them in numeric order — we recommend building from the conceptual spine outward and saving the heaviest, most time-pressured domain for last. Start with Cluster Architecture, Installation & Configuration (Domain 4, 25%) because it is the mental model everything else hangs on: how the control-plane components (API server, scheduler, controller-manager, etcd) and the kubelet fit together, how RBAC decides who can do what, and how the cluster is stood up and kept healthy. Once you can picture the machine, move to Workloads & Scheduling (Domain 3, 15%), because Deployments, ConfigMaps, scaling, self-healing, and the scheduler's placement rules are the objects you will manipulate in almost every task. Then take Services & Networking (Domain 5, 20%): Services, DNS, Ingress, the Gateway API, and NetworkPolicy are how those workloads talk to each other and to the outside world, and they make far more sense once you already understand pods and Deployments. Storage (Domain 1, 10%) comes next because PersistentVolumes, PersistentVolumeClaims, StorageClasses, and access modes are a comparatively self-contained slice that builds cleanly on the workloads you have already deployed. Treat Troubleshooting (Domain 2, 30% — the single heaviest and most time-pressured domain) as the capstone you practice continuously the whole way through, not as a chapter you read once at the end: every time you deploy something, deliberately break it and fix it, because on the exam you diagnose failing pods, dead control-plane components, and broken Services against the clock. The exam gives you roughly seven minutes per task, so imperative kubectl (create, expose, scale, run, --dry-run=client -o yaml) and reading kubectl describe / logs / get events quickly are worth as much study time as any single concept. This is sequencing advice based on the published weights and the way the concepts build on one another, not a claim about the science of learning — if a different order fits how you think, use it, but keep Troubleshooting as a running thread throughout because it is nearly a third of the exam.
Study this first. At 25% it is the second-heaviest domain, and it is the conceptual spine everything else hangs on: how the control-plane components fit together, how RBAC decides who can do what, and how a cluster is stood up and kept healthy. Understand the machine before you operate it.
This is the 'understand, build, secure, and maintain the cluster itself' domain, and the CNCF weights it at 25% of the CKA curriculum — the second-heaviest slice. We recommend studying it first because it is the conceptual spine of the whole exam: once you can picture how the control plane, the nodes, and the security model fit together, every other domain becomes an application of that mental model rather than a set of disconnected commands. This domain is the administrator's core: standing a cluster up, keeping it healthy across versions, controlling who can do what, extending it, and protecting its data.
Cluster lifecycle with kubeadm is the installation backbone. kubeadm is the official tool for bootstrapping a conformant cluster: kubeadm init sets up a control-plane node, kubeadm join adds worker (or additional control-plane) nodes, and kubeadm upgrade moves the cluster to a new Kubernetes version in a controlled way. The lifecycle also includes certificate management — the cluster's components authenticate to each other with certificates that expire and must be rotated — and the general discipline of upgrading the control plane before the workers and one minor version at a time. These install and upgrade tasks genuinely require real nodes (virtual machines), which a single-node local kind cluster cannot reproduce, so we are explicit that you practice kubeadm on VMs or on a hosted scenario platform, not by pretending kind covers it.
High availability and packaging tools round out installation. A production control plane is usually made highly available by running multiple control-plane nodes behind a load balancer with a replicated etcd, so the loss of one node does not take down the cluster — you should understand the shape of an HA topology even if you do not build one in a lab. On the packaging side, Helm installs and manages applications as versioned charts, and Kustomize layers environment-specific overlays onto base manifests without templating; the exam expects you to recognize what each does and to use them to deploy or customize workloads.
The extension interfaces are the pluggable seams of the cluster, and the exam wants you to know what each does. The Container Network Interface (CNI) is the plugin that gives pods their networking (a cluster is not fully functional until a CNI is installed). The Container Storage Interface (CSI) is how external storage systems provide volumes. The Container Runtime Interface (CRI) is how the kubelet talks to the container runtime (such as containerd) that actually runs containers. You are not expected to write a plugin, but you should be able to say which interface is responsible when, for example, pods are stuck because no network plugin is installed.
Authorization with RBAC is the security heart of the domain and a frequent exam task. Role-Based Access Control governs who can perform which actions on which resources. A Role grants permissions within a single namespace and a ClusterRole grants them cluster-wide; a RoleBinding or ClusterRoleBinding attaches those permissions to a subject — a user, a group, or a ServiceAccount (the identity pods use to talk to the API). The single most valuable RBAC skill on the exam is verification: kubectl auth can-i checks whether a given subject may perform a given action, so you can prove a least-privilege Role does exactly what you intended and nothing more. Building a namespace, a ServiceAccount, a read-only Role, and a RoleBinding, then confirming the permissions with kubectl auth can-i, is exactly the shape of a common exam question.
CRDs, Operators, and etcd backup close the domain. CustomResourceDefinitions (CRDs) extend the Kubernetes API with new resource types, and Operators are controllers that manage those custom resources to automate an application's lifecycle. And because etcd is the cluster's single source of truth, backing it up and restoring it with etcdctl (snapshot save and snapshot status) is a marquee exam skill — though the live etcd endpoints and certificates only exist on a real control-plane node, so you practice the full save/restore on VMs or a hosted scenario and use kind only for the RBAC pieces. The lab below applies the RBAC fixture (a namespace, ServiceAccount, least-privilege Role, and RoleBinding) on a kind cluster you own, verifies it with kubectl auth can-i, and walks the etcd snapshot drill while pointing you to killercoda/killer.sh for the kubeadm install/upgrade tasks kind cannot host. As always, read the CNCF curriculum and the kubernetes.io administration docs (allowed in the exam) for the authoritative topic list; this explanation paraphrases the scope in our own words rather than reproducing it.
Learn it free
Official · Official exam curriculum
CNCF CKA exam curriculum + Linux Foundation exam pageThe authoritative topic list for this domain's architecture, installation, RBAC, and etcd coverage — read it directly rather than relying on any summary, including ours. (captured 2026-07-10)
Official · Official documentation (allowed in the exam)
Kubernetes documentation: Administer a clusterThe authoritative reference for RBAC, etcd backup/restore, and cluster maintenance tasks — and the exact documentation you are permitted to use during the hands-on exam. (captured 2026-07-10)
Official · Official documentation (allowed in the exam)
Kubernetes documentation: Installing with kubeadmThe authoritative kubeadm init/join/upgrade reference for the install and lifecycle tasks that need real nodes — pair it with a real-node scenario platform since kind cannot host kubeadm. (captured 2026-07-10)
Vetted independent · Free community deep-dive
Kubernetes The Hard Way (Kelsey Hightower)A free, widely respected walkthrough of building a cluster component by component; it is not required for the exam and goes deeper than kubeadm, but it cements how the control-plane pieces fit together (community resource, not official CKA content). (captured 2026-07-10)
Official · Free official introductory course
Introduction to Kubernetes (LFS158, The Linux Foundation)A free Linux Foundation course covering Kubernetes architecture fundamentals — a solid, vendor-authored primer for the concepts this domain builds on (verify the free enrollment before relying on it). (captured 2026-07-10)
Cka Cluster Architecture Lab
Build a least-privilege RBAC setup and verify it with kubectl auth can-i on a local cluster Walk the etcd snapshot drill and route kubeadm install/upgrade to a real-node scenario platform
Free tools
Local machine with Docker
kind (Kubernetes-in-Docker)
kubectl
Steps
Create a local kind cluster you own and VERIFY the kubectl context before applying any RBAC objects.
Apply the RBAC fixture to create the namespace, ServiceAccount, least-privilege Role, and RoleBinding.
Use kubectl auth can-i to prove the ServiceAccount can read pods but cannot delete them, confirming the Role is genuinely least-privilege.
Read the etcd snapshot drill in the fixture comments and record where it applies, and note explicitly that kubeadm init/join/upgrade and the live etcd endpoints need real VMs, so you will practice those on killercoda/killer.sh, not on kind.
Delete the entire kind cluster so nothing persists on your machine.
What you should see
Confirm the note records the created namespace/ServiceAccount/Role/RoleBinding, a yes for getting pods and a no for deleting them via kubectl auth can-i, and an understanding of the etcd snapshot drill, with the context verified and the cluster deleted afterward.
Practice evidence maps to exam_domain_linux_foundation_certified_kubernetes_administrator_cka_04
Stay safe & legal: The RBAC steps run only on a local kind cluster you create yourself; verify kubectl config current-context is kind-cka-arch before every command, never apply these RBAC objects to a production, shared, employer, or any cluster you do not own, and never run etcdctl against a real cluster's etcd unless you own and are authorized to administer it. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 2 of 5 · domain 3 · 15% of the exam
Workloads & Scheduling
Study this second, right after the architecture spine. At 15% it is a middle-weight domain, and its objects — Deployments, ConfigMaps and Secrets, scaling, self-healing, and scheduler placement rules — are the ones you manipulate in almost every task, so fluency here pays off across the whole exam.
This is the 'run, update, scale, and place your applications' domain, and the CNCF weights it at 15% of the CKA curriculum. It sits at the center of daily Kubernetes work: nearly every task you will do on the exam involves a Deployment, a ConfigMap, or the scheduler's placement rules in some way, so fluency here compounds across the whole exam. The domain is about the controllers that keep your desired state true — the objects that make sure the right number of the right containers are running, updated safely, and placed on the right nodes.
Deployments and their rollouts are the heart of the domain. A Deployment manages a set of identical pods and gives you controlled, versioned updates: when you change the image, it performs a rolling update, replacing old pods with new ones gradually so the app stays available. kubectl rollout status watches an update land, kubectl rollout history shows the revisions, and kubectl rollout undo rolls back to the previous revision — a very common exam task, because rolling back a bad deploy is a core administrator skill. The imperative commands matter here: on a timed exam, kubectl set image and kubectl rollout undo are far faster than editing YAML, and knowing them cold saves precious minutes.
Configuration and secrets decouple your app from its settings. A ConfigMap holds non-sensitive configuration (environment values, config files) and a Secret holds sensitive data (credentials, tokens) in a base64-encoded form; both can be injected into pods as environment variables or mounted as files. The exam expects you to create these objects, often imperatively (kubectl create configmap, kubectl create secret), and to wire them into a pod. The professional point is that configuration should live outside the container image so the same image can run in different environments — a habit the exam rewards you for demonstrating.
Scaling and self-healing are what the controllers give you for free, and the exam wants you to understand both the manual and the automatic side. kubectl scale sets a replica count directly, while a HorizontalPodAutoscaler (HPA) adjusts replicas automatically based on observed metrics like CPU (a VerticalPodAutoscaler, VPA, instead adjusts the resource requests of pods). Self-healing comes from the controllers themselves: a Deployment recreates a pod that dies, a DaemonSet keeps exactly one pod per node, and a StatefulSet manages pods with stable identities and storage for stateful apps. Knowing which controller fits which need — stateless app, per-node agent, stateful database — is a recurring exam judgment.
Scheduling is where you influence which node a pod lands on, and it has a precise vocabulary. Resource requests and limits tell the scheduler how much CPU and memory a pod needs (and caps how much it may use), and requests directly affect placement — a pod whose request no node can satisfy stays Pending. Taints and tolerations let a node repel pods unless a pod explicitly tolerates the taint, which is how you reserve nodes for particular workloads. nodeSelector and node affinity attract pods to nodes with matching labels, and PriorityClasses let higher-priority pods preempt lower-priority ones under pressure. These placement controls need more than one schedulable node to practice meaningfully, which is why the lab uses a multi-node cluster.
Study this domain by performing rollouts, rollbacks, scaling, and placement on a multi-node cluster you own, using imperative commands so the exam's clock does not beat you. The lab below stands up a three-node kind cluster from the multinode fixture, then has you run a rolling update and a rollback, set resource requests and limits, taint a node and schedule a pod that tolerates it, target a labeled node with nodeSelector, and (with metrics-server installed) create an HPA — all imperatively. As always, read the CNCF curriculum and the kubernetes.io workloads docs (allowed in the exam) for the authoritative topic list; this explanation paraphrases the scope in our own words rather than reproducing it.
Learn it free
Official · Official exam curriculum
CNCF CKA exam curriculum + Linux Foundation exam pageThe authoritative topic list for this domain's workloads and scheduling coverage — read it directly rather than relying on any summary, including ours. (captured 2026-07-10)
Official · Official documentation (allowed in the exam)
Kubernetes documentation: WorkloadsThe authoritative reference for Deployments, DaemonSets, StatefulSets, scaling, and scheduling — and the exact documentation you are permitted to use during the hands-on exam, so learn to navigate it now. (captured 2026-07-10)
Vetted independent · Free community video course
Prepare for the Kubernetes Administrator certification (freeCodeCamp, 2026 update)A free, full-length CKA video walkthrough that reinforces the workload and scheduling objects — useful as an overview, though a two-hour video is a survey of the material, not the full hands-on depth the performance-based exam demands, so pair it with real kubectl practice. (captured 2026-07-10)
Cka Workloads Lab
Perform a rolling update and a rollback of a Deployment imperatively on a multi-node cluster Apply resource limits, taints/tolerations, nodeSelector placement, and a HorizontalPodAutoscaler
Free tools
Local machine with Docker
kind (Kubernetes-in-Docker)
kubectl
Steps
Create the multi-node kind cluster from the fixture and VERIFY the kubectl context and node count before scheduling anything.
Create a Deployment, perform a rolling update to a new image, then roll it back and confirm the revision history.
Apply resource requests and limits, taint a worker and schedule a tolerating pod onto it, and label the other worker and target it with nodeSelector.
Install metrics-server for this local cluster, confirm metrics flow, then create a HorizontalPodAutoscaler on the Deployment.
Delete the entire kind cluster so nothing persists on your machine.
What you should see
Confirm the notes show a completed rolling update and rollback, applied requests/limits, a pod placed onto a tainted node and one onto a labeled node, and a created HPA, with the context verified and the cluster deleted afterward.
Practice evidence maps to exam_domain_linux_foundation_certified_kubernetes_administrator_cka_03
Stay safe & legal: This lab runs only on a local multi-node kind cluster you create yourself on your own machine; verify kubectl config current-context is kind-cka-workloads before every command and never apply these Deployments, taints, or autoscalers to a production, shared, employer, or any cluster you do not own. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 3 of 5 · domain 5 · 20% of the exam
Services & Networking
Study this third, after workloads. At 20% it is a substantial domain, and it is how the workloads you have learned to run actually talk to each other and to the outside world — Services, DNS, Ingress, the Gateway API, and NetworkPolicy all make far more sense once pods and Deployments are familiar.
This is the 'how do the pieces talk to each other and to the outside world' domain, and the CNCF weights it at 20% of the CKA curriculum. It is where the workloads you have learned to run become a connected system: pods find each other, get stable addresses, resolve names, are reachable from outside the cluster, and are protected from traffic they should not receive. Networking is the domain where a small misconfiguration — a wrong label, a missing policy, a broken DNS record — produces symptoms that look like everything is broken, so understanding the model clearly is what keeps you from flailing.
The pod networking model is the foundation. Kubernetes gives every pod its own IP address, and the model requires that any pod can reach any other pod directly, without network address translation, across the whole cluster. That flat model is delivered by a CNI plugin (from the architecture domain), and it is the assumption every higher-level networking object is built on. Understanding that pods are individually addressable but ephemeral — their IPs change as they are rescheduled — is what motivates Services, which give a stable front for a changing set of pods.
Services are the stable networking abstraction and the most examined object in the domain. A Service selects a set of pods by label and gives them a single, stable virtual IP and DNS name; behind it, the Endpoints (or the newer EndpointSlices) list the actual pod IPs currently backing the Service. The Service types matter: ClusterIP exposes the Service only inside the cluster (the default), NodePort opens a port on every node so the Service is reachable from outside, and LoadBalancer provisions an external load balancer in supported environments. The single most valuable debugging habit here is to check a Service's endpoints — an empty endpoints list almost always means the selector matches no pods, which is a fast, high-value diagnosis that ties straight back to the troubleshooting domain.
Ingress and the newer Gateway API handle HTTP(S) routing into the cluster. An Ingress defines host- and path-based rules for routing external HTTP traffic to Services, and it needs an ingress controller running to enforce those rules. The Gateway API — added to the CKA curriculum in the February 2025 revision — is the newer, more expressive successor: a GatewayClass defines an implementation, a Gateway defines a listener, and an HTTPRoute defines the routing rules, separating the infrastructure concern from the routing concern more cleanly than Ingress did. The exam expects you to recognize both models and to know that Gateway API is the direction Kubernetes networking is heading.
NetworkPolicy is how you restrict traffic between pods, and it is a common exam task because the default is wide open. By default every pod can talk to every other pod; a NetworkPolicy changes that by selecting pods and specifying which ingress and egress traffic is allowed, using pod selectors and namespace selectors. A crucial subtlety the exam probes: once any NetworkPolicy selects a pod, that pod is default-deny for the direction the policy covers, so anything not explicitly allowed is blocked. Practicing a policy that permits traffic within one namespace and blocks it from another — and confirming both the allowed and the blocked path — is exactly the skill the exam rewards.
DNS with CoreDNS is the last pillar and the cause of many mysterious failures. CoreDNS runs in the cluster and gives Services and pods DNS names (a Service is reachable at name.namespace.svc.cluster.local), configured by a Corefile you can inspect. When name resolution fails inside the cluster, CoreDNS is where you look. Study this domain by wiring up Services, confirming DNS, and proving a NetworkPolicy both allows and blocks the right traffic on a cluster you own. The lab below creates a kind cluster with ingress support, applies the network fixture (two namespaces, a Deployment, a Service, and a NetworkPolicy), verifies DNS resolution through CoreDNS, confirms cross-namespace traffic is blocked by the policy, and has you demonstrate the Service types and an Ingress. As always, read the CNCF curriculum and the kubernetes.io services/networking docs (allowed in the exam) for the authoritative topic list; this explanation paraphrases the scope in our own words rather than reproducing it.
Learn it free
Official · Official exam curriculum
CNCF CKA exam curriculum + Linux Foundation exam pageThe authoritative topic list for this domain's services and networking coverage — read it directly rather than relying on any summary, including ours. (captured 2026-07-10)
Official · Official documentation (allowed in the exam)
Kubernetes documentation: Services, Load Balancing, and NetworkingThe authoritative reference for Services, Ingress, the Gateway API, NetworkPolicy, and DNS — and the exact documentation you are permitted to use during the hands-on exam, so learn to navigate it now. (captured 2026-07-10)
Vetted independent · Free community labs (browser terminal)
Killercoda CKA scenariosFree, no-install browser scenarios on a policy-enforcing cluster — the reliable way to see a NetworkPolicy actually block traffic if your local kind CNI does not enforce it (verify the free label before relying on it). (captured 2026-07-10)
Cka Networking Lab
Wire up a Service, confirm CoreDNS resolution, and inspect its endpoints on a local cluster Apply a NetworkPolicy and confirm it allows in-namespace traffic and blocks cross-namespace traffic
Free tools
Local machine with Docker
kind (Kubernetes-in-Docker)
kubectl
Steps
Create a local kind cluster you own and VERIFY the kubectl context; note that seeing the NetworkPolicy actually block traffic requires a policy-enforcing CNI or the killercoda alternative.
Apply the network fixture and confirm the backend Service has endpoints, proving its selector matches the api pods.
Verify DNS resolution through CoreDNS by looking up the Service's cluster DNS name from a throwaway pod, and inspect the CoreDNS Corefile.
Confirm the allowed path from within the backend namespace succeeds and the cross-namespace path from the frontend namespace is blocked by the NetworkPolicy (on a policy-enforcing CNI).
Delete the entire kind cluster so nothing persists on your machine.
What you should see
Confirm the notes show the api Service had endpoints, CoreDNS resolved the Service name, the in-namespace request succeeded, and the cross-namespace request was blocked (on a policy-enforcing CNI), with the context verified and the cluster deleted afterward.
Practice evidence maps to exam_domain_linux_foundation_certified_kubernetes_administrator_cka_05
Stay safe & legal: This lab runs only on a local kind cluster you create yourself on your own machine; verify kubectl config current-context is kind-cka-network before every command and never apply these Services or NetworkPolicies to a production, shared, employer, or any cluster you do not own. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 4 of 5 · domain 1 · 10% of the exam
Storage
Study this fourth, after you can deploy and connect workloads. At 10% it is the lightest domain, and it is a comparatively self-contained slice — PersistentVolumes, claims, StorageClasses, and access modes — that builds cleanly on the pods and Deployments you have already practiced.
This is the 'give a pod durable storage that outlives the pod' domain, and the CNCF weights it at 10% of the CKA curriculum. It is the lightest domain by weight, but it is worth getting exactly right, because storage tasks on the exam are usually well-defined and quick points if you know the object model, and slow, frustrating dead-ends if you do not. The whole point of the domain is that a pod's own filesystem is ephemeral: when the pod dies, anything written inside the container is gone. Persistent storage in Kubernetes is the machinery that lets data survive pod restarts, rescheduling, and deletion.
The object model has two halves that you must keep straight. A PersistentVolume (PV) is a piece of storage in the cluster — think of it as the supply side, the actual disk or network share made available to Kubernetes. A PersistentVolumeClaim (PVC) is a request for storage made by a workload — the demand side, where a pod says 'I need one gigabyte of read-write storage.' Kubernetes binds a claim to a volume that satisfies it, and the pod mounts the claim, never the volume directly. This claim-to-volume binding is the single most important thing to internalize: the exam expects you to reason about why a PVC is or is not bound, and to create the objects that make a pod's storage request succeed.
StorageClasses and dynamic provisioning are how modern clusters avoid pre-creating volumes by hand. Instead of an administrator manually creating a PV for every claim, a StorageClass describes a kind of storage (backed by a particular provisioner), and when a PVC references that class, the cluster provisions a matching volume automatically. A StorageClass can be marked as the cluster default, so claims that name no class still get storage. On a local kind cluster the default class is backed by a local-path provisioner, which is enough to watch a claim move from Pending to Bound the moment a pod that uses it is scheduled — the exact behavior the exam tests.
Access modes and reclaim policies are the two attributes that trip people up, so drill them until they are automatic. Access modes describe how many nodes can mount a volume and how: ReadWriteOnce (RWO) means one node can mount it read-write, ReadOnlyMany (ROX) means many nodes can mount it read-only, and ReadWriteMany (RWX) means many nodes can mount it read-write — and not every storage backend supports every mode, which is a common source of a claim that never binds. The reclaim policy (Retain, Delete) decides what happens to the underlying volume when its claim is deleted: Retain keeps the data for manual recovery, while Delete removes the volume. Knowing which policy is in effect is the difference between safely reclaiming space and silently destroying data.
Troubleshooting storage is where the domain overlaps hardest with the heaviest domain on the exam. A PVC stuck in Pending almost always means no PV or StorageClass can satisfy it — a missing default class, an unsupported access mode, or a size that no available volume meets. A pod stuck because it cannot mount its volume shows up in the pod's events, which you read with kubectl describe pod, and often points at a class, permissions, or node-affinity mismatch. The professional habit the exam rewards is to inspect the claim, the volume, and the pod's events together — kubectl get pvc, kubectl get pv, kubectl describe pod — and to reason from what is actually bound to what is missing, rather than guessing.
Study this domain by making a claim bind and a pod use it on a cluster you own, then deliberately inspecting the reclaim policy and access modes, because the exam is hands-on and storage points come fast once the object model is muscle memory. The lab below has you create a local kind cluster, apply the storage fixture (a PVC plus a pod that writes a file into the mounted volume), watch the PVC move from Pending to Bound, read the data back, and inspect the bound PV's reclaim policy and access modes — then delete the cluster. As always, read the CNCF curriculum and the kubernetes.io storage docs (which are allowed in the exam) for the authoritative topic list; this explanation paraphrases the scope in our own words rather than reproducing it.
Official · Official documentation (allowed in the exam)
Kubernetes documentation: Storage conceptsThe authoritative reference for PersistentVolumes, claims, StorageClasses, access modes, and reclaim policies — and it is the exact documentation you are permitted to use during the hands-on exam, so learn to navigate it now. (captured 2026-07-10)
Vetted independent · Free community labs (browser terminal)
Killercoda CKA scenariosFree, no-install browser scenarios for practicing storage tasks against a real cluster; a safe alternative if a local kind cluster is impractical (verify the free label before relying on it). (captured 2026-07-10)
Cka Storage Lab
Bind a PersistentVolumeClaim and mount it in a running pod on a local kind cluster Inspect a bound volume's reclaim policy and access modes and prove storage outlives its pod
Free tools
Local machine with Docker
kind (Kubernetes-in-Docker)
kubectl
Steps
Create a local kind cluster you own and VERIFY the kubectl context before touching anything, so every later command lands only on this disposable cluster.
Apply the storage fixture and watch the PersistentVolumeClaim move from Pending to Bound once the pod is scheduled and the local-path provisioner supplies a volume.
Read the file back out of the mounted volume, inspect the bound PV's reclaim policy and access modes, then delete the pod and confirm the claim stays Bound.
Delete the entire kind cluster so nothing persists on your machine.
What you should see
Confirm the notes show the context was kind-cka-storage, the PVC reached Bound, the test file was read from the mounted volume, and the bound PV's reclaim policy and access modes were recorded, with the cluster deleted afterward.
Practice evidence maps to exam_domain_linux_foundation_certified_kubernetes_administrator_cka_01
Stay safe & legal: This lab runs only on a local kind cluster you create yourself on your own machine; verify kubectl config current-context is kind-cka-storage before every command and never apply these manifests to a production, shared, employer, or any cluster you do not own. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 5 of 5 · domain 2 · 30% of the exam
Troubleshooting
This is the single heaviest domain at 30%, and it is also the most time-pressured. Do not save it for a final chapter — practice it continuously from day one by deliberately breaking every workload you deploy and fixing it, so diagnosing failures against the clock becomes automatic before exam day.
This is the 'something is broken — find out what and fix it, fast' domain, and the CNCF weights it at 30% of the CKA curriculum, making it the single heaviest domain on the exam. It is also the most time-pressured: troubleshooting tasks are where the clock hurts, because you have to form a hypothesis, gather evidence, and act, often in a few minutes. The domain rewards a repeatable diagnostic method far more than memorized trivia. Because it is nearly a third of the exam and touches every other domain, we tell learners to practice it continuously — deliberately break the workloads you deploy while studying the other domains, and fix them, so the method becomes reflexive.
Cluster and node logging is the foundation. When something is wrong at the infrastructure level, you look at the logs of the components that run the node: the kubelet (the agent on each node) and the container runtime. On a systemd-based node these are read with journalctl (for example the kubelet unit), and static control-plane pods write logs you can reach with kubectl logs or on disk under the node. The exam expects you to know where a component's logs live and to read them to distinguish, say, a kubelet that will not start from a node that is simply out of resources. Reading logs bottom-up — the most recent, most specific error first — is the habit that turns a wall of text into a diagnosis.
Resource usage and container logs are the everyday tools. kubectl top nodes and kubectl top pods (which need the metrics-server running) show CPU and memory pressure, which explains a surprising number of failures — evictions, OOMKills, and pods that will not schedule. For a specific container, kubectl logs shows its output, and the single most underused flag on the exam is kubectl logs --previous, which shows the logs of the last terminated container — essential for a pod that keeps crashing, because by the time you look, the current container may be brand new and blank. Knowing to reach for --previous on a CrashLoopBackOff is the difference between seeing the actual error and seeing nothing.
Application-level failures have a small vocabulary of states that you must be able to recognize on sight and map to a cause. ImagePullBackOff and ErrImagePull mean the image name is wrong or the registry is unreachable. CrashLoopBackOff means the container starts and then exits repeatedly — look at its exit code and its previous logs. OOMKilled means it exceeded its memory limit. A pod stuck Pending usually means the scheduler cannot place it: insufficient CPU or memory on any node, an unsatisfiable nodeSelector or affinity, or a taint with no matching toleration. The exam scenario is almost always 'here is a broken pod, tell me why and fix it,' and kubectl describe pod plus kubectl get events is how you read the story the events tell.
Control-plane component failures are the highest-stakes part of the domain, because when the API server, scheduler, controller-manager, kubelet, or etcd is unhealthy, the whole cluster misbehaves. On a kubeadm cluster the control-plane components run as static pods defined by manifest files on the control-plane node, so a common exam task is a component that will not start because its static-pod manifest has a typo or a bad flag. You confirm which components are up (kubectl get pods -n kube-system, or crictl on the node when the API server itself is down), read the failing component's logs, and correct the manifest. etcd is the cluster's datastore, so its health is non-negotiable, and its backup and restore live in the architecture domain but its failures land here.
Service, DNS, and endpoint issues round out the domain and connect it to networking. A Service that returns nothing usually has a selector that matches no pods, which you spot because its Endpoints (or EndpointSlices) are empty — a fast, high-value check. DNS failures inside the cluster point at CoreDNS. Study this domain by breaking things on purpose on a cluster you own and diagnosing them with a fixed toolkit — describe, logs --previous, get events, top — and by drilling the empty-endpoints check until it is automatic. The lab below applies a fixture full of deliberately-broken pods (a bad image, a crash loop, an impossible resource request) plus a break-the-Service-selector drill; you diagnose each with the standard tools and fix it. As always, read the CNCF curriculum and the kubernetes.io debug docs (allowed in the exam) for the authoritative topic list; this explanation paraphrases the scope in our own words rather than reproducing it.
Learn it free
Official · Official exam curriculum
CNCF CKA exam curriculum + Linux Foundation exam pageThe authoritative topic list for this heaviest domain's troubleshooting coverage — read it directly rather than relying on any summary, including ours. (captured 2026-07-10)
Official · Official documentation (allowed in the exam)
Kubernetes documentation: Monitoring, logging, and debuggingThe authoritative reference for debugging pods, Services, and cluster components — and the exact documentation you are permitted to use during the hands-on exam, so learn to navigate its debug tasks now. (captured 2026-07-10)
Vetted independent · Free community labs (browser terminal)
Killercoda CKA scenariosFree, no-install browser scenarios with realistic broken clusters to diagnose against the clock; the best way to build troubleshooting speed if a local kind cluster is impractical (verify the free label before relying on it). (captured 2026-07-10)
Cka Troubleshooting Lab
Diagnose ImagePullBackOff, CrashLoopBackOff, and Pending pods from events and previous logs and fix each Find and fix a broken Service using the empty-endpoints check on a local kind cluster
Free tools
Local machine with Docker
kind (Kubernetes-in-Docker)
kubectl
Steps
Create a local kind cluster you own and VERIFY the kubectl context before applying anything, since this fixture is deliberately broken and must land only on this disposable cluster.
Apply the troubleshooting fixture and observe the three pods land in their failing states.
Diagnose each pod with describe, previous logs, and events, then fix the image, the crashing command, and the impossible resource request.
Create and expose a deployment, deliberately break its Service selector, confirm the endpoints go empty, then fix the selector and confirm endpoints reappear.
Delete the entire kind cluster so nothing persists on your machine.
What you should see
Confirm the note records the correct root cause and the fixing command for each of the three pods and the broken Service, and that the context was kind-cka-troubleshoot, with the cluster deleted afterward.
Practice evidence maps to exam_domain_linux_foundation_certified_kubernetes_administrator_cka_02
Stay safe & legal: This lab runs only on a local kind cluster you create yourself, and its manifests are deliberately broken; verify kubectl config current-context is kind-cka-troubleshoot before every command and never apply these fixtures or run fixes against a production, shared, employer, or any cluster you do not own. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Skills you’ll build
Studying Certified Kubernetes Administrator (CKA)builds transferable skills that carry across employers and platforms, not just toward this one exam. Each has a free, source-cited RoleMath primer — what it is, a step-by-step free learning path, clearly labeled free resources, and a safe hands-on exercise:
Work through the modules above, then get a personalized read on where you stand: the readiness check maps your background against these same published domains and suggests what to study first — no score, no pass prediction.
Exam format: Performance-based and entirely hands-on (command-line only, no multiple choice): roughly 15-20 tasks in a live Kubernetes environment, 2 hours. The kubernetes.io documentation is allowed during the exam. Official Linux Foundation CKA exam page
Exam registration fee: Approximately $445 USD for the CKA exam (verify the current price on the Linux Foundation page; it periodically bundles training and offers discounts). Registration includes two killer.sh simulator sessions, one free retake, a 12-month eligibility window, and a 2-year certification validity. Official Linux Foundation CKA exam page
Version currency: The CKA curriculum tracks Kubernetes releases (currently targeting Kubernetes v1.35) and was last substantively revised 2025-02-18. Verify the current curriculum version on the CNCF/Linux Foundation page before studying. Official Linux Foundation CKA exam page
Recommended experience: Comfort with the Linux command line, containers (Docker), and YAML. No prior Kubernetes certification is required, but this is an administrator-level exam. Official Linux Foundation CKA exam page
A free, source-cited study companion built on the CNCF's published Certified Kubernetes Administrator (CKA) curriculum and the official Linux Foundation exam page — not official training, not a pass guarantee. CKA is a performance-based, entirely hands-on exam: you solve real tasks at the command line in a live Kubernetes cluster, so speed with kubectl and imperative commands matters as much as knowing the concepts. Every hands-on lab here runs only on a local kind cluster you create and own; verify the current curriculum version on the official page before your exam.
Certification and vendor names are used only to identify the program this independent study companion refers to. RoleMath is not affiliated with, endorsed by, or sponsored by The Linux Foundation.