CKS Exam Questions and Answers

Store the API key in a Kubernetes Secret and mount it as a volume inside the container

Mounting the Secret as a volume avoids exposing the API key in environment variables, which can leak via process listings or crash dumps. It satisfies the requirement for secure injection into the container without baking credentials into the image or manifest.

Use 'restricted' PSS with Enforce mode

Restricted profile in Enforce mode is the only combination among the choices that both selects the strongest pod-hardening policy and actually enforces it at admission time. Restricted requires runAsNonRoot=true, sets seccompProfile to RuntimeDefault, drops all capabilities except NET_BIND_SERVICE, and mandates a read-only root filesystem, which together deprive an attacker of the most common kernel exploits. Because Enforce mode rejects non-compliant pods before they are created, there is no opportunity for a restricted-violating pod to run and escape.

Set `securityContext.readOnlyRootFilesystem: true` in the Pod spec

Setting readOnlyRootFilesystem: true instructs the container runtime to mount the container's root filesystem as read-only, so no process can create, delete, or modify files in the root layer. This is the precise securityContext field that the requirement asks for, and it works regardless of the UID the container runs as. Any process that needs to write temporary data must have explicit writable volumes, such as emptyDir, mounted over required paths.

Apply a custom seccomp profile that blocks the vulnerable syscall

A custom seccomp profile restricts the set of syscalls a process may make, and if the scanner mapped the library CVE to a specific syscall, denying that syscall creates a direct mitigation at the kernel boundary. Even when the vulnerable library remains in the image, the exploit cannot complete because the necessary syscall is rejected with EPERM. This is the only option that acts directly on syscall invocation.

Add `NET_RAW` capability

NET_RAW allows raw sockets; TCP DNS uses standard sockets, so this is unnecessary.

Use minimal base images (e.g., distroless or scratch) to reduce attack surface

Minimal images like distroless or scratch contain only the essential runtime dependencies, excluding shells, package managers, and superfluous utilities. This dramatically shrinks the attack surface available to an attacker who gains code execution, limiting exploitation capabilities and reducing the number of CVEs that can affect the image. Fewer components also mean fewer packages to monitor and patch in the base layer.

Scan images for vulnerabilities using tools like Trivy or Clair

Vulnerability scanning queries known CVE databases to enumerate flaws in the image's OS packages and application dependencies before deployment. Automating these scans in the CI pipeline and admission control allows you to block images that exceed the risk threshold and alert on newly disclosed vulnerabilities in running workloads. This gives continuous visibility into your image security posture.

Enable image verification using digital signatures (e.g., Notary or Cosign)

Digital signatures provide cryptographic assurance that an image was produced and signed by a trusted identity and that its contents have not been altered after signing. By integrating verification with admission controllers like OPA or Kyverno, you can enforce that only signed images from approved signers are deployed. This prevents tampering in the registry and supply-chain attacks that modify image content.

Scan images for vulnerabilities in a CI pipeline before deploying.

Scanning images for known vulnerabilities in CI, using tools like Trivy or Grype, catches flaws in OS packages and language dependencies before they reach production. Integrate these scans with policy checks that fail the build on critical or high severity CVEs, and also rescan base images on a schedule, since new vulnerabilities are disclosed after the image is built. This is a reactive measure against known issues, distinct from verifying who built the image or that it hasn't been altered.

Use image signing and verification (e.g., with cosign) to ensure image integrity.

Image signing with cosign cryptographically binds the image manifest to a key held by the publisher, proving identity and origin. Verify the signature in the Kubernetes cluster using an admission controller, such as Kyverno or OPA Gatekeeper, to reject unsigned or tampered images; consider holding keys in a KMS like Vault or AWS KMS. Signing addresses integrity and provenance, whereas vulnerability scanning only identifies known flaws, not whether the artifact is authentic.

Kyverno with a verifyImages rule

Kyverno with a verifyImages rule is correct because Kyverno runs as a dynamic admission controller inside the cluster and intercepts Pod creation requests before they are persisted. The verifyImages rule leverages cosign to check each container image's digital signature against the specified public keys, failing admission if the signature is missing or invalid. This enforces a policy that only signed images from trusted registries can run, at the exact point Kubernetes decides to allow the workload.

Rebuild the image using a patched base image and integrate vulnerability scanning into the CI pipeline.

