CKS: Certified Kubernetes Security Specialist Practice Exam

What the CKS exam covers

• Cluster Setup122 questions
• Cluster Hardening147 questions
• System Hardening137 questions
• Minimize Microservice Vulnerabilities171 questions
• Supply Chain Security134 questions
• Monitoring, Logging and Runtime Security160 questions

Free CKS sample questions

A sample of 10 questions with answers and explanations. Sign up free to practice all 871.

1. Question 1Cluster Setup

   You must benchmark a kubeadm cluster against the CIS Kubernetes Benchmark and get a list of failing controls. Which tool and invocation is standard for this on a control-plane node?

   • Akubectl audit cis --node master
   • BTrivy cluster --benchmark cis
   • Ckubeadm check cis
   • DKube-bench run --targets masterCorrect
   ✓ Correct answer: D

   kube-bench is the industry-standard open-source tool for checking Kubernetes clusters against the CIS Kubernetes Benchmark. Running 'kube-bench run --targets master' on a control-plane node executes all CIS checks applicable to master components - the API server, controller manager, scheduler, and etcd - and outputs a PASS/FAIL/WARN result for each numbered control, making it the correct tool and invocation for this task.

   Why the other options are wrong

   • Akubectl audit cis --node master is not a valid kubectl subcommand; kubectl does not have a built-in CIS benchmarking capability.
   • Btrivy cluster --benchmark cis is not a valid trivy invocation; Trivy is primarily a vulnerability scanner for container images, filesystems, and repositories - not a live CIS node benchmark runner.
   • Ckubeadm check cis is not a real kubeadm subcommand; kubeadm handles cluster bootstrapping and upgrades but has no built-in CIS benchmark checking functionality.
2. Question 2Cluster Hardening

   A user submitted a CertificateSigningRequest for a client cert and you've validated their identity. Which command approves it so a certificate is issued?

   • Akubectl csr sign <csr-name>
   • Bkubectl certificate issue <csr-name>
   • Ckubectl approve csr <csr-name>
   • Dkubectl certificate approve <csr-name>Correct
   ✓ Correct answer: D

   CertificateSigningRequest objects in Kubernetes move through a lifecycle: pending -> approved/denied -> issued. An administrator approves a pending CSR using kubectl certificate approve <name>, which sets the Approved condition on the object. A configured signer (such as the built-in kubernetes.io/kube-apiserver-client signer) then issues the signed certificate and populates the status.certificate field, from which the requester can retrieve it. The companion command kubectl certificate deny rejects a request. None of the other command forms shown are valid kubectl subcommands.

   Why the other options are wrong

   • Akubectl csr sign <csr-name> is not a valid kubectl command - there is no csr subcommand on kubectl; CertificateSigningRequests are managed through the certificate subcommand.
   • Bkubectl certificate issue <csr-name> is not a valid kubectl command - the certificate subcommand supports only approve and deny; actual certificate issuance is performed automatically by a signer after approval.
   • Ckubectl approve csr <csr-name> reverses the correct command structure - the top-level subcommand is certificate, and approve is the action under it; kubectl approve is not a valid kubectl verb.
3. Question 3System Hardening

   Why is allowing hostIPC: true on pods a hardening concern?

   • AIt shares the host's IPC namespace, letting the container access host shared memory/semaphores and potentially other processes' dataCorrect
   • BIt shares the host's network namespace, exposing the node's listening ports and interfaces directly to the pod's containers
   • CIt shares the host's PID namespace, letting the container see and send signals to processes running on the node
   • DIt bind-mounts the host's /dev/shm read-write into every container so they can exchange data through it
   ✓ Correct answer: A

   Linux IPC namespaces isolate System V IPC objects (shared memory segments, semaphores, message queues) and POSIX message queues. When hostIPC: true is set on a pod, the container joins the host's IPC namespace instead of its own, gaining visibility to and the ability to interact with all IPC objects on the host. This can expose sensitive data from other processes, allow inter-process attacks via shared memory, and break the isolation boundary between containers and the host. The baseline Pod Security Standard explicitly forbids hostIPC: true for this reason.

   Why the other options are wrong

   • BSharing the host network namespace is hostNetwork, not hostIPC; hostIPC specifically shares System V IPC and POSIX shared memory, not the node's network ports
   • CSeeing and signalling host processes comes from hostPID, which shares the process namespace; hostIPC shares the inter-process communication namespace instead
   • DhostIPC shares the IPC namespace itself rather than performing a /dev/shm bind mount; the concern is direct access to host shared memory and semaphore objects
