CKS Practice Exam 4 — 20 Questions

Question 1

Which THREE of the following are recommended measures to reduce the attack surface of Kubernetes nodes?

Accepted Answer

Disable unnecessary system services on nodes. Disabling unnecessary system services on Kubernetes nodes reduces the number of running processes and open ports that could be exploited by an attacker. Services like telnet, rsh, or unused SNMP daemons provide additional attack vectors. This aligns with the principle of minimalism in system hardening, as recommended by the CIS Kubernetes Benchmark.

Answer

Open all ports on nodes to allow easy debugging

Answer

Run all containers as root user

Question 2

Which THREE of the following are required to secure etcd in a Kubernetes cluster?

Accepted Answer

Require client certificate authentication. Etcd requires client certificate authentication to verify the identity of clients (such as kube-apiserver) connecting to it. Without mutual TLS (mTLS), an attacker could impersonate a legitimate client and read or modify cluster state, including secrets and configuration data.

Answer

Configure RBAC for etcd

Answer

Allow anonymous access for monitoring

Question 3

You are configuring kubelet to protect kernel defaults. Which flag enables this?

Accepted Answer

--protect-kernel-defaults. The `--protect-kernel-defaults` flag is a kubelet option that, when set to `true`, enforces kernel tunable protections by checking that sysctl settings like `vm.overcommit_memory`, `vm.panic_on_oom`, and `kernel.panic` match the kubelet's expected safe defaults. This is a critical hardening measure to prevent container breakout scenarios where a compromised pod could weaken host kernel parameters.

Answer

--security-opt=protect-kernel

Answer

--enable-protect-kernel

Answer

--kernel-security

Question 4

Match each container security context setting to its effect.

Accepted Answer

runAsNonRoot: Prevents the container from running as root. Correct matches: runAsNonRoot forces non-root execution; runAsUser sets a specific UID. Common confusion is swapping these effects. Other settings like privileged and readOnlyRootFilesystem also enforce least privilege.

Answer

runAsNonRoot: Specifies the user ID (UID) to run the container

Answer

runAsUser: Prevents the container from running as root

Question 5

A cluster administrator needs to run a workload that uses gVisor (runsc) for container sandboxing. Which Kubernetes resource is required to enable this?

Accepted Answer

RuntimeClass. A RuntimeClass resource is required to enable gVisor (runsc) because it defines the container runtime configuration that should be used for pods. By creating a RuntimeClass with the handler set to 'runsc', the cluster administrator can instruct the kubelet to use gVisor as the OCI-compatible runtime for sandboxing, providing an additional security layer through a user-space kernel.

Answer

PriorityClass

Answer

NetworkPolicy

Answer

PodSecurityPolicy

Question 6

You are tasked with securing the kubelet. Which flag must be set on the kubelet to enable the NodeRestriction admission plugin?

Accepted Answer

--enable-admission-plugins=NodeRestriction on the kube-apiserver. The NodeRestriction admission plugin is an admission controller that runs on the kube-apiserver, not on the kubelet. It limits the Node and Pod objects a kubelet can modify, enforcing that nodes can only modify their own node object and pods bound to them. The flag `--enable-admission-plugins=NodeRestriction` on the kube-apiserver activates this plugin, which is a key security control for hardening the cluster.

Answer

--admission-control=NodeRestriction on the kubelet

Answer

--enable-admission-plugins=NodeRestriction on the kubelet

Answer

--node-restriction=true on the kubelet

Question 7

A security engineer runs 'kubesec scan deployment.yaml' and receives a score of -1. What does this score indicate?

Accepted Answer

The scan failed due to an error or invalid YAML. In kubesec, a score of -1 indicates that the scan could not complete successfully, typically due to an error in the YAML file (e.g., invalid syntax, malformed structure) or a failure in the scanning process itself. Kubesec returns scores from 0 to 10 for valid deployments, where higher scores indicate better security; -1 is a special sentinel value reserved for scan failures, not a security assessment.

Answer

The deployment passed all security checks

Answer

The deployment is not secure and needs immediate attention

Answer

The deployment has critical vulnerabilities

Question 8

Which tool can be used to perform static analysis of Kubernetes manifests for security issues?

Accepted Answer

kubesec. Kubesec is a static analysis tool specifically designed to evaluate Kubernetes resource manifests against a set of built-in security best practices. It scans YAML or JSON manifests for common misconfigurations such as running containers as root, missing resource limits, or insecure capability assignments, and returns a risk score. This makes it the correct choice for static analysis of Kubernetes manifests for security issues.

Answer

syft

Answer

cosign

Answer

trivy

Question 9

A security admin wants to ensure that all container images in a Kubernetes cluster are scanned for known vulnerabilities before being deployed. Which tool can be integrated into a CI/CD pipeline to scan container images for CVEs?

Accepted Answer

Trivy. Trivy is a comprehensive vulnerability scanner for container images, filesystems, and Git repositories. It can be integrated into CI/CD pipelines to automatically scan container images for known CVEs before deployment, making it the correct choice for this requirement.

Answer

kubesec

Answer

Helm

Answer

kubectl

Question 10

You are using `crictl` to debug a container that is not responding. Which command should you use to get the list of running containers?

Accepted Answer

crictl ps. `crictl ps` is the correct command because it lists running containers managed by the CRI-compatible runtime (e.g., containerd, CRI-O). This is analogous to `docker ps` but for the Kubernetes container runtime interface, allowing you to see container IDs, names, and statuses for debugging.

Answer

crictl pods

Answer

crictl images

Answer

crictl stats

Question 11

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 12

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 13

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 14

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 15

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 16

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 17

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 18

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 19

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 20

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