Rebuilding the image from a patched base image directly eliminates the vulnerable package from the image filesystem, ensuring that the vulnerability is no longer present in the artifact itself. Integrating vulnerability scanning into the CI pipeline shifts security left, allowing teams to detect and block vulnerable images before they are pushed to a registry or deployed. This approach is sustainable and reproducible, as every build is validated and known vulnerabilities trigger a pipeline failure, forcing developers to update dependencies promptly. It addresses the source of the issue rather than applying after-the-fact controls.

Generate signed attestations with in-toto during the CI pipeline and verify them using an admission webhook like Kyverno.

In-toto attestations are cryptographically signed metadata generated during the CI pipeline that describe the build steps, materials, and results, providing non-repudiation for the image's origin. An admission webhook such as Kyverno can be configured to verify these signatures and attestations at admission time, ensuring that only images produced by the trusted pipeline and with valid provenance are allowed to run. This combination enables robust supply-chain security by tying the runtime state to an auditable, tamper-evident build process.

Update the image tag in each Deployment's spec to point to the new patched image, then perform a rolling update. The admission controller will verify signatures and attestations for the new image.

Updating the image tag in each Deployment's PodTemplateSpec is the correct declarative approach: it triggers a rolling replacement of the underlying ReplicaSets, so old pods are terminated only after new ones become Ready. During pod creation, the cluster's validating/mutating admission controller (e.g., Kyverno or OPA via cosign) checks the image's cryptographic signature and attestations; if the patched image is signed and passes policy, the update proceeds. This ensures every pod runs a verified, patched image with zero downtime.

Integrate an image scanner (e.g., Trivy) into the CI/CD pipeline to block builds with critical vulnerabilities.

Integrating a scanner like Trivy into the CI/CD pipeline creates a build-time quality gate: it scans the final image after all layers are assembled and fails the pipeline if critical vulnerabilities are found, so vulnerable images are never pushed to the container registry. This shift-left approach automates prevention at the earliest practical stage and provides a clear signal to developers before the image reaches deployment. This is the recommended primary control for supply chain security.

The `spawned_process` macro may not match because the process was inherited (not spawned), e.g., from an entrypoint

The `spawned_process` macro is defined to match processes whose parent is a shell, i.e., processes created via `fork` and `exec` from an interactive or scripted shell. When a container runs an entrypoint that directly exec's a shell as PID 1, the parent of that shell is the container runtime or init process, not another shell. As a result, the `proc.pname` check inside the macro fails, and the rule never matches even though the shell is present. In such cases, the shell is inherited rather than spawned, so a rule relying on `spawned_process` will not fire.

rules: [- level: RequestResponse, resources: [group: '', resources: [secrets]], namespaces: [kube-system], - level: Metadata]

Audit policy rules are evaluated in order, first match wins. Placing the RequestResponse rule for secrets in kube-system first captures that resource at full detail, while the trailing Metadata rule acts as the catch-all for every other request, satisfying both logging requirements in one policy.

The pod is missing an emptyDir volume mounted at `/tmp`

The correct fix is to create a dedicated emptyDir volume and mount it at /tmp. When readOnlyRootFilesystem is true, the container's root filesystem is mounted with the MS_RDONLY flag, so every write attempt to any path on that filesystem returns EROFS — regardless of permissions. An emptyDir volume provides a separate, writable filesystem (initially empty, typically backed by the node's disk or tmpfs) that can be mounted exactly where the application expects to write temporary data, allowing the container to work while preserving the immutability of the root filesystem.

connect

The connect syscall establishes a connection between a socket and a remote address; for curl, this is the exact moment the TCP handshake begins with the destination web server. When tracing system calls, connect is the first syscall that carries the remote IP and port, so it directly identifies the outbound HTTP request. Thus, of the listed options, connect is the correct syscall to monitor for this network activity.

evt.type=open and fd.name=/etc/shadow

The `open` syscall is the initial operation that must occur before any file content can be read or modified; when a process calls `open` on `/etc/shadow`, Falco's `fd.name` is populated directly from the path argument, making this condition both reliable and comprehensive. This rule detects any attempt to open the shadow file, regardless of the intended operation (read, write, or execute) and regardless of the process name or container name. It is the precise, minimal condition that catches unauthorized access to sensitive credential files, and it is the standard cornerstone for such Falco rules.

kubectl label pod compromised-pod isolated=true && kubectl apply -f networkpolicy.yaml

Ly identifies the need to label the pod and apply a deny-all NetworkPolicy. The command sequence is impractical (busybox lacks kubectl), but the concept is what the exam tests. In a real scenario, you would label the pod directly and then apply the policy.

Configure control plane containers to run as non-root user and with read-only root filesystem

