CKS Practice Test 8 — 10 Questions

Question 1

You are investigating a pod suspected of being compromised. Which set of commands would provide the most useful forensic evidence without altering the container's state?

Accepted Answer

kubectl logs && kubectl describe pod . Option A is the only set of commands that does not execute anything inside the container. `kubectl logs` and `kubectl describe pod` read information from the API server and kubelet without interfering with the container's runtime state. Options B, C, and D all involve `kubectl exec` (or `kubectl cp`, which uses `kubectl exec` to run tar inside the container), creating new processes and potentially modifying atime or other state, violating the forensic principle of non-interference.

Answer

kubectl cp :/ -c /tmp/forensic && kubectl logs --previous

Answer

kubectl exec -- cat /proc/1/cmdline && kubectl exec -- ls -la /

Answer

kubectl exec -it -- bash && kubectl exec -- cat /var/log/syslog

Question 2

An admin runs 'kubectl get pods' and sees a pod in 'CrashLoopBackOff' state. The pod's containers have a restart policy of 'Always'. What is the most likely cause?

Accepted Answer

The container's command fails immediately after start. A CrashLoopBackOff state indicates that the container starts, fails, and is repeatedly restarted by kubelet due to the 'Always' restart policy. The most likely cause is that the container's command or entrypoint fails immediately after start (e.g., a non-zero exit code from a misconfigured binary or script), triggering the restart loop. Unlike resource or node-level issues, this is a container-level failure that produces the rapid restart pattern characteristic of CrashLoopBackOff.

Answer

The image pull secret is missing

Answer

The pod's resource requests exceed node capacity

Answer

The node is out of memory

Question 3

You need to ensure a container's filesystem is immutable at runtime except for a temporary volume. Which Pod spec configuration achieves this?

Accepted Answer

containers:
- name: app
  securityContext:
    readOnlyRootFilesystem: true
  volumeMounts:
  - mountPath: /tmp
    name: scratch
volumes:
- name: scratch
  emptyDir: {}. Setting `readOnlyRootFilesystem: true` in the container's securityContext makes the container's filesystem immutable at runtime, preventing any writes to the root filesystem. By mounting an `emptyDir` volume at `/tmp`, the container gets a writable temporary volume for scratch data, satisfying the requirement of a temporary writable area while keeping the rest of the filesystem read-only.

Answer

containers:
- name: app
  securityContext:
    runAsNonRoot: true
  volumeMounts:
  - mountPath: /tmp
    name: scratch
volumes:
- name: scratch
  emptyDir: {}

Answer

containers:
- name: app
  securityContext:
    readOnlyRootFilesystem: false

Answer

containers:
- name: app
  securityContext:
    readOnlyRootFilesystem: true
  volumeMounts:
  - mountPath: /tmp
    name: scratch
volumes:
- name: scratch
  hostPath:
    path: /tmp

Question 4

You are a security engineer for a financial services company running a Kubernetes cluster with 50 nodes. The cluster uses containerd as the container runtime and Calico for networking. The security team has detected unusual outbound network connections from a pod running in the 'payments' namespace to an external IP address known to be a command-and-control server. The pod is part of a Deployment named 'payment-processor' with 3 replicas. The cluster has a Falco daemonset deployed with default rules, and audit logging is enabled for the API server. You need to quickly identify the compromised container and contain the threat. Which action should you take FIRST?

Accepted Answer

Identify the node hosting the suspicious pod using 'kubectl get pod -o wide', then SSH to that node and use 'crictl ps' to list containers, then 'crictl stop' the container. It follows the proper incident response workflow for a compromised container: first identify the node hosting the suspicious pod using `kubectl get pod -o wide`, then SSH to that node and use `crictl ps` (the containerd CLI) to list running containers and their IDs, then use `crictl stop` to immediately halt the compromised container. This approach directly isolates the threat at the container runtime level without relying on potentially compromised in-pod tools or deleting the pod (which could be recreated by the Deployment controller).

Answer

Use 'kubectl exec -it <pod> -- bash' to inspect the container, then kill the malicious process from within

Answer

