CKS Practice Exam 57 — 20 Questions

Question 1

You are deploying a workload that must be isolated from other workloads on the same node. You want to use a container sandboxing runtime to provide an additional security boundary. Which TWO of the following are true regarding the use of gVisor or Kata Containers in a Kubernetes cluster? (Choose two.)

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

They require a RuntimeClass resource and a corresponding handler configured on the node.. Sandboxed runtimes like gVisor and Kata Containers require a RuntimeClass and a node-level handler to be selected by pods. They add isolation by using a user-space kernel or a lightweight VM, reducing the risk of container escapes. They are not enabled via privileged mode, do not encrypt images, and are not limited to Windows nodes.

Answer

They are only supported on Windows nodes and cannot run on Linux.

Answer

They can be enabled by setting the pod's securityContext.privileged field to true.

Answer

They automatically encrypt all container images at rest on the node.

Question 2

An administrator needs to apply a seccomp profile to a Pod. The profile is defined in a file named audit.json located on each node at /var/lib/kubelet/seccomp/profiles/audit.json. The cluster is running Kubernetes 1.25. Which seccomp type should be used in the Pod's securityContext to reference this profile?

Accepted Answer

Localhost. To use a custom seccomp profile stored on the node, the seccomp type must be set to Localhost, and the localhostProfile field must specify the path relative to the kubelet's seccomp root directory. RuntimeDefault uses a predefined profile, Unconfined disables seccomp, and DockerDefault is not a valid Kubernetes seccomp type. Therefore, Localhost is the correct choice.

Answer

Unconfined

Answer

RuntimeDefault

Answer

DockerDefault

Question 3

A security engineer is hardening a cluster and wants to reduce the attack surface of Pods by restricting their access to host resources. The engineer is reviewing a Pod specification and plans to remove or disable settings that grant host-level access. Which two settings should the engineer remove or set to false to reduce the attack surface? (Choose two.)

Accepted Answer

hostPID: true. The hostNetwork and hostPID fields, when set to true, place the Pod in the host's network and PID namespaces respectively, giving it direct access to host resources and significantly increasing the attack surface. Removing or setting these to false isolates the Pod. The other options either represent secure settings that are already in place or address different security concerns not directly related to host resource access.

Answer

allowPrivilegeEscalation: true

Answer

readOnlyRootFilesystem: false

Answer

privileged: false

Question 4

A Kubernetes cluster uses the ImagePolicyWebhook admission controller to enforce image signature verification. The administrator notices that pods are being admitted even when the webhook backend is unreachable. The cluster is configured with defaultAllow: true in the admission configuration. What is the most likely cause of this behavior?

Accepted Answer

The defaultAllow: true setting in the admission configuration causes the API server to allow pods when the webhook fails to respond.. The defaultAllow field in the ImagePolicyWebhook admission configuration controls whether pods are admitted when the webhook backend is unreachable. When set to true, the API server allows pods on webhook failure, which explains the observed behavior. The other options either do not apply because the webhook is configured and attempted, or they describe different failure modes.

Answer

The webhook backend is not configured with a valid TLS certificate, causing the API server to skip the webhook.

Answer

The ImagePolicyWebhook admission controller is not enabled in the API server's --enable-admission-plugins flag.

Answer

The webhook backend is returning an allow response for all requests due to a misconfiguration in its policy logic.

Question 5

A cluster administrator wants to enforce that all newly created pods in the 'production' namespace run with a read-only root filesystem. The cluster uses Kubernetes 1.25+ and the Pod Security Admission controller is enabled with the baseline and restricted profiles. Which namespace label must be applied to enforce the restricted policy?

Accepted Answer

pod-security.kubernetes.io/enforce: restricted. The Pod Security Admission controller uses namespace labels to enforce policies. The restricted profile mandates a read-only root filesystem. Only the enforce label with value restricted actively blocks non-compliant pods. Audit and warn labels merely log or alert, and baseline is insufficient. Thus, pod-security.kubernetes.io/enforce: restricted is the correct label.

Answer

pod-security.kubernetes.io/audit: restricted

Answer

pod-security.kubernetes.io/enforce: baseline

Answer

pod-security.kubernetes.io/warn: restricted

Question 6

A security team is implementing supply chain security for their Kubernetes cluster. They want to ensure that only container images that have been signed and verified are deployed. They are evaluating admission controllers and tools. Which TWO of the following are valid approaches to enforce image signature verification at admission time? (Choose two.)

