CKA
Certified Kubernetes Administrator (CKA) Program
Certified Kubernetes Administrator (CKA) Exam Guide: Requirements, Skills, and Study Roadmap
The Certified Kubernetes Administrator (CKA) validates whether a candidate can perform Kubernetes administrator responsibilities through an online, remotely proctored, performance-based command-line exam. It is suited to infrastructure, DevOps, platform, and Kubernetes practitioners who need to demonstrate operational competence rather than only explain concepts. This guide helps you decide whether your current experience is sufficient, which domains deserve the most practice, how to use the included attempts and simulations, and when you are ready to schedule.
What the CKA validates
The CKA is designed to demonstrate the skills, knowledge, and competency required to perform Kubernetes administrator responsibilities. The exam is created by the Cloud Native Computing Foundation in collaboration with The Linux Foundation and uses a vendor-neutral, hands-on format rather than a multiple-choice assessment.
That distinction should shape your preparation. You need to be able to inspect a cluster, identify the relevant object or component, choose an appropriate command or manifest, make the change, and verify the result. Memorizing isolated definitions is less useful than understanding how Kubernetes components behave and how to recover when an intended change does not work.
The official program description says a CKA can demonstrate basic installation as well as configuring and managing production-grade Kubernetes clusters. It also identifies networking, storage, security, maintenance, logging, and troubleshooting as important areas of administrator competence. Treat these as connected operational skills: a failed workload may require checking scheduling, networking, storage, configuration, or node health rather than focusing on the visible error alone.
Who should choose this certification
The CKA is a practical fit for people responsible for operating Kubernetes clusters, supporting platform teams, maintaining workloads, or troubleshooting cluster behavior. It can also suit a learner moving from Linux or infrastructure administration into Kubernetes, provided that the learner is prepared to build command-line fluency through repeated lab work.
Prioritize the CKA if your target role involves cluster administration rather than application development alone. The Certified Kubernetes Application Developer certification focuses on designing, building, and deploying cloud-native applications; the CKA instead centers on the administrator’s responsibilities. A security-focused progression should also be sequenced carefully because the CKS requires candidates to have passed the CKA before attempting it.
A candidate with daily Kubernetes exposure should not assume that routine use covers the whole assessment. Higher-level tools can hide cluster components and command details. Preparation should deliberately expose you to the underlying resources, control-plane behavior, node operations, storage, services, and diagnostic workflow that your normal role may abstract away.
What the exam measures
The CKA measures five official domains: Storage, Troubleshooting, Workloads and Scheduling, Cluster Architecture, Installation and Configuration, and Services and Networking. The current competency weighting is Storage 10%, Troubleshooting 30%, Workloads and Scheduling 15%, Cluster Architecture, Installation and Configuration 25%, and Services and Networking 20%.
Troubleshooting is the largest domain at 30%, so it should be a central practice thread rather than an end-of-course topic. Cluster Architecture, Installation and Configuration carries 25%, while Services and Networking carries 20%; these domains require both conceptual understanding and the ability to inspect and modify a running environment. Workloads and Scheduling accounts for 15%, and Storage accounts for 10%.
The domain categories remained unchanged when the CKA competencies were updated. The Linux Foundation states that exams taken on or after February 18, 2025 reflect the updated competencies, regardless of when the reservation or purchase was made. Use the current official competency list when building your study checklist, especially if you are preparing from older material.
How to read the blueprint without misusing it
Blueprint weights are planning signals, not a reason to ignore smaller domains. A weak Storage result can still undermine otherwise strong performance, and troubleshooting frequently depends on knowledge from architecture, workloads, networking, or storage. Use the percentages to allocate attention while maintaining a complete working ability across all listed competencies.
Start by marking each official competency as one of three states: can perform without help, can perform with documentation, or cannot yet perform. Then give priority to tasks in the last category, followed by tasks that require too much searching or repeated trial and error. This diagnostic is more useful than simply counting how many Kubernetes terms you recognize.
When you review a practice result, record the cause of the miss. Separate knowledge gaps from execution errors, inefficient navigation, incorrect context, and failure to verify the result. The corrective action differs: a knowledge gap needs explanation and lab repetition, while an execution error may need a shorter command workflow and a verification checklist.
Build the right practice environment
Use a disposable Kubernetes environment where you can create, alter, break, and restore resources. The official exam is delivered as command-line problems running on Linux, so your practice should make the terminal the primary interface. The exact lab platform is a practical choice; the essential requirement is repeated work against real Kubernetes objects and cluster components.
Practice with documentation available, but do not copy commands without understanding their effect. For each exercise, first describe the desired state, identify the resource involved, apply the smallest suitable change, and verify the resulting state. Then repeat the task from a clean starting point without relying on a saved answer.
Keep a short operational notebook containing commands you have personally tested, symptoms and likely causes, and verification commands. Organize it by task—such as scheduling, service reachability, storage attachment, or node health—rather than as an unstructured list of flags. This makes the notes useful as a navigation aid while preserving the understanding needed to adapt commands to a new scenario.
The official resources permitted during the exam should be checked before exam day, and your practice should mirror those rules. Do not build a plan around leaked questions, exam dumps, or memorized task text. Those materials are not a substitute for administrator competence and may conflict with examination requirements.
Sequence your study by dependency
A productive sequence moves from cluster structure to ordinary object management, then to connectivity and persistence, and finally to diagnosis under time pressure. This order reduces random command memorization because later tasks depend on earlier knowledge of resources, controllers, nodes, and control-plane behavior.
Begin with Linux command-line habits and Kubernetes object inspection. Become comfortable identifying namespaces, contexts, nodes, pods, controllers, services, and configuration resources. Learn to read manifests and command output precisely. Your first goal is not speed; it is being able to explain what Kubernetes is attempting to do and where that state is represented.
Next, practice workloads and scheduling. Create and modify common workload resources, inspect scheduling decisions, and investigate why a pod is pending, restarting, or failing readiness. Include resource constraints, labels, selectors, and placement rules in your exercises. Always finish by checking status and events rather than assuming that a successful command means a successful workload.
Then study services and networking, followed by storage. Trace a request from a workload to a service and investigate the points where selectors, ports, endpoints, policies, or pod readiness can prevent the expected result. For storage, connect the claim, volume, storage class, node, and consuming workload in your mental model. Finally, integrate these topics into mixed troubleshooting sessions.
Reserve architecture, installation, and configuration for both an early foundation and a later review. Early study gives you the component model; later practice tests whether you can use that model when a node, control-plane component, or cluster configuration behaves unexpectedly.
Study Cluster Architecture, Installation and Configuration
This 25% domain requires more than knowing Kubernetes component names. Prepare to explain how cluster components interact, how configuration is represented, and how administrative changes affect the cluster. Practice inspection first, then controlled modification, and verify both the immediate result and the relevant health indicators.
Work through exercises that require you to identify the role of the control plane, nodes, API interaction, scheduling, and cluster state. Examine configuration files and component status in your lab. When a change affects cluster behavior, document the before state, make one change, and compare the after state. This makes faulty assumptions easier to isolate.
Include maintenance-oriented thinking. Ask what must remain available, what can be changed safely, and what evidence confirms that the change worked. A command that returns without an error is not sufficient verification if the relevant component is still unhealthy or the desired behavior has not appeared.
A common mistake is studying installation as a one-time setup procedure while neglecting configuration and operational consequences. Counter it by pairing every setup exercise with a diagnosis exercise: deliberately create a known misconfiguration, identify the symptom, locate the source, correct it, and confirm recovery.
Study Workloads and Scheduling
The 15% Workloads and Scheduling domain is best prepared through short, repeatable tasks that move from declaration to placement to runtime verification. Focus on how workload specifications, labels, selectors, resources, and scheduling constraints combine, because an apparently correct object can still produce an unschedulable or unhealthy workload.
Practice creating and editing workload resources using both manifests and efficient command-line methods. Inspect generated or existing YAML instead of treating it as opaque text. After each change, check rollout or pod state, events, and the effective configuration. Learn to distinguish an invalid specification from a valid specification that cannot be scheduled or cannot become ready.
Build a fault matrix for common symptoms. A pending pod suggests a scheduling or resource problem; a restarting pod calls for container and event investigation; a ready-looking workload with no traffic calls for service and endpoint checks. These are study categories, not shortcuts: confirm the cause in the cluster before applying a fix.
Avoid changing several fields at once. If you alter an image, selector, resource request, and placement rule together, you may not know which change solved or caused the problem. Make a targeted edit, observe the result, and retain the habit of verifying that the fix matches the requested outcome.
Study Services and Networking
Services and Networking carries 20% of the current blueprint, so practice tracing connectivity rather than memorizing service types in isolation. A reliable workflow checks names, namespaces, selectors, endpoints, ports, pod readiness, and the path from the client to the intended workload.
Create services for deliberately labeled workloads, then test what happens when a selector, target port, namespace, or readiness condition is wrong. Inspect the objects that represent the service’s selected backends. When connectivity fails, first establish whether the service has endpoints, whether the target pods are ready, and whether the port mapping matches the application.
Use small, controlled network exercises before attempting larger scenarios. Test internal service discovery, workload-to-workload communication, and the effect of configuration changes. Keep a record of the command that proves each layer is working. This prevents the common mistake of declaring networking fixed because one endpoint responds while another path remains broken.
Do not begin with advanced networking theory detached from cluster evidence. The exam’s performance-based format rewards the ability to inspect a concrete environment and take the appropriate administrative action. Learn the concepts, but always connect them to object state, events, endpoints, logs, and a reproducible test.
Study Storage and data paths
Storage accounts for 10% of the current blueprint, but storage failures can block workloads and create difficult troubleshooting conditions. Learn the relationship between storage classes, persistent volume claims, persistent volumes, access requirements, pods, and nodes, then practice finding the first broken link in that chain.
Create claims and consuming workloads in a lab, inspect binding and events, and test what changes when a requested property cannot be satisfied. Follow the claim from request to binding to mount from the workload’s perspective. Confirm both control-plane state and the application-visible result rather than stopping after a resource reports that it was created.
Practice distinguishing a claim that is waiting to bind from a workload that cannot mount an already bound volume. The symptoms may appear in different objects, so start with the affected pod and follow its events and related resources. Keep the diagnosis evidence-led; do not delete and recreate storage objects merely because the first command did not produce the expected state.
A frequent preparation pitfall is learning storage commands without understanding persistence and attachment behavior. Repeat exercises after restarting or relocating the consuming workload where your lab supports it, and explain what should remain, what should be recreated, and what evidence proves the data path is functioning.
Make Troubleshooting your integration practice
Troubleshooting is the largest CKA domain at 30%, and it also integrates nearly every other domain. Prepare by starting from symptoms, collecting evidence, forming one hypothesis, testing it, and applying the narrowest correction. The objective is not to guess the familiar fix; it is to identify why this cluster is producing this result.
Use a repeatable inspection order. Establish the active context and namespace, inspect the affected resource, read status and events, check related objects, and review logs or component information where appropriate. Then verify the user-visible or cluster-level outcome. Adapt the order when the evidence points elsewhere, but avoid making unverified changes simply to see what happens.
Create mixed scenarios in which a failure crosses domain boundaries: a workload may be healthy but unreachable, a pod may be correctly configured but unschedulable, or a service may exist without selecting ready backends. Write down the initial symptom and final root cause after each lab. Over time, this builds diagnostic patterns without turning them into rigid assumptions.
Track time spent and the number of unnecessary changes. The best troubleshooting practice is not only solving the issue; it is solving it with a clear trail of evidence and leaving the environment in a known state. If you cannot explain why your correction worked, repeat the exercise from a clean state.
Use documentation as a working tool
Documentation access rewards knowing how to find authoritative syntax quickly, not trying to memorize every option. Practice opening the relevant Kubernetes documentation, locating the resource or task, extracting the smallest usable example, and adapting it to the namespace, context, and constraints in front of you.
Build a search routine around the problem statement. Identify the noun first—such as a workload, service, volume, node, or configuration object—then search for the operation and the relevant behavior. Read enough surrounding text to catch prerequisites and field relationships. Copy only the portions you understand, and verify the result after applying them.
Maintain a compact index of documentation locations and tested command patterns. The index should point you toward topics; it should not be a collection of unexamined answers. Practice navigating from the official documentation during timed labs so that documentation lookup becomes a controlled part of your workflow rather than a last-minute distraction.
A common mistake is spending too long searching for a perfect command when a simple inspection command would reveal the next step. Start with cluster evidence, narrow the question, and then consult documentation for exact syntax or supported behavior.
A practical study roadmap
A flexible roadmap should contain four stages: baseline assessment, domain construction, integrated troubleshooting, and exam rehearsal. The calendar length depends on your existing Linux and Kubernetes experience, so use demonstrated performance—not an arbitrary number of study days—as the signal for moving between stages.
In the baseline stage, attempt representative exercises across every official domain without looking for shortcuts. Record what you could complete, what required documentation, and what you could not diagnose. This creates a personal priority list and prevents overinvesting in familiar workload tasks while neglecting architecture, storage, or troubleshooting.
During domain construction, work through the five areas in dependency order. Use short sessions with a clear objective: inspect and alter a cluster configuration, schedule and verify workloads, trace service connectivity, complete a storage path, or recover from a controlled fault. End each session with a brief explanation of the evidence that proved success.
In the integration stage, combine domains in fresh lab environments. Deliberately vary namespaces, labels, resource names, and initial conditions so that you cannot rely on copied context. Review every failed attempt and repeat the underlying skill until the diagnosis and correction are reproducible.
In the rehearsal stage, use the official simulation attempts as readiness checks rather than as your entire preparation. The Linux Foundation states that the CKA purchase includes access to two exam simulation attempts, and that each simulation attempt provides 36 hours of access from activation. Use the first to expose weaknesses and the second after targeted remediation. Do not activate either simulation merely to browse it; plan the review time before starting.
Before booking, you should be able to work through unfamiliar tasks systematically, recover from mistakes, use documentation without losing control of the session, and verify results. If your performance depends on remembering a particular practice question, continue practicing the underlying administrator skill instead.
Manage time during performance-based tasks
The official exam consists of 15–20 performance-based tasks, and candidates have 2 hours to complete the CKA. Prepare a pacing method that protects points: read the full task, identify its context and requested result, make the smallest change, verify it, and move on when the investigation stops being productive.
During timed practice, separate easy execution from deep diagnosis. Complete tasks whose requirements and verification are clear, then return to problems that need broader investigation. Record enough information to resume cleanly, including the namespace, resource, symptom, and next diagnostic step. Avoid spending the session repeatedly rewriting a command that has not been validated.
Treat verification as part of the task, not an optional final step. Check the object state and the requested behavior. A resource may exist while a rollout is incomplete, a service may exist without usable backends, or a claim may exist without being usable by the workload. Your practice timer should include this confirmation.
Do not make destructive changes to unrelated resources when under pressure. If a correction fails, pause and compare the current state with the original requirement. A calm rollback or narrower diagnostic step is usually more valuable than a sequence of guesses.
Prepare for remote delivery
The CKA is delivered online and remotely proctored through streaming audio, video, and screen-sharing feeds. You provide the computer and must use an environment that meets the published requirements. Treat the technical check as part of exam preparation, not as an administrative task to complete at the last moment.
The Linux Foundation’s instructions specify one active monitor; dual monitors are not supported. The organization recommends a screen size of 15” or higher and a screen resolution of 1080p for the ExamUI. Reliable internet access, a working microphone, and a suitable supported operating system are also required; review the current PSI system requirements rather than relying on an old checklist.
Run the PSI Online Proctoring System Check and review the Bridge FAQ and Linux OS troubleshooting guidance before scheduling. The PSI Secure Browser download is made available at exam launch time, so confirm in advance that your computer and network can support the process. A wired connection may be more stable, and bandwidth-intensive services should be disabled during the session.
Use a private, suitable testing location. Public spaces such as coffee shops, stores, and open office environments are not allowed. Remove avoidable interruptions, confirm that other users are not consuming the connection heavily, and test the microphone and camera in the same physical setup you expect to use.
The official instructions also warn about keyboard shortcuts: use Ctrl+Alt+W instead of Ctrl+W because Ctrl+W closes the current tab in Google Chrome. Add this detail to your final technical checklist, along with the secure-browser test, power, connectivity, identification, and appointment information.
Schedule without losing eligibility
Exam registration generally gives you 12 months from the registration date to schedule and take the exam, including an eligible retake, or until a corporate subscription expires, whichever happens first. Use the eligibility date shown in My Portal as the controlling deadline and choose a sitting date that leaves time for deliberate remediation.
After registration, the Schedule action redirects you to the PSI Dashboard. The scheduling process asks you to select the country and time zone where you will take the exam, then choose an available date and time. The scheduling documentation states that exam reservations require 24-hour lead time, making the following day the earliest possible reservation date.
You may upload an identification document before scheduling or skip that step and complete it later or during check-in using a mobile device, subject to the identification requirements. Complete it early if doing so reduces administrative risk, but follow the current candidate identification instructions rather than relying on an informal checklist.
A reservation may be cancelled or rescheduled up to 24 hours before its scheduled start time. Changes are unavailable when 24 hours or less remain. A no-show forfeits the registration fees and does not qualify for a retake, so do not book a time you are unlikely to attend.
The purchase listed by the Linux Foundation includes 12 months to schedule and take the exam, two exam attempts, and access to two exam simulation attempts. Confirm the exact offer attached to your order before relying on those inclusions, particularly if you purchase through a different channel or an authorized training partner.
Understand scoring, retakes, and certification currency
The CKA passing requirement is a score of 66% or above. Results are emailed within 24 hours after the exam is completed, subject to the stated exceptions for technical difficulties or other issues. A purchase normally includes one retake when the candidate does not pass and remains eligible, but the order and current terms control the applicable entitlement.
The retake is not an unlimited extension of eligibility. Under the exam terms, one retake per exam purchase is granted, and unless the exam order says otherwise it must be taken within 12 months of the original purchase or before the corporate subscription expires, whichever comes first. Confirm the status in your account before planning the second attempt.
A failed attempt should produce a targeted recovery plan. Review where points were lost, classify each miss as a knowledge, execution, navigation, or verification problem, and repeat those skills in a clean environment. Do not simply retake a simulator or reread notes without proving that the original failure mode has changed.
The certification becomes non-current 24 months after the candidate successfully passes the certification exam unless it is revoked earlier or renewed under applicable requirements. Candidates may keep it current by retaking and passing the same exam before expiration; the renewed period becomes current for 2 years from the date the exam is retaken and passed. Check the certification FAQ for available renewal paths and complete requirements before expiration.
Choose the purchase and training route
The Linux Foundation lists the exam-only purchase at $445. It also lists a CKA exam plus THRIVE-ONE annual subscription bundle at $625 and a CKA exam plus Kubernetes Fundamentals (LFS258) course bundle at $645. Decide based on the support you actually need, not on the assumption that a bundled course automatically replaces hands-on practice.
Choose exam-only when you already have a reliable lab, understand the current competencies, and can diagnose your own gaps. A structured course is more defensible when you need guided explanations, a systematic introduction, or a defined sequence through Kubernetes fundamentals. In either case, reserve time for independent command-line practice and fault diagnosis.
Review the official catalog immediately before purchase because prices, bundles, and included benefits can change. If you buy through an authorized training partner, confirm refund and retake conditions with that partner. The general terms state that an exam registration refund may be requested only when the purchase was made less than three business days earlier and the exam has not been scheduled or taken; partner purchases may follow partner-specific handling.
Do not schedule simply because a purchase includes a second attempt. Treat the retake as contingency capacity, not as the main study plan. A first attempt used as a diagnostic can be expensive and may leave insufficient time to correct weaknesses within the eligibility period.
Common preparation mistakes to avoid
Most CKA preparation failures come from practicing the wrong behavior: reading without operating a cluster, memorizing commands without understanding state, or specializing in familiar workloads while neglecting troubleshooting and configuration. Correct these habits early by requiring every study session to produce a verified change or diagnosis.
Relying on old blueprints is particularly risky because the competency set changed for exams taken on or after February 18, 2025. Check the current Linux Foundation program page and competency list before using a course, note set, or simulator. The date you sit for the exam determines which update applies, not merely the date you purchased or reserved it.
Another mistake is confusing a successful command with a successful outcome. Apply a manifest, then inspect the resulting resource, events, readiness, endpoints, mounts, or component health as appropriate. If the requested behavior is not present, the task is not complete.
Avoid practicing only in a familiar namespace with predictable names. Vary contexts, namespaces, labels, resource names, and starting conditions. The aim is to make your method portable, so that you can read the task in front of you rather than reconstructing a remembered sequence.
Finally, do not neglect delivery rules. A technically prepared candidate can still lose an attempt through an unsupported monitor setup, an unsuitable location, an untested secure browser, a no-show, or a reservation change made too late. Treat the candidate handbook and PSI requirements as part of the certification syllabus.
Final readiness decision
Schedule when your practice evidence shows consistent execution across all five domains, not merely when you have finished watching a course. You should be able to diagnose unfamiliar cluster behavior from evidence, use permitted documentation efficiently, work within 2 hours, and complete the required technical checks without unresolved questions.
Use a final readiness review with four tests. First, repeat a mixed lab from a clean state. Second, explain the cause of each failure before applying a fix. Third, verify every requested outcome rather than only resource creation. Fourth, complete the PSI system check and confirm the exam location, monitor, network, microphone, identification, and reservation details.
If one domain remains weak, delay scheduling when your eligibility window allows it and target that domain with fault-based practice. If the problem is time management, reduce command search and improve task triage rather than simply studying more theory. If the problem is technical setup, resolve it before activating an exam attempt.
Once ready, record the current competency version you prepared against, confirm the terms attached to your purchase, and schedule through the official portal. After the exam, review the result when emailed and keep the certification expiration and renewal requirements in your professional calendar.
Conclusion
The CKA is a decision-oriented administrator assessment: inspect Kubernetes state, make controlled changes, and prove that the cluster or workload now behaves as required. Build preparation around the current domains, give troubleshooting deliberate attention, and use simulations to measure readiness rather than to replace practice. Before scheduling, confirm the current official requirements, technical environment, eligibility deadline, and reservation policy. That process gives you a clearer basis for deciding whether to book now, continue lab work, or use structured training to close a specific gap.