CKS
Certified Kubernetes Security Specialist (CKS)
Certified Kubernetes Security Specialist (CKS) Exam Guide
The Certified Kubernetes Security Specialist (CKS) validates practical ability to secure container-based applications and Kubernetes platforms across build, deployment, and runtime. It is intended for Kubernetes practitioners who already hold the Certified Kubernetes Administrator (CKA) credential and want to demonstrate security-focused operational competence. This guide helps you decide whether your current Kubernetes experience is ready for a performance-based exam, which domains deserve the most practice, and how to turn the blueprint into a realistic preparation and scheduling plan.
What does the CKS exam validate?
The CKS tests whether you can apply Kubernetes and cloud-native security practices at the command line, rather than simply recall security terminology. Its scope follows the application lifecycle: securing cluster configuration, workloads, software supply chains, and runtime behavior. The Linux Foundation describes the exam as performance-based and focused on security during build, deployment, and runtime.
The credential is vendor-neutral and is offered by the Linux Foundation and the Cloud Native Computing Foundation. Its practical emphasis makes it a better fit for candidates who can already operate Kubernetes resources and troubleshoot Linux-based environments than for someone approaching Kubernetes security as a purely theoretical subject.
A useful readiness test is simple: can you inspect an unfamiliar cluster, identify a security weakness, choose an appropriate control, apply it safely, and verify the result from a terminal? If your answer depends on copying isolated commands without understanding their effect, spend more time building and breaking small environments before scheduling.
The exam is not a substitute for security architecture experience. It gives you a structured target for hands-on Kubernetes security skills. Your preparation should therefore connect each objective to an observable action, such as restricting a workload, validating an image, examining audit evidence, or responding to suspicious runtime behavior.
Who should take CKS, and what must be true first?
You must have achieved the Certified Kubernetes Administrator (CKA) certification before scheduling CKS; the CKA does not need to be active. The Linux Foundation’s update states that a CKA status of Achieved, Renewed, or Expired can satisfy this prerequisite, so confirm your certification record before purchasing or booking.
The intended audience includes experienced DevOps, SRE, system administration, cloud, and Kubernetes professionals who want to expand their security capability. The exam assumes the operational foundation represented by CKA: navigating Kubernetes resources, working from a Linux command line, and diagnosing configuration problems under time pressure.
If you have never administered a cluster, begin with CKA-level administration rather than jumping directly into security tooling. If you hold CKA but rarely use Kubernetes, refresh resource inspection, manifests, networking, storage, scheduling, and cluster troubleshooting before studying the security domains. Security controls are difficult to apply efficiently when basic Kubernetes operations are still slow.
A CKS purchase is a sensible next step when you can perform ordinary cluster tasks without relying on a graphical interface and can explain the security consequences of common configuration choices. It is premature when your study plan is mostly flashcards, product descriptions, or memorized snippets.
Which domains carry the most weight?
The current CKS blueprint has six domains. Supply Chain Security, Minimizing Microservice Vulnerabilities, and Monitoring, Logging and Runtime Security each account for 20% of the exam; Cluster Setup and Cluster Hardening each account for 15%; and System Hardening accounts for 10%. Allocate practice according to both the published weights and your weakest practical skills.
Cluster Setup is 15% of the exam domain weight and concerns establishing security-conscious cluster foundations. Prepare by practicing how you would inspect and adjust the components that form the control plane and node environment, then verify that the intended configuration is actually active.
Cluster Hardening is 15% of the exam domain weight. Treat this as an access and exposure problem: examine who can perform actions, which interfaces are reachable, and whether Kubernetes configuration grants more authority than a workload or operator needs.
System Hardening is 10% of the exam domain weight. Use this domain to strengthen Linux and node-level habits, including reducing unnecessary exposure and checking the host conditions that can undermine otherwise careful Kubernetes configuration.
Minimizing Microservice Vulnerabilities is 20% of the exam domain weight. Practice reducing workload privilege and limiting the damage a compromised container or service could cause. Your exercises should include inspecting manifests, identifying excessive permissions, and testing whether the deployed workload behaves within its intended boundary.
Supply Chain Security is 20% of the exam domain weight. Study the path from source and image construction through admission and deployment. Practice verifying provenance or policy assumptions with the tools and configuration available in your lab, rather than treating an image tag as proof of integrity.
Monitoring, Logging and Runtime Security is 20% of the exam domain weight. Build the habit of using audit and runtime evidence to identify access, abnormal behavior, and possible attack progression. A good exercise ends with a defensible explanation of what happened and which evidence supports it.
Do not interpret the percentages as a promise about the number of tasks in each domain. The official material supplies domain weights, while the exam instructions state that the exam contains 15-20 performance-based tasks. The exact task mix is not something to predict or memorize.
How should you study the blueprint instead of memorizing it?
Turn every domain into a repeatable loop: inspect the starting state, state the security objective, make the smallest effective change, test the result, and record how you would undo it. This approach prepares you for unfamiliar task wording because it develops diagnosis and verification, not dependence on a single copied command.
Start with a skills inventory. For each domain, mark tasks you can perform from memory, tasks you can complete with documentation, and tasks you cannot yet complete. Schedule laboratory time around the third category. Reading is useful for learning vocabulary and design intent, but terminal work reveals whether you can locate the right object, file, log, or policy quickly.
Keep a decision log rather than a command dump. For each exercise, write the symptom, the likely control point, the command or manifest change used, and the verification step. Include failure conditions: a rejected request, an unavailable workload, a denied authorization, or a missing log entry may indicate either a successful control or an incorrect implementation.
Use official documentation as a navigation aid during practice, but do not build your plan around finding an exact future task. The exam is performance-based; leaked questions and dumps are neither a sound preparation method nor a guarantee of passing. Practice solving variations of the same security problem in clean environments.
A practical lab pattern
Create short scenarios with a known weakness and a measurable target. For example, begin with a workload that has more permissions than it needs, apply a safer configuration, redeploy it, and verify both the permissions and application behavior. Then repeat the exercise with a different namespace, service account, or manifest structure so that the method transfers.
What to record after each exercise
Record the resource or host component involved, the evidence that exposed the issue, the change you made, and the command that confirmed success. Also note one plausible mistake and how you would detect it. This turns each lab into a compact troubleshooting reference without assuming that the same syntax will appear in the exam.
What should your hands-on environment include?
Use a disposable Kubernetes lab where you can alter cluster configuration, deploy deliberately imperfect workloads, inspect logs, and recover from mistakes. The exact platform is a practical choice rather than an official exam requirement; what matters is that your environment lets you repeat security changes from a Linux command line and observe their consequences.
Build exercises around the six official domains instead of collecting unrelated tools. A cluster setup exercise should end with a configuration check. A workload-hardening exercise should show reduced privilege. A supply-chain exercise should test an enforcement or validation decision. A runtime exercise should produce evidence that you can investigate.
Practice under constraints that resemble the exam’s working style: terminal-first navigation, concise notes, and a limited time window. Avoid spending every session rebuilding the lab. Keep reusable setup files, but make sure you understand what they create. A prebuilt environment is valuable only if you can diagnose it when an expected object, permission, or log is absent.
Use a clean reset between major attempts. If you leave undocumented changes in place, later success may come from hidden state rather than understanding. After resetting, deliberately vary names, namespaces, and starting conditions. This tests whether you can locate the relevant resources instead of relying on muscle memory.
How should you sequence preparation?
A reliable sequence is administration refresh, foundational hardening, workload and supply-chain controls, runtime investigation, then timed integration. This order reduces wasted effort: you first restore the Kubernetes mechanics required by every domain, then layer security decisions on top, and finally practice switching between domains without losing time.
Phase one should refresh CKA-level execution. Work from the command line until you can inspect resources, edit or generate manifests, understand namespaces and service accounts, read events and logs, and recover from common deployment errors. Do not move on merely because you recognize the concepts; measure whether you can complete ordinary actions without prolonged searching.
Phase two should cover Cluster Setup, Cluster Hardening, and System Hardening together. These domains interact: a secure workload can still be exposed by weak cluster access or an unprotected node. For each exercise, identify the boundary being protected and the evidence that proves the boundary is working.
Phase three should concentrate on Minimizing Microservice Vulnerabilities and Supply Chain Security. Compare insecure and constrained workload definitions. Trace how an artifact moves toward deployment, identify where trust can be checked or rejected, and verify that a policy is enforced rather than merely documented.
Phase four should focus on Monitoring, Logging and Runtime Security. Generate controlled activity in the lab, inspect the available evidence, and write a short incident timeline. Include the question, “What would distinguish an expected action from suspicious behavior?” This prevents monitoring practice from becoming a passive log-reading exercise.
Phase five should integrate everything in timed sessions. Mix tasks from all six domains, begin with no assumptions about which component is at fault, and review errors afterward. The purpose is not to predict the real exam; it is to train prioritization, verification, and recovery when the domain changes from one task to the next.
A four-week example roadmap
In week one, refresh command-line Kubernetes administration and establish the lab. Map each blueprint domain to at least one repeatable scenario. Spend the final session identifying the tasks that still require step-by-step notes.
In week two, work through cluster, node, access, and workload-hardening scenarios. For every change, test both the intended secure path and an action that should now be denied. This exposes controls that appear configured but are not effective.
In week three, add supply-chain validation, admission or deployment decisions, audit evidence, and runtime investigation. Alternate implementation sessions with diagnosis sessions: one session starts from a requirement, while the next starts from a symptom.
In week four, run timed mixed practice, then repair the largest recurring weaknesses. Reserve the final study sessions for concise workflows and environment checks, not for learning an entirely new collection of tools.
How do you prepare for performance-based time pressure?
The exam contains 15-20 performance-based tasks and allows 2 hours to complete the CKS exam. You therefore need a method for making progress even when a task is unfamiliar. Read the requirement completely, identify the affected boundary, establish a quick baseline, make a targeted change, and verify before moving on.
Do not spend an unlimited amount of time perfecting one task. If you cannot identify the control point after a focused investigation, record what you know, move to a task where the objective is clearer, and return later. This is a preparation recommendation, not an official scoring rule; the goal is to protect your opportunity to earn credit across the exam.
Use verification as part of the solution, not as an optional final step. A manifest that looks safer may fail validation, an authorization change may affect the wrong subject, and a log query may return irrelevant evidence. Confirm the actual object, effective behavior, and relevant output.
Practice concise terminal workflows. Know how to locate configuration, filter output, inspect YAML, search logs, and preserve a working copy before editing. Efficiency should come from familiar investigation patterns rather than from typing commands without understanding them.
Run at least one practice session in which you deliberately leave a task incomplete and return to it later. This tests whether your notes are sufficient and whether you can restore context. It also reduces the risk of losing time because you cannot remember what you already checked.
What delivery and equipment details should you verify?
The CKS is delivered online through PSI Bridge using the PSI Secure Browser and remote audio, video, and screen-sharing proctoring. You provide your own computer, internet connection, microphone, and supported operating system. Complete the official PSI system check and review the current Bridge guidance before booking a session.
The Linux Foundation recommends one active monitor, with dual monitors not supported, and recommends a screen size of 15” or higher and a screen resolution of 1080p. Its instructions also recommend reliable connectivity, avoiding bandwidth-heavy activity on the same connection, and using a wired connection when practical.
The Secure Browser download becomes available at exam launch, and the official instructions direct candidates to review the PSI Secure Browser FAQ and Linux OS troubleshooting guidance before exam day. Treat installation as a planned technical check, not as a problem to solve for the first time at launch.
The exam is remotely proctored through streaming audio, video, and screen-sharing feeds. Public spaces such as coffee shops, stores, and open office environments are not allowed. Choose a private, compliant location and remove avoidable network activity from the computer and connection.
The CKS is available in English, Japanese, and Simplified Chinese. The candidate handbook states that candidates may switch among available exam languages through the exam console’s language control. Confirm the language options and interface guidance in the official handbook before scheduling.
For terminal work, the official instructions warn that Ctrl+W closes the current tab in Google Chrome and recommend Ctrl+Alt+W instead. They also specify Linux terminal shortcuts for copying and pasting: Ctrl+Shift+C and Ctrl+Shift+V. Practice these habits if your normal environment uses different shortcuts.
A pre-booking technical checklist
Run the PSI system check on the computer and network you expect to use. Confirm the operating system, microphone, camera, browser behavior, single-monitor setup, display readability, and network stability. Then review the current official instructions again close to the appointment because technical requirements and platform guidance can change.
How do registration, attempts, and scheduling work?
A standard CKS exam purchase includes 12 months to schedule and take the exam, two exam attempts, and access to two exam simulation attempts. The terms of service govern eligibility, reservations, refunds, and retakes, so keep the purchase window and appointment rules visible when planning your study calendar.
The Linux Foundation currently lists the exam-only price as $445 in the supplied certification research. Prices and package availability can change, so use the official certification page to confirm the amount before purchase rather than treating this guide as a quotation.
If you do not achieve a passing score, the terms provide one retake per eligible exam purchase, subject to the stated conditions. An eligible retake generally must be taken within 12 months of the original exam purchase or before a corporate subscription expires, whichever comes first. Confirm the terms attached to your order.
You may reschedule or cancel an exam reservation up to 24 hours before its start time. Changes are not available when 24 hours or less remain, and a no-show forfeits the registration fee and does not qualify for a retake. Do not reserve a date until your lab work and technical setup are credible.
The exam registration provides eligibility within 12 months of the registration date, or until a corporate subscription expires, whichever happens first. Use that window intentionally: schedule early enough to leave time for a retake, but not so early that you are relying on untested knowledge.
A refund may be requested only when both conditions are met: the purchase was made less than three (3) business days ago and the exam has not been scheduled or taken. Purchases through an authorized training partner may follow partner-specific handling, so check the applicable terms before assuming a refund is available.
What changed in the current CKS blueprint?
The CKS domains remained recognizable after the update that took effect for exams taken after 12:01am UTC on September 12, 2024, but competencies and several domain weights changed. Any retake taken after that cutoff tests the updated set, so old notes or older practice material should not be treated as a complete blueprint.
The current published domains are Cluster Setup, Cluster Hardening, System Hardening, Minimizing Microservice Vulnerabilities, Supply Chain Security, and Monitoring, Logging and Runtime Security. Use the current certification page and its competency list as the source of truth when deciding what to study.
The supplied research identifies the exam environment as based on Kubernetes v1.35, with alignment to the most recent Kubernetes minor version occurring approximately 4 to 8 weeks after a Kubernetes release. Because version alignment is time-sensitive, verify the official certification page before building a lab or scheduling.
A practical response to blueprint changes is to maintain two lists: stable security principles and version-sensitive implementation details. Principles such as least privilege, controlled trust, verification, and useful evidence transfer across versions. Commands, configuration locations, and tool behavior require current documentation and hands-on confirmation.
Do not let a prior preparation guide determine your schedule if it conflicts with the current blueprint. First compare its domains and competencies with the official page, then replace obsolete exercises. This is especially important when a retake is planned, because the updated blueprint applies to retakes taken after the stated effective time.
Does passing CKS affect CKA status?
Beginning June 18, 2026, passing or recertifying CKS automatically reinstates or extends CKA to the new CKS expiration date, including when the CKA has already expired. This is a certification-status benefit described by CNCF, not a reason to skip the CKA prerequisite or reduce preparation for CKS.
The CNCF explanation states that a CKS exam can be scheduled when CKA was achieved at any time in the candidate’s lifetime, and that CKA may be active, close to expiring, or expired. If your certification timeline matters, check your LF account and the current CNCF and Linux Foundation guidance before making a purchase decision.
Linux Foundation certifications become non-current 24 months from the date the certification requirements are successfully completed, unless another status event or renewal rule applies. Retaking and passing the same exam before expiration is one listed renewal method, while individual programs may offer additional paths.
Keep copies of achievement and expiration information in your planning notes. Certification status is account-specific, and this article cannot inspect your record. If the CKA prerequisite or CARE interaction is unclear, resolve that question with the official certification support channel before scheduling.
What mistakes commonly weaken CKS preparation?
The most damaging mistake is studying security concepts without repeatedly applying them to a working cluster. CKS tasks require locating the relevant control, changing it accurately, and proving the result. Replace passive reading with short scenarios that have a visible starting weakness and a testable secure outcome.
Another mistake is distributing time evenly across the blueprint. The 20% domains—Minimizing Microservice Vulnerabilities, Supply Chain Security, and Monitoring, Logging and Runtime Security—deserve substantial practice, but the 15% Cluster Setup and Cluster Hardening domains and the 10% System Hardening domain still represent material coverage. Use the weights alongside your personal error log.
Do not confuse a deployed configuration with an effective security control. A policy may target the wrong subject, a manifest may be rejected, a permission may be broader than intended, or an audit query may omit the event you need. Always test the expected allowed behavior and the expected denied or detected behavior.
Avoid building a lab that hides the mechanics. Automation can save setup time, but if you cannot explain which objects, files, identities, or logs it creates, it will not help when a task starts from a different state. Rebuild manually often enough to understand the dependency chain.
Do not ignore delivery constraints until the appointment. A dual-monitor setup, unstable connection, missing microphone permission, unfamiliar secure browser, or unsuitable location can disrupt an otherwise adequate preparation effort. Perform the official system check and rehearse on the same equipment you intend to use.
Finally, do not schedule solely because you have completed a course or simulator. Schedule when you can diagnose new variations, verify changes, and manage a timed mixed session. Training products can structure practice, but they do not replace the ability to perform the required work independently.
What should you do next?
Start by confirming the CKA prerequisite and checking the current official CKS page for the active blueprint, Kubernetes version, purchase terms, and available language. Then run a short diagnostic lab covering one task from each domain. Use the results to decide whether you need an administration refresh, focused security practice, or timed integration.
If the diagnostic exposes basic Kubernetes gaps, postpone scheduling and rebuild command-line fluency first. If you can operate the cluster but struggle with workload boundaries, supply-chain decisions, or runtime evidence, prioritize those areas according to the blueprint and your error log. If the skills are sound but execution is slow, shift toward mixed timed sessions.
Before purchasing, compare the registration window with your actual study availability and leave room for the eligible retake rules. Before reserving an appointment, complete the PSI system check, select a private compliant location, prepare one supported monitor, and review the current candidate instructions.
On the final preparation day, avoid broad new study. Review your investigation workflow, verify your equipment, confirm the appointment details, and ensure that your notes reflect current official guidance. Your goal is controlled execution: identify the security boundary, make the smallest correct change, and verify what the cluster now does.
Conclusion
CKS preparation is strongest when it is organized around decisions and verification rather than a list of security terms. Confirm the CKA prerequisite, use the current six-domain blueprint, give the three 20% domains substantial laboratory attention, and maintain enough cluster administration fluency to work efficiently from the command line. Then validate the practical details—version guidance, PSI setup, language, reservation window, and retake conditions—against the official sources before you schedule.