CKS Practice Test 20 — 15 Questions

Question 1

A security auditor runs kube-bench on a Kubernetes node and reports that the check '1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive' fails. What is the most appropriate remediation?

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

Accepted Answer

Run 'chmod 644 /etc/kubernetes/manifests/kube-apiserver.yaml'. The CIS benchmark for Kubernetes requires the API server manifest file to have permissions of 644 or more restrictive (e.g., 600, 640, or 644) to prevent unauthorized modifications. Running 'chmod 644 /etc/kubernetes/manifests/kube-apiserver.yaml' sets the file to read-write for the owner and read-only for group and others, satisfying the benchmark. The kubelet automatically detects the change and reloads the static pod, so no restart is needed.

Answer

Delete the API server manifest file

Answer

Run 'chmod 755 /etc/kubernetes/manifests/kube-apiserver.yaml'

Answer

Restart the kubelet service

Question 2

A developer asks you to run a container with gVisor runtime. The cluster has a RuntimeClass named 'gvisor' defined. Which field must be added to the Pod spec to use gVisor?

Accepted Answer

spec.runtimeClassName: gvisor. The `runtimeClassName` field is a top-level field in the Pod spec (i.e., `spec.runtimeClassName`) that specifies the name of the RuntimeClass resource to use for running the Pod's containers. In this case, setting `spec.runtimeClassName: gvisor` instructs the kubelet to use the gVisor runtime (via the 'gvisor' RuntimeClass) for all containers in the Pod, enabling a sandboxed kernel for enhanced isolation.

Answer

spec.containers[0].runtimeClassName: gvisor

Answer

metadata.runtimeClassName: gvisor

Answer

spec.runtimeClass: gvisor

Question 3

Which of the following is the correct annotation to apply an AppArmor profile named 'my-profile' to a container named 'app' in a pod?

Accepted Answer

container.apparmor.security.beta.kubernetes.io/app: localhost/my-profile. The AppArmor profile annotation for a container must follow the format `container.apparmor.security.beta.kubernetes.io/: localhost/`. This annotation is in the `security.beta.kubernetes.io` API group (beta, not alpha) and targets the specific container by name. The value must include the `localhost/` prefix to indicate a profile loaded on the node, not a built-in or default profile.

Answer

security.alpha.kubernetes.io/apparmor/app: localhost/my-profile

Answer

pod.apparmor.security.beta.kubernetes.io/app: my-profile

Answer

container.apparmor.security.beta.kubernetes.io/app: my-profile

Question 4

A cluster has the ImagePolicyWebhook admission controller enabled. A pod creation is denied with the message 'image policy check failed'. The webhook server returns an error. Which of the following could be a valid reason?

Accepted Answer

The image is not signed by a trusted authority. The ImagePolicyWebhook admission controller intercepts pod creation requests and queries an external webhook server to determine whether the image should be allowed. If the webhook returns an error (e.g., HTTP 5xx or a denial response), the admission controller fails the request with 'image policy check failed'. A common reason for the webhook to deny the request is that the image is not signed by a trusted authority, as the webhook may be configured to enforce image signature verification (e.g., using Notary or Sigstore).

Answer

The container runtime is out of date

Answer

The image tag does not exist in the registry

Answer

The pod specification has a hostNetwork: true

Question 5

Which container runtime is specifically designed for sandboxing containers with a lightweight kernel?

Accepted Answer

gVisor (runsc). gVisor (runsc) is a container runtime that provides a lightweight kernel written in Go, which intercepts system calls from the container and handles them in user space. This creates a strong sandbox between the container and the host kernel, making it specifically designed for sandboxing containers with a lightweight kernel, unlike standard runtimes that share the host kernel directly.

Answer

Docker

Answer

containerd

Answer

runc

Question 6

An administrator wants to monitor runtime security events in Kubernetes using Falco. Which component must be deployed as a DaemonSet to capture system calls from containers?

Accepted Answer

Falco. Falco is the core userspace component that processes system calls and enforces runtime security rules. It must be deployed as a DaemonSet on each Kubernetes node to capture system calls from all containers running on that node, as it relies on a kernel module or eBPF probe to intercept syscalls at the host level.

Answer

Falco driver

Answer

Kube-bench

Answer

Falcoctl

Question 7

A cluster administrator wants to monitor network traffic between pods for security analysis. Which tool is designed specifically for this purpose and integrates with Kubernetes?

Accepted Answer

Deploy Cilium with Hubble for network flow visibility.. D is correct because Cilium, combined with Hubble, is specifically designed to provide deep network flow visibility and monitoring for Kubernetes pods. Hubble leverages eBPF to capture and report network traffic at the kernel level, offering granular observability into pod-to-pod communications, which directly meets the requirement for security analysis of network traffic between pods.

Answer

Configure Fluentd to collect network logs from each node.

Answer

Use Prometheus to scrape network metrics from kube-proxy.

Answer

Run kube-bench to audit network policies.

Question 8

A cluster has been configured with the NodeRestriction admission plugin. A developer tries to create a pod that uses a hostPath volume pointing to /var/log. The pod's nodeSelector is set to 'kubernetes.io/hostname: worker-1'. Which statement is true?

Accepted Answer

The pod will be created because NodeRestriction does not restrict hostPath volumes.. The NodeRestriction admission plugin limits the node labels that a kubelet can set and restricts pods from modifying their node affinity to gain access to node-specific resources. However, it does not restrict the use of hostPath volumes. Therefore, a pod with a hostPath volume pointing to /var/log and a nodeSelector for 'worker-1' will be created, as long as the nodeSelector matches an existing node label and the hostPath volume is otherwise permitted by the PodSecurityPolicy or other security contexts.