Scale the 'payment-processor' Deployment to 0 replicas to immediately stop all pods

Answer

Check the Falco logs for an alert containing the pod name, then use 'kubectl delete pod' to remove the compromised pod

Question 5

You are implementing supply chain security for container images. Which tool would you use to scan a local directory of Dockerfiles and Kubernetes manifests for known vulnerabilities?

Accepted Answer

trivy fs. D is correct because `trivy fs` scans a local filesystem (including directories containing Dockerfiles and Kubernetes manifests) for known vulnerabilities. It parses these files, checks base images against vulnerability databases, and detects misconfigurations or CVEs. This tool is designed for supply chain security, covering both package vulnerabilities and infrastructure-as-code issues. The `fs` subcommand of trivy combines filesystem scanning with configuration analysis, making it suitable for the stated task.

Answer

kubectl scan

Answer

syft

Answer

cosign sign

Question 6

A security admin runs 'trivy image --severity CRITICAL,HIGH myrepo/myapp:latest' and sees many CVEs. The admin wants to ensure that only images with no CRITICAL or HIGH severity vulnerabilities are deployed to the cluster. Which admission controller should be configured to enforce this policy?

Accepted Answer

ImagePolicyWebhook. The ImagePolicyWebhook admission controller is specifically designed to evaluate container images against an external policy backend before they are admitted into the cluster. By configuring it to reject images with CRITICAL or HIGH severity vulnerabilities (as reported by Trivy), the admin can enforce that only compliant images are deployed. This controller intercepts Pod creation requests and queries an external webhook to decide whether to allow or deny the image based on the policy.

Answer

PodSecurityPolicy

Answer

ValidatingAdmissionWebhook

Answer

MutatingAdmissionWebhook

Question 7

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?

Accepted Answer

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.

Answer

The rule is missing `proc.name in (bash, sh, zsh)` because only bash is checked

Answer

Falco is not running with the required syscall capabilities

Answer

The priority is set to `ERROR` but the output is being filtered

Question 8

Which TWO of the following are valid arguments for the kubectl command to create a secret from a file? (Select TWO)

Accepted Answer

--from-file. Options D and E are correct because both --from-file and --from-env-file are valid arguments for the kubectl create secret command when creating a secret from a file. --from-file reads the entire file content and uses the filename as the key. --from-env-file reads a file containing key=value lines, which is suitable for environment variable-style secrets. Option B (--from-literal) is incorrect because it specifies key-value pairs directly on the command line, not from a file. Option A (--dry-run) is a flag, not an argument for specifying secret data. Option C (--from-yaml) is not a valid argument for kubectl create secret.

Answer

--dry-run

Answer

--from-literal

Answer

--from-yaml

Question 9

A pod running in the cluster is in a CrashLoopBackOff state. You run 'kubectl describe pod <pod>' and see the following event: 'Warning BackOff Back-off restarting failed container'. Which command would you run to see the standard error output of the container?

Accepted Answer

kubectl logs --previous. `kubectl logs --previous` retrieves the logs from the previous instance of a crashed or restarting container. When a pod is in CrashLoopBackOff, the current container may have already restarted, so the standard error output from the failed run is only available in the previous container's logs. This command specifically fetches those logs, which typically contain the stderr output that caused the crash.

Answer

kubectl exec <pod> -- cat /var/log/syslog

Answer

kubectl describe pod <pod>

Answer

kubectl logs <pod>

Question 10

You want to run a container with gVisor (runsc) runtime for sandboxing. Which resource is required to use a non-default runtime?

Accepted Answer

RuntimeClass resource. In Kubernetes, to use a non-default runtime like gVisor (runsc), you must define a RuntimeClass resource that references the runtime handler (e.g., 'runsc') configured on the node. The RuntimeClass acts as a bridge between the Pod spec and the node's container runtime configuration, allowing the scheduler to select the appropriate runtime for sandboxing. Without a RuntimeClass, the default runtime (typically runc) is used, which does not provide the same isolation level.

Answer

PodSecurityPolicy

Answer

ContainerRuntime resource

Answer

Node runtime configuration only