Setting runAsNonRoot: true and an explicit runAsUser (for example, 1000) in the pod security context, along with readOnlyRootFilesystem: true, directly removes root privileges and makes the container's immutable root filesystem fail-closed on any write attempt. This is the most effective hardening for control plane components because it attacks both privilege escalation and tampering of the container's filesystem at the source, rather than filtering specific kernel or program actions.

PodSecurity

PodSecurity is the correct answer because it is a built-in admission controller that enforces the Pod Security Standards, specifically the 'restricted' profile, which mandates that containers run as a non-root user (e.g., runAsNonRoot: true and runAsUser set to a non-zero ID). It validates the Pod's securityContext during creation and rejects any Pod that attempts to run as root. This directly implements the administrator's policy to restrict root execution.

Set securityContext.allowPrivilegeEscalation: false

Setting allowPrivilegeEscalation: false directly applies the Linux 'no_new_privs' flag to the container process, which prevents the process and its children from ever gaining more privileges than their original execution context, even if a later exec of a setuid-root or capability-enabled binary occurs. This is a kernel-level mechanism that blocks the common privilege-escalation vectors such as SUID binaries, file capabilities, and certain ioctl-based operations. It is the most direct security control among the options because it explicitly targets the privilege-escalation mechanism itself, rather than only constraining the user ID, filesystem, or capabilities. For this compromised container, this setting is necessary to contain the breach and prevent further elevation.

Enable PodSecurity admission controller with baseline or restricted profile

Pod Security Admission (PSA) is the built-in admission controller that enforces the Pod Security Standards, and both the `baseline` and `restricted` policies require `hostNetwork` to be set to `false` (with `restricted` also forbidding other host namespaces). By applying a PSA level of `baseline` or `restricted` at the cluster, namespace, or label-based level, the API server will reject any new pod that tries to use host networking. This is the recommended, current replacement for the removed PodSecurityPolicy, and it directly blocks the offending capability. Note that PSA only applies to newly created pods, so existing pods must be recreated or patched to bring them into compliance.

Enable ImagePolicyWebhook admission controller

ImagePolicyWebhook is an admission controller that intercepts Pod create and update operations and sends an ImageReview payload containing each container's image name to an external HTTP/HTTPS service. The webhook responds with an admission decision, allowing an administrator to reject any image that doesn't come from a trusted registry, tag, or digest. This is the standard built-in mechanism for applying a centralized, registry-aware image policy to every Pod submitted through the API server.

SYS_ADMIN, SYS_MODULE, SYS_PTRACE

These capabilities permit privileged kernel operations: SYS_ADMIN enables mount and namespace manipulation, SYS_MODULE loads kernel modules, and SYS_PTRACE inspects other processes. Dropping them removes the primitives container escapes rely on, satisfying the stem's requirement to restrict host kernel access.

3

Three control plane nodes are the minimum required for high availability because etcd quorum for a 3-node cluster is two, meaning the cluster can survive the loss of one node. With only two nodes, a single failure would leave one node and no majority, so three is the smallest odd number that provides fault tolerance. This is the standard recommendation for production Kubernetes control planes.

Set --insecure-port=0 and ensure --secure-port=6443 is configured

Setting --insecure-port=0 disables the plaintext HTTP endpoint on the kube-apiserver, eliminating unauthenticated access. Simultaneously ensuring --secure-port=6443 is configured guarantees that all API communication is served over TLS on the standard secure port, using client certificate and token authentication. This combination is the recommended hardening measure per Kubernetes documentation.

/etc/kubernetes/manifests/

/etc/kubernetes/manifests/ is the default static pod manifest directory in a kubeadm cluster. The kubelet watches this directory for YAML/JSON files and automatically creates and manages the pods they define, which is how the control plane components (kube-apiserver, kube-controller-manager, kube-scheduler, and etcd) are launched. This directory is the correct place for these manifests because the kubelet's staticPodPath is set to this location during kubeadm initialization, making it the source of truth for the control plane pods.

--kubeconfig

The --kubeconfig flag is the correct mechanism because the kubeconfig file defines the API server endpoint (typically an HTTPS URL), the CA certificate used to verify the server, and the kubelet's client credentials for authentication. When the kubelet starts with --kubeconfig, it uses this file to establish a mutually authenticated, TLS-encrypted connection to the API server. Requiring a kubeconfig that points to the API server over HTTPS ensures all control-plane traffic from the kubelet is encrypted in transit.