4. Question 4Minimize Microservice Vulnerabilities

   You must guarantee every admitted pod sets a securityContext with runAsNonRoot and no privilege escalation, even from third-party Helm charts. Which is the most robust enforcement?

   • APod Security Admission 'restricted' on the namespace (and/or a policy engine), since it validates at admission regardless of how the pod is createdCorrect
   • BA MutatingWebhook that patches runAsNonRoot and allowPrivilegeEscalation into every chart as it renders, silently fixing pods before admission
   • CA Helm post-render hook that rewrites the securityContext values before install so every chart ships with runAsNonRoot enabled by default
   • DAn OPA Gatekeeper policy running in audit mode that reports non-compliant pods after they run so operators can remediate them afterward
   ✓ Correct answer: A

   Pod Security Admission (PSA) enforces the Pod Security Standards via a built-in admission controller that evaluates every pod creation or update against the policy level configured on the namespace label. Setting a namespace to the restricted level causes PSA to reject any pod - whether created via kubectl, Helm, a controller, or a CRD - that does not meet the standard (including runAsNonRoot and allowPrivilegeEscalation: false). Policy engines like Kyverno or OPA Gatekeeper provide equivalent admission-time enforcement with more flexibility.

   Why the other options are wrong

   • BA mutating webhook silently changes fields rather than guaranteeing the author set them, and setting runAsNonRoot alone does not cover allowPrivilegeEscalation; it also cannot block a pod that fails other constraints.
   • CA Helm post-render hook only affects installs done through that Helm workflow; pods created by other clients or controllers bypass it entirely, so it is not a robust cluster gate.
   • DAudit-mode policy only reports violations after admission; the non-compliant pod still runs, so it does not guarantee every admitted pod meets the securityContext requirements.
5. Question 5Supply Chain Security

   You attached an SBOM as an attestation. Which cosign flag verifies a specific predicate type (e.g., SPDX SBOM)?

   • Acosign verify --attestation-type <predicate-type> <image>
   • Bcosign verify --predicate <predicate-type> --key cosign.pub <image>
   • Ccosign verify-attestation --type <predicate-type> --key cosign.pub <image>Correct
   • Dcosign attest --verify --type <predicate-type> <image>
   ✓ Correct answer: C

   cosign verify-attestation accepts a --type flag that specifies the in-toto predicate type to filter and verify, such as 'spdx', 'cyclonedx', or 'slsaprovenance'. This ensures you are verifying an attestation of the expected kind (e.g., an SPDX SBOM) rather than a different predicate that happened to be attached. The --key flag provides the public key for signature verification, and together they confirm both the authenticity and the content type of the attestation.

   Why the other options are wrong

   • Acosign verify checks image signatures, not attestations, and has no --attestation-type flag; verifying an attestation predicate requires the verify-attestation subcommand.
   • Bcosign verify (signature verification) does not take a --predicate filter; the predicate-type filter belongs to verify-attestation via its --type flag.
   • Dcosign attest creates attestations and has no --verify mode; verifying a specific predicate type is done with verify-attestation --type.
6. Question 6Monitoring, Logging and Runtime Security

   Which audit-log pattern could indicate an attacker cleaning up after themselves?

   • AUnexpected delete operations on Secrets, pods, or audit/log resources by an unusual identityCorrect
   • BRoutine node status heartbeats sent by each kubelet to renew its Lease and report the node is ready
   • CA controller listing pods during its reconcile loop, a normal read-only call it makes constantly
   • DA user reading their own ConfigMap, an authorized read within the RBAC scope granted to them
   ✓ Correct answer: A

   After achieving their objective, attackers frequently attempt to destroy evidence by deleting Secrets they exfiltrated, removing pods they used as a foothold, or wiping logging-related resources to frustrate investigation. In the audit log this shows as delete verbs on sensitive resources performed by an identity that does not normally perform such deletions. Correlating the actor, resource, and timing distinguishes malicious cleanup from legitimate administrative housekeeping. This anti-forensic pattern is a strong indicator that a compromise is being actively concealed.

   Why the other options are wrong

   • BNode heartbeats are expected periodic status updates from kubelets; they delete nothing and are not evidence of an attacker erasing traces.
   • CA controller listing pods is normal read-only reconcile activity; cleanup by an attacker is characterized by unexpected deletes, not routine list calls.
   • DA user reading their own ConfigMap is authorized read access within scope; it removes no resources and is not track-covering behavior.
7. Question 7System HardeningSelect all that apply

   You are hardening worker nodes against container breakout and unauthorized local access. Which TWO node-OS measures meaningfully reduce risk? (Choose TWO)

   • AEnable SELinux or AppArmor in enforcing mode on the hostCorrect
   • BRestrict SSH access to key-based authentication and a bastion, disabling password loginCorrect
   • CRun the kubelet with --anonymous-auth=true for convenience
   • DGive every node a static long-lived admin kubeconfig on disk
   ✓ Correct answer: A, B

   SELinux/AppArmor in enforcing mode confines processes and limits breakout damage at the host level. Restricting SSH to key-based authentication through a bastion removes password-guessing and broad remote access vectors. Together they shrink the host attack surface.

   Why the other options are wrong

   • C--anonymous-auth=true lets unauthenticated clients hit the kubelet API, a serious weakness.
   • DStoring a long-lived admin kubeconfig on every node creates a high-value credential an attacker can steal.