Accepted Answer

Use the ImagePolicyWebhook admission controller with a custom webhook that calls cosign verify.. Enforcing image signature verification at admission time can be achieved through the ImagePolicyWebhook admission controller with a custom webhook that calls cosign verify, or through a Kyverno policy that uses the verifyImages rule. Both approaches intercept pod creation and validate image signatures before allowing the pod. The other options do not provide signature verification capabilities.

Answer

Use the PodSecurity admission controller with the restricted profile to enforce image signing.

Answer

Use the NodeRestriction admission controller to restrict which images can be pulled by kubelets.

Answer

Use the AlwaysPullImages admission controller to ensure images are always pulled and verified by the container runtime.

Question 7

A security engineer is configuring a Kubernetes cluster to enforce that all container images are signed by a trusted key before deployment. They deploy the Cosign admission controller and configure it with a public key. However, they notice that some pods are still being admitted with unsigned images. What is the most likely cause?

Accepted Answer

The admission controller's namespaceSelector or objectSelector excludes the namespaces where these pods are being created.. Admission webhooks can be selectively applied based on namespace or object labels. If the namespaceSelector in the webhook configuration does not match the namespaces where pods are created, the webhook is bypassed. This allows unsigned images to be admitted. Checking the webhook's scope is essential to ensure it applies cluster-wide or to all relevant namespaces.

Answer

The Cosign admission controller is configured with a failure policy of Ignore, so if the webhook is unavailable, pods are admitted.

Answer

The container runtime is configured to skip signature verification for images from certain registries.

Answer

The public key used by the admission controller is incorrect, causing it to fail open and admit all images.

Question 8

A CKS candidate is investigating a pod that appears to have been compromised. The incident response team wants to capture the exact system calls made by processes inside the container to understand the attacker's actions. Which Kubernetes-native feature or tool should be used to collect this syscall-level telemetry?

Accepted Answer

Falco with the appropriate kernel module or eBPF probe loaded on the node. Collecting syscall-level telemetry requires a runtime security tool that hooks into the kernel. Falco, using either its kernel module or eBPF probe, observes system calls across all processes on the node, including those inside containers. This allows incident responders to see exactly which syscalls a compromised process invoked, providing the granular data needed for forensic analysis of the attack.

Answer

kubectl debug with a privileged profile attached to the pod

Answer

Container runtime logs collected by the kubelet and exposed via kubectl logs

Answer

Kubernetes audit logging configured with the RequestResponse level

Question 9

A security engineer is using cosign to sign a container image. The engineer runs 'cosign sign --key cosign.key registry.example.com/app:1.0' and receives an error: 'Error: signing [registry.example.com/app:1.0]: getting signer: reading key: PEM decode failed: invalid pem block'. What is the most likely cause of this error?

Accepted Answer

The private key file cosign.key is not in the correct PEM format or is corrupted.. The error 'PEM decode failed: invalid pem block' indicates that Cosign could not parse the private key file. This is most likely because the file is not a valid PEM-encoded key, perhaps due to corruption, wrong file, or incorrect format. The other options would produce different errors related to registry authentication, image reference, or key decryption.

Answer

The cosign.key file was encrypted and requires a password that was not provided.

Answer

The image reference is invalid because it lacks a digest.

Answer

The image registry requires authentication, and the engineer has not logged in.

Question 10

A security engineer is hardening a Kubernetes cluster and wants to ensure that any container attempting to load a kernel module is immediately detected and logged. They have deployed Falco on all nodes. Which Falco rule condition should they use to detect this activity?

Accepted Answer

evt.type=init_module or evt.type=finit_module. To detect kernel module loading, Falco must monitor the init_module and finit_module system calls, which are the actual kernel interfaces for loading modules. Matching evt.type against these syscall names provides direct, reliable detection regardless of which user-space tool or method is used to initiate the load. This condition is precise and minimizes false positives.

Answer

evt.type=mmap and fd.type=module

Answer

evt.type=execve and proc.name contains modprobe

Answer

evt.type=open and fd.name contains /lib/modules

Question 11

A security analyst notices that a Falco rule intended to detect writes to /etc inside containers is generating alerts for a legitimate application that writes to /etc/app/config. The analyst wants to refine the rule to exclude this specific path while still detecting other writes to /etc. Which Falco rule condition modification should be applied?

Accepted Answer

