Reinforce CKS concepts with active-recall study cards covering all 6 blueprint domains. Each card shows the question on the front and the correct answer with a full explanation on the back.
Flashcards work through active recall — the process of retrieving information from memory rather than passively re-reading it. Research consistently shows that active recall produces stronger, longer-lasting memory than re-reading study guides. For CKS preparation, this means flashcards are one of the highest-return study tools available.
Attempt recall first
Read the CKS question on each card, pause, and attempt to formulate the answer in your own words before revealing. This retrieval attempt — even if wrong — dramatically strengthens memory compared to immediately reading the answer.
Review wrong cards again
When you get a card wrong, note it and add it back to your review pile. Spaced repetition — seeing difficult cards more frequently — is the mechanism that makes flashcard study far more efficient than linear reading.
Study by domain
Group your CKS flashcard sessions by domain for the first 3–4 weeks. Master one domain before moving to the next. In the final week, shuffle all cards together to test cross-domain recall — which is what the real CKS exam requires.
Short sessions beat marathon reviews
20–30 flashcard cards per session, done daily, produces better retention than a single 200-card marathon session. Five short daily sessions per week over 4 weeks gives you over 400 total card reviews — enough to reliably pass CKS.
Sample cards from the CKS flashcard bank. Read the question, think of the answer, then read the explanation below.
A microservice running as a Deployment in a Kubernetes cluster needs to authenticate to a third-party API using a static API key. Which is the most secure way to store and inject this secret into the container?
Store the API key in a Kubernetes Secret and mount it as a volume inside the container
Mounting a Kubernetes Secret as a volume provides the most secure method for injecting sensitive data into a container. Unlike environment variables, which can be exposed through process listings, container logs, or `/proc` filesystem, a volume mount stores the secret in the container's filesystem with permissions restricted to the runtime user. This approach also supports automatic rotation of secret values without restarting the pod, as the filesystem is updated in place when the Secret object changes.
During a security audit, a team discovers that their microservice application, deployed on Kubernetes, is vulnerable to container breakout attacks. The containers run as root and have many Linux capabilities. Which set of Pod Security Standards (PSS) enforcement modes and policies would best mitigate this risk?
Use 'restricted' PSS with Enforce mode
The 'restricted' Pod Security Standard with 'Enforce' mode is the correct choice because it mandates the most stringent security controls, including dropping all Linux capabilities and preventing containers from running as root. This directly mitigates container breakout attacks by eliminating the excessive privileges that enable such exploits. 'Enforce' mode actively blocks non-compliant pods, ensuring the policy is applied without relying on user awareness or audit logs.
A DevOps engineer wants to ensure that all microservice containers run with a read-only root filesystem to prevent unauthorized writes. What is the simplest way to enforce this at the Pod level?
Set `securityContext.readOnlyRootFilesystem: true` in the Pod spec
Setting `securityContext.readOnlyRootFilesystem: true` in the Pod spec directly enforces that the container's root filesystem is read-only, preventing any unauthorized writes to the root filesystem. This is the simplest and most direct way to achieve the requirement at the Pod level, as it applies to all containers in the Pod unless overridden at the container level.
A DevOps team wants to ensure that only signed images from a trusted registry are deployed in the cluster. They plan to use a webhook to intercept pod creation. Which tool is best suited for this task?
Kyverno with a verifyImages rule
Kyverno is a Kubernetes-native policy engine that can enforce image signature verification via its `verifyImages` rule. It intercepts pod creation through a dynamic admission webhook, checking that container images are signed with a trusted key (e.g., using Sigstore/Cosign) before the pod is admitted. This directly meets the requirement to only allow signed images from a trusted registry.
A security audit reveals that a container image running in production contains a critical vulnerability (CVE-2024-1234). The image was built from a base image that had the vulnerability. What is the MOST effective long-term solution to prevent such issues?
Rebuild the image using a patched base image and integrate vulnerability scanning into the CI pipeline.
The most effective long-term solution because it addresses the root cause by rebuilding the image from a patched base image, eliminating the vulnerability at the source. Integrating vulnerability scanning into the CI pipeline ensures that future images are automatically checked for known CVEs before deployment, preventing vulnerable images from reaching production. This aligns with the principle of shifting security left in the software supply chain.
An organization uses a private container registry and wants to ensure that only images built from a specific CI/CD pipeline are deployed. Which combination of measures provides the strongest guarantee?
Generate signed attestations with in-toto during the CI pipeline and verify them using an admission webhook like Kyverno.
It implements a complete chain of custody for container images. In-toto generates signed attestations that record every step of the CI/CD pipeline (e.g., source code checkout, build, test), and an admission webhook like Kyverno verifies these attestations before allowing a pod to run. This ensures that only images that passed the exact, attested pipeline are deployed, providing the strongest guarantee against unauthorized or tampered images.
A Falco rule is written to detect when a shell is spawned inside a container. The rule condition is: `spawned_process and container and proc.name = bash`. The rule is not triggering. Which of the following is the most likely reason?
The `spawned_process` macro may not match because the process was inherited (not spawned), e.g., from an entrypoint
The `spawned_process` macro in Falco specifically matches processes that are created via `execve` or `fork` system calls. If a shell is inherited from the container's entrypoint (e.g., the container runs `bash` as PID 1 directly), it is not considered a spawned process but rather the initial process of the container. Falco's default `spawned_process` macro filters out such inherited processes, so the rule condition fails to match even though `proc.name = bash` is true.
You are configuring Kubernetes audit logging. You want to log all requests to the `secrets` resource in the `kube-system` namespace at the `RequestResponse` level, while logging all other requests at the `Metadata` level. Which audit policy configuration achieves this?
rules: [- level: RequestResponse, resources: [group: '', resources: [secrets]], namespaces: [kube-system], - level: Metadata]
It defines an audit policy rule that matches requests to the `secrets` resource (core API group, empty string) in the `kube-system` namespace and sets the audit level to `RequestResponse`, which logs both the request metadata and the response body. The subsequent `- level: Metadata` rule acts as a catch-all for all other requests, logging only metadata. Audit policy rules are evaluated in order, and the first matching rule applies, so the specific rule for secrets must come before the general rule.
You have deployed a pod and set `securityContext.readOnlyRootFilesystem: true`. The pod is failing to start with an error about writing to `/tmp`. What is the most likely cause?
The pod is missing an emptyDir volume mounted at `/tmp`
When `securityContext.readOnlyRootFilesystem: true` is set, the container's root filesystem becomes read-only. Many applications, including those that write temporary files, expect to write to `/tmp`. Without a writable volume mounted at `/tmp`, the container fails to start because it cannot write to that directory. Mounting an `emptyDir` volume at `/tmp` provides a writable location that is ephemeral and tied to the pod's lifecycle, resolving the issue.
A security team is hardening a Kubernetes cluster. They need to ensure that all control plane components run with the least privilege. Which approach should they take?
Configure control plane containers to run as non-root user and with read-only root filesystem
Running control plane containers as a non-root user and with a read-only root filesystem directly enforces the principle of least privilege at the container level. This approach limits the ability of an attacker who compromises a control plane component to escalate privileges or modify critical system files, which is a fundamental hardening requirement for the control plane.
A team needs to set up a highly available Kubernetes control plane across three availability zones. What is the minimum number of etcd members required to achieve fault tolerance against one zone failure?
3
For a highly available Kubernetes control plane across three availability zones, the etcd cluster must tolerate the loss of one entire zone. With three etcd members, one per zone, the cluster requires a majority (2) to form quorum. If one zone fails, the remaining two members still constitute a majority, ensuring continued operation. This matches the minimum odd number greater than one that provides fault tolerance against a single failure.
A security audit reveals that the kube-apiserver is using the default insecure port 8080 on a production cluster. Which is the most secure and recommended remediation?
Set --insecure-port=0 and ensure --secure-port=6443 is configured
Setting `--insecure-port=0` disables the unencrypted HTTP port (default 8080), which eliminates the risk of unauthenticated access to the API server. Ensuring `--secure-port=6443` is configured enforces TLS-encrypted communication on the standard secure port, which is the only recommended and secure method for production clusters.
A security team wants to ensure that all pods in a namespace run with a restricted seccomp profile. Which Pod Security Standard admission controller mode should be used to enforce this without blocking necessary pods?
Enable the PodSecurity admission plugin with the 'restricted' policy and 'enforce' mode
The Pod Security Standards (PSS) define three policies: privileged, baseline, and restricted. The restricted policy enforces the most stringent security controls, including requiring a seccomp profile to be set to 'RuntimeDefault' or 'localhost/*'. Using the PodSecurity admission plugin with 'enforce' mode ensures that any pod failing the restricted policy is immediately rejected, guaranteeing that only compliant pods run in the namespace.
A cluster uses RBAC and a ServiceAccount 'monitor' in namespace 'observability'. The account needs to list pods in all namespaces. Which ClusterRole and binding should be created?
ClusterRole with 'list' on pods, ClusterRoleBinding
A ServiceAccount that needs to list pods across all namespaces requires a ClusterRole with the 'list' verb on pods, because ClusterRoles are not namespaced and can grant permissions cluster-wide. A ClusterRoleBinding is necessary to bind that ClusterRole to the ServiceAccount, as RoleBindings only apply within a single namespace and cannot grant cluster-scoped permissions.
The CKS flashcard bank covers all 6 official blueprint domains published by CNCF. Cards are distributed proportionally, so domains with higher exam weight have more cards.
Domain Coverage
Minimize Microservice Vulnerabilities
Supply Chain Security
Monitoring, Logging and Runtime Security
System Hardening
Cluster Setup
Cluster Hardening
Both flashcards and practice questions are evidence-based study tools. The difference is in what they train:
Flashcards — concept retention
Best for memorising definitions, acronyms, protocol behaviours, command syntax, and conceptual distinctions. Use flashcards to build the foundational vocabulary that CKS questions assume you know.
Best in: weeks 1–3
Practice tests — application
Best for applying concepts to realistic scenarios, eliminating distractors, and building exam stamina.CKS questions test scenario reasoning — not just recall — so practice tests are essential.
Best in: weeks 3–6
The most effective CKS study plan combines both: use flashcards for the first 2–3 weeks to build conceptual foundations, then shift to practice tests and mock exams in the final 2–3 weeks to apply and benchmark that knowledge. Most candidates who pass on their first attempt use both tools.
Yes. Courseiva provides free CKS flashcards across all official exam domains. Every card includes the correct answer and a full explanation of why it is right and why the distractors are wrong. The platform also includes topic-based practice, mock exams, and readiness tracking — no account required.
Courseiva has 845+ original CKS flashcards across all 6 exam blueprint domains. New cards are added regularly as the question bank grows. All cards are checked against the official CNCF exam objectives, with editorial oversight from an experienced network and security engineer.
Courseiva flashcards are purpose-built for IT certification exams. Unlike generic flashcard platforms where content quality varies, every Courseiva card is mapped to the official CKS exam blueprint, written by engineers who hold the certification, and includes a full explanation of the correct answer and why the distractors are wrong. This explanation quality is what separates genuine learning from rote memorisation.
Courseiva is a web platform — an internet connection is required. For offline study, we recommend creating free Courseiva account, using the platform in your browser, and using your device's offline capabilities if your browser supports offline web apps.
Save your results, see which domains need more work, and get spaced repetition recommendations — all free.
Sign Up FreeFree forever · Every certification included