Answer

The pod will be created only if the node label matches the nodeSelector; the hostPath volume is irrelevant.

Answer

The pod will be rejected because hostPath volumes are not allowed by NodeRestriction.

Answer

The pod will be rejected because the nodeSelector conflicts with the NodeRestriction plugin.

Question 9

A developer wants to create a Deployment that runs as a non-root user. Which YAML snippet correctly sets the security context to run the container with UID 1000?

Accepted Answer

spec.containers[].securityContext.runAsUser: 1000. `securityContext.runAsUser: 1000` explicitly sets the container's user ID to 1000, ensuring the container process runs as a non-root user. This is the direct way to enforce a specific UID in Kubernetes, meeting the developer's requirement to run as a non-root user.

Answer

spec.containers[].securityContext.runAsUser: 0

Answer

spec.containers[].securityContext.runAsNonRoot: true

Answer

spec.containers[].securityContext.runAsGroup: 1000

Question 10

Which command is used to check whether AppArmor is enabled and which profiles are loaded on a Linux node?

Accepted Answer

aa-status. AppArmor is a Linux Security Module (LSM) enforced at the node level, not a Kubernetes resource. Kubernetes does not expose AppArmor status via kubectl. To check whether AppArmor is enabled and which profiles are loaded, you must execute `aa-status` directly on the node (e.g., via SSH). This command queries the AppArmor kernel module and lists all loaded profiles.

Answer

kubectl get seccomp

Answer

kubectl get apparmor

Answer

systemctl status apparmor

Question 11

Which command creates a validating webhook configuration that checks all pods in the cluster?

Accepted Answer

kubectl create validatingwebhookconfiguration my-webhook --from-file=webhook.yaml. `kubectl create validatingwebhookconfiguration` is the specific command to create a ValidatingWebhookConfiguration resource from a YAML file, which can be configured to intercept and validate pod creation requests across the cluster. This resource allows you to define a webhook that checks all pods before they are admitted, enforcing custom validation logic.

Answer

kubectl create mutatingwebhookconfiguration my-webhook --from-file=webhook.yaml

Answer

kubectl run webhook --image=webhook

Answer

kubectl apply -f webhook.yaml --validating

Question 12

Which of the following is the correct kubectl command to view the OPA Gatekeeper ConstraintTemplates in the cluster?

Accepted Answer

kubectl get constrainttemplates. OPA Gatekeeper registers its constraints as custom resources in Kubernetes, and the standard `kubectl get constrainttemplates` command retrieves all ConstraintTemplate resources from the cluster. This works because Gatekeeper uses the Kubernetes API aggregation layer, making ConstraintTemplates a top-level resource type that kubectl can query directly.

Answer

kubectl get gatekeeper-constrainttemplates

Answer

kubectl describe opa constrainttemplate

Answer

kubectl get crd -o name | grep constraint

Question 13

Which TWO of the following are correct about container sandboxing technologies? (Select TWO)

Accepted Answer

Kata Containers run containers in lightweight VMs, providing hardware-level isolation.. Kata Containers provide hardware-level isolation by running each container or pod in a lightweight VM with its own guest kernel using KVM. Option B is correct because gVisor implements a user-space kernel (called Sentry) that intercepts system calls, providing a kernel-level sandbox without dedicated VMs. Option C is incorrect because Kata Containers use a guest kernel, not the host kernel. Option D is incorrect because gVisor does not run containers in separate VMs; it runs as a kernel within the user space. Option E is incorrect because although RuntimeClass is commonly used to select non-default runtimes in Kubernetes, the statement is not universally required; it is a mechanism but not a strict requirement for using these technologies, making the claim that both 'require' RuntimeClass too absolute and thus false.

Answer

Kata Containers use the host kernel for system calls.

Answer

gVisor runs containers in separate VMs for each pod.

Answer

Both gVisor and Kata Containers require RuntimeClass to be used in Kubernetes.

Question 14

An administrator wants to use AppArmor to confine a container. They have loaded a profile named 'my-custom-profile' using apparmor_parser. Which annotation should be added to the pod to enforce this profile?

Accepted Answer

container.apparmor.security.beta.kubernetes.io/: localhost/my-custom-profile. The AppArmor annotation for pods follows the format `container.apparmor.security.beta.kubernetes.io/` with the value `localhost/`. The `localhost/` prefix is required to indicate that the profile is loaded locally on the node, not a built-in or Kubernetes-managed profile. This annotation enforces the loaded 'my-custom-profile' on the specified container.

Answer

container.apparmor.kubernetes.io/<container_name>: localhost/my-custom-profile

Answer

apparmor.security.beta.kubernetes.io/<container_name>: my-custom-profile

Answer

container.apparmor.security.beta.kubernetes.io/my-custom-profile: enforce

Question 15

A pod runs with a service mesh sidecar (Istio). The team wants to enforce mutual TLS (mTLS) for all traffic between services in the 'production' namespace. Which resource should be applied?

Accepted Answer

PeerAuthentication with mode: STRICT in the namespace. PeerAuthentication with mode: STRICT enforces mutual TLS at the service mesh level by requiring all traffic within the namespace to use TLS certificates for both sides of the connection. This is the correct Istio resource to enforce mTLS for all services in the 'production' namespace, as it sets a namespace-wide policy that overrides any permissive defaults.

Answer

DestinationRule with trafficPolicy: tls: mode: ISTIO_MUTUAL

Answer

VirtualService with TLS settings

Answer

ServiceEntry with mTLS enabled