Add 'and not fd.name = /etc/app/config' to the condition. Falco rules can be tuned with boolean conditions to exclude known legitimate activity. To suppress alerts for a specific file path, the condition should include a check that the file descriptor name does not equal that path. This maintains detection for all other writes to /etc while eliminating the false positive from the legitimate application's configuration file.

Answer

Add 'and not fd.directory = /etc/app' to the condition

Answer

Add 'and not proc.name = app' to the condition

Answer

Change the rule's priority from WARNING to NOTICE

Question 12

A cluster uses containerd and a security team wants to block containers from loading kernel modules. They apply a pod with securityContext.seccompProfile.type set to Localhost and a profile that returns SCMP_ACT_ERRNO for the init_module and finit_module syscalls. The pod starts but a test binary still loads a module. Which is the most likely cause?

Accepted Answer

The container process runs with CAP_SYS_MODULE and the seccomp profile's default action is SCMP_ACT_ALLOW, so the errno rule was placed after a broader allow rule that matched first.. Seccomp applies the first matching rule, so a broad allow placed before the errno rule for init_module and finit_module neutralizes the block. Keeping CAP_SYS_MODULE also lets the process attempt module loads. Ordering the deny rules first and removing the capability ensures the filter actually stops module loading in this container.

Answer

The seccomp profile must be stored in the container image rather than referenced by the pod, so the runtime ignored it.

Answer

The pod needs privileged: true for the profile to be enforced, since restricted pods skip seccomp filtering.

Answer

Seccomp filters cannot block init_module or finit_module because those syscalls are resolved by the kernel before the filter runs.

Question 13

You are reviewing a pod specification that mounts a hostPath volume to /var/run/docker.sock. Which security risk does this present, and what is the recommended mitigation?

Accepted Answer

It allows the container to control the Docker daemon, potentially leading to host compromise; mitigate by avoiding hostPath mounts to the Docker socket and using a least-privilege approach.. Mounting the Docker socket gives the container control over the Docker daemon, enabling container escapes and host compromise. The correct mitigation is to avoid such mounts and use least-privilege alternatives. Read-only flags, hostNetwork, and hostPID settings do not mitigate this specific risk.

Answer

It allows the container to access the host's PID namespace; mitigate by setting hostPID: false.

Answer

It allows the container to read only the Docker logs; mitigate by setting readOnly: true on the volume mount.

Answer

It exposes the host's network stack; mitigate by setting hostNetwork: false.

Question 14

A security review flags that developers can create pods that mount the host's /etc directory. You need to block hostPath volumes cluster-wide without breaking existing workloads that use the CSI driver for persistent storage. Which control is appropriate?

Accepted Answer

Create a ValidatingAdmissionPolicy that denies pods whose spec.volumes contain a hostPath entry.. Blocking hostPath volumes requires admission-time inspection of the pod spec. ValidatingAdmissionPolicy lets you express a CEL rule that rejects any pod declaring a hostPath volume, which precisely targets the risk without imposing unrelated restrictions. CSI volumes use a different volume source, so legitimate persistent storage continues to work. PodSecurity restricted, kubelet allow-privileged, and NetworkPolicy all act on different concerns and either over-restrict or miss the mount entirely.

Answer

Apply a PodSecurity admission label of restricted to every namespace so hostPath volumes are rejected.

Answer

Add a NetworkPolicy with an empty podSelector in each namespace to prevent pods from reading host filesystem paths.

Answer

Set --allow-privileged=false on the kubelet of every node so hostPath mounts are refused at runtime.

Question 15

You are hardening a kubeadm-managed cluster running Kubernetes v1.28. The kubelet's read-only port (10255) is still listening on every node, exposing pod and node metadata without authentication. You must disable it across the cluster. Which action is correct?

Accepted Answer

Edit each node's kubelet configuration to set readOnlyPort: 0, then restart the kubelet service.. The unauthenticated kubelet read-only port is controlled solely by the readOnlyPort setting inside the kubelet's configuration. Setting it to 0 disables the listener, eliminating anonymous metadata disclosure. NetworkPolicies, apiserver flags, and credential rotation act on different layers and cannot close a listener bound in the node's host network namespace. The fix must be applied per node and followed by a kubelet restart.

Answer

Add a NetworkPolicy to the kube-system namespace that denies ingress to TCP port 10255 on all pods.

Answer

Change the kube-apiserver --kubelet-preferred-address-types flag to InternalIP so the read-only port is bypassed.