1. Generate a new certificate and key pair for the API server. 2. Replace the existing certificate files on the control plane node. 3. Restart the kube-apiserver process or container. 4. Verify the new certificate is serving correctly using curl or openssl.

This is the correct order because the new certificate must be generated first, then its files must replace the old ones, the API server must be restarted to load the new certificate, and finally verification ensures the process succeeded.

NodeRestriction: Limits the permissions of kubelet nodes to prevent unauthorized operations.

NodeRestriction admission controller is specifically designed to limit the kubelet's permissions on Node and Pod API objects. It ensures that a kubelet can only modify its own Node object and pods bound to it, and cannot add or edit labels, taints, or status fields that could be used to escalate privileges or disrupt the cluster. This prevents a compromised kubelet from impersonating another node or altering critical metadata.

PodSecurity: Enforces Pod Security Standards (privileged, baseline, restricted).

PodSecurity is a built-in admission controller that enforces the Pod Security Standards defined by Kubernetes. It applies the privileged, baseline, or restricted profiles based on the namespace's pod-security labels, and it can either enforce, audit, or warn on policy violations. This controller replaces the deprecated PodSecurityPolicy and validates pod specifications at creation time, refusing or logging workloads that exceed the configured security constraints.

ServiceAccount: Controls automounting of service account tokens to pods.

The ServiceAccount admission controller governs how service account tokens are mounted into pods. It checks the automountServiceAccountToken field on both the pod and the service account, and by default sets a token volume even if no explicit mount is requested. This controller can deny or modify the automount behavior, which is critical for limiting the exposure of the cluster's API credentials to containers that do not need them.

AlwaysPullImages: Forces pods to always pull container images, ensuring no local cached images are used without verification.

AlwaysPullImages is an admission controller that overwrites every pod's imagePullPolicy to Always, regardless of what the user specified. This forces the kubelet to contact the image registry on each container start, preventing the use of potentially stale or tampered images already cached on the node. It is commonly used in multi-tenant clusters to ensure that only registry-defined images run, and that image credentials are always validated for each pull.

Enable the PodSecurity admission plugin with the 'restricted' policy and 'enforce' mode

PodSecurity admission with the 'restricted' policy in 'enforce' mode acts as an admission controller that rejects any pod that fails the restricted profile, including the requirement that seccomp be set to RuntimeDefault or Localhost. This directly blocks non-compliant pods at creation time, ensuring only pods meeting the strict security requirements run in the namespace. Enforce mode is the only mode that provides hard enforcement, making this the correct choice.

ClusterRole with 'list' on pods, ClusterRoleBinding

A ClusterRole is not bound to any namespace, and a ClusterRoleBinding grants its permissions cluster-wide or across all namespaces. By combining the 'list' verb on pods with these two cluster-scoped resources, the monitor ServiceAccount can list pods in every namespace. This is the standard and correct way to grant cross-namespace pod enumeration in RBAC.

runAsNonRoot: true

When set to true, this securityContext field enforces at admission and runtime that the container's UID is non-zero. If the image's configured user or an explicit runAsUser is 0, Kubernetes will refuse to start the pod, producing a CreateContainerConfigError or validation failure. This directly meets the requirement to prevent pods from running as root, making it the correct choice.

Edit the kube-apiserver manifest to add --authorization-mode=Node,RBAC

Editing the kube-apiserver static manifest under /etc/kubernetes/manifests to add --authorization-mode=Node,RBAC is exactly what the CIS benchmark expects. This enables the Node authorizer for kubelet requests and the RBAC authorizer for all other identities, covering the two essential authorization paths. The kubelet will detect the manifest change and restart the API server as a static pod. This is the recommended configuration identified by kube-bench.

Set runAsUser: 1000 in the container securityContext

Setting runAsUser: 1000 in the container's securityContext explicitly forces the container process to run with a non-zero UID, which satisfies the runAsNonRoot: true validation. The kubelet checks that the effective UID of the container is not 0; by fixing the UID to 1000, the check passes while maintaining a secure, non-root execution model. This is the minimal, direct, and security-preserving fix.

NetworkPolicy with egress rules

NetworkPolicy with egress rules is the Kubernetes-native resource for restricting outbound traffic. An egress rule can select target pods via podSelector, namespaceSelector, or CIDR blocks, and also specify allowed ports. This provides API-declarative, label-based access control at L3/L4, enforced by the CNI plugin (e.g., Calico, Cilium). Since NetworkPolicy is a namespaced resource scoped to pods, it is the correct and supported mechanism to directly limit egress within a cluster.