8. Question 8Monitoring, Logging and Runtime Security

   You must ensure audit logs survive a node compromise where the attacker has root on the control-plane host. Which design most directly prevents local tampering with already-recorded events?

   • AStream events via the audit webhook to an external, append-only/immutable log store outside the node's controlCorrect
   • BEncrypt the on-disk audit log with a key stored in the same node's filesystem
   • CRestrict the audit log file with chattr +i so root cannot modify it
   • DWrite the audit log to a hostPath volume backed by the node's local SSD
   ✓ Correct answer: A

   If logs only live on the compromised host, a root attacker can edit or delete them. Forwarding via the webhook backend to an immutable, access-controlled external sink (WORM storage / SIEM) preserves forensic integrity beyond the attacker's reach.

   Why the other options are wrong

   • Ba root attacker on the host can read the key stored on the same node and decrypt or rewrite the log, so local encryption does not prevent tampering by a local root
   • Cchattr +i can be cleared by root with chattr -i, so an attacker with root on the host can remove the immutable flag and alter the file
   • Dany log kept on the node's local disk is fully modifiable by a root attacker on that host; durability against a node compromise requires shipping events off the node
9. Question 9System Hardening

   You apply a securityContext with seccompProfile.type: RuntimeDefault, but a Pod still appears to allow a syscall you expected the default profile to block. Which is the most likely accurate reason?

   • AThe container runtime's default profile is an allowlist tuned for compatibility and intentionally permits many syscalls; for tighter control you need a custom Localhost profileCorrect
   • BRuntimeDefault only takes effect if the pod also explicitly sets privileged: false in the securityContext, which was likely left unset here so the seccomp profile never engaged
   • CThe node kernel must be booted with the seccomp=2 parameter, or RuntimeDefault silently degrades to Unconfined at container start and ends up filtering no syscalls at all
   • DRuntimeDefault applies its syscall filter only to the pause/sandbox container, not to the application containers, so the app container's syscalls pass through unfiltered by design
   ✓ Correct answer: A

   RuntimeDefault uses the container runtime's general-purpose profile, which blocks clearly dangerous syscalls but permits a large set so that most workloads run unmodified. If you need to deny additional specific syscalls, you author a custom seccomp profile and reference it with type: Localhost. RuntimeDefault is a strong, low-effort baseline but not a fully minimized allowlist.

   Why the other options are wrong

   • BRuntimeDefault applies regardless of the privileged setting for the field itself; privileged affects capabilities and device access, but the reason a syscall is still allowed is that the default profile permits it by design
   • Cmodern kernels used by Kubernetes have seccomp support compiled in; RuntimeDefault does not silently downgrade to Unconfined, so the permitted syscall is due to the profile's broad allowlist
   • DRuntimeDefault is applied to the application containers, not just the pause container; the syscall is permitted because the default profile is intentionally broad, not because app containers are exempt
10. Question 10Supply Chain SecuritySelect all that apply

    You are configuring the built-in ImagePolicyWebhook admission controller to whitelist registries. Which statements about this controller are correct? (Choose two.)

    • AThe API server must be started with --admission-control-config-file pointing to a config that references the webhook kubeconfigCorrect
    • BWhen the backend is unreachable, the defaultAllow setting in the admission config decides whether requests are admitted or deniedCorrect
    • CImagePolicyWebhook decisions are made by inspecting the image's signature payload embedded in the API server binary
    • DThe webhook is enabled by adding it to the kubelet's --feature-gates flag on each node
    ✓ Correct answer: A, B

    You enable ImagePolicyWebhook in --enable-admission-plugins and point --admission-control-config-file at an AdmissionConfiguration referencing the ImagePolicyWebhook kubeconfig and options. The defaultAllow field determines whether pods are admitted (true) or rejected (false) when the external policy backend cannot be reached, so setting it to false fails closed.

    Why the other options are wrong

    • CThe controller calls an external HTTP backend with an ImageReview; it does not read signatures baked into the API server.
    • DImagePolicyWebhook is an API server admission plugin, not a kubelet feature gate.

Related Cloud Native resources

• CKS study guideKey concepts
• Cloud Native practice examsAll Cloud Native
• Certification pathWhere this fits
• Certification exam guides & tipsBlog
• Plans & pricingFree & paid
• KCSA practice examRelated
• CKA practice examRelated
• KCNA practice examRelated

CKS practice exam FAQ