Answer

Rotate the kubelet client certificate and enable NodeRestriction so the read-only port requires authentication.

Question 16

An operator must upgrade a kubeadm cluster and wants to verify that the new control plane binaries are authentic before installing them. The team already has the Kubernetes release signing key. Which step confirms the integrity and origin of the downloaded binary?

Accepted Answer

Verify the detached signature over the checksum file with the release signing key, then confirm the binary's hash matches the signed checksum.. The Kubernetes release process publishes a checksum file and a detached signature over that file. Verifying the signature with the trusted release key proves the checksum file is authentic, and matching the binary's hash to the signed checksum proves the binary itself is intact. Hash comparisons alone or checksums fetched from the same origin do not establish origin, and kubeadm does not verify binaries automatically.

Answer

Run openssl dgst -sha256 on the binary and confirm it matches the checksum file downloaded from the same server.

Answer

Import the release key into kubeadm's trust store and let kubeadm verify binaries automatically during upgrade.

Answer

Compare the SHA-512 hash of the binary against the value published in the release notes, then install it.

Question 17

A platform team is hardening a namespace that runs tenant workloads. They want runtime detection that flags container escapes and unexpected privilege changes. Which TWO Falco rule fields or conditions are most appropriate to detect these behaviors? (Choose two.)

Accepted Answer

evt.type in (mount, umount2) with proc.name = runc or a condition on the mount source. Detecting container escapes and privilege changes calls for syscall-level signals tied to confinement boundaries. Watching setuid and setgid transitions catches attempts to gain effective privileges, while monitoring mount and umount2 activity with a runtime or source constraint surfaces tampering with the filesystem namespace. Both are low-noise, high-signal conditions for tenant workloads compared with generic shell or file-read detections.

Answer

evt.type = execve and proc.name = kubectl

Answer

proc.name = bash and container.id != host

Answer

evt.type = open and fd.name contains /etc/passwd

Question 18

A Kubernetes cluster enforces image signature verification using the Cosign admission controller. A developer attempts to deploy a pod using an image that was signed with a key that is not in the trusted public key list. The pod is rejected. Which component is responsible for this rejection?

Accepted Answer

The Kubernetes API server's admission chain, specifically the Cosign admission webhook.. Admission controllers in the Kubernetes API server enforce policies before objects are persisted. The Cosign admission webhook validates image signatures against a configured list of trusted public keys. If the signature does not match a trusted key, the webhook denies the pod creation, preventing unsigned or untrusted images from running.

Answer

The Kubernetes scheduler, which filters nodes based on image signature policies.

Answer

The container runtime interface (CRI) on the node, such as containerd or CRI-O.

Answer

The kubelet on the node where the pod is scheduled.

Question 19

A cluster runs Kubernetes 1.29 with the AppArmor support enabled. A pod manifest sets securityContext.appArmorProfile.type to Localhost with localhostProfile: k8s-nginx. The pod stays in ContainerCreating and the kubelet logs show a failed to apply AppArmor profile error. Which action most directly resolves the failure?

Accepted Answer

Load the k8s-nginx profile into the kernel on every node in the cluster with apparmor_parser -r before the pod is scheduled.. Localhost AppArmor profiles must exist in the node kernel before a pod referencing them can start. The kubelet and container runtime only look up the named profile; they do not load it. Loading k8s-nginx with apparmor_parser on each node that may run the pod makes the profile resolvable, allowing the container to be created under the intended policy.

Answer

Install the AppArmor profile into the container image at /etc/apparmor.d/k8s-nginx and restart the pod.

Answer

Add the k8s-nginx profile to the kube-apiserver's --apparmor-profile flag.

Answer

Change the profile type to RuntimeDefault so the container inherits the runtime's default AppArmor profile.

Question 20

A developer is building a container image and wants to ensure that the image is free from known vulnerabilities before pushing it to a registry. The developer decides to use Trivy. Which command should the developer run to scan the image for vulnerabilities?

Accepted Answer

trivy image myapp:latest. The trivy image command is designed to scan container images for vulnerabilities. It retrieves the image, analyzes its layers, and matches installed packages against vulnerability databases. The other options either target different artifact types (filesystem, configuration files) or use a non-existent subcommand, so they would not achieve the desired scan.

Answer

trivy fs --security-checks vuln myapp:latest

Answer

trivy config myapp:latest

Answer

trivy repository myapp:latest