CKS Practice Test 13 — 15 Questions

Question 1

You are a platform engineer for a financial services company. Your Kubernetes cluster runs on bare-metal nodes with Ubuntu 20.04 and uses containerd as the container runtime. The cluster is in production with 50 worker nodes. A recent security scan shows that all nodes have the 'overlayfs' kernel module loaded, which is not required. The security policy requires minimal kernel modules. You need to disable the module without disrupting running containers. What should you do?

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

Accepted Answer

Add 'blacklist overlayfs' to /etc/modprobe.d/ and run 'update-initramfs -u', then reboot nodes one by one after draining. It permanently disables the overlayfs kernel module by adding it to the modprobe blacklist and updating the initramfs, ensuring the module is not loaded on subsequent boots. Draining and rebooting nodes one by one avoids disrupting running containers, as pods are rescheduled to other nodes before the node is taken offline. This approach aligns with the security policy of minimizing kernel modules while maintaining production uptime.

Answer

Restart containerd on each node to unload the module

Answer

Use 'rmmod overlayfs' after stopping all containers

Answer

Use 'modprobe -r overlayfs' on each node immediately

Question 2

Which TWO of the following are valid ways to reduce the attack surface of a Kubernetes node? (Select 2)

Accepted Answer

Restrict hostNetwork, hostPID, and hostIPC access from containers. Option B is correct because restricting hostNetwork, hostPID, and hostIPC prevents containers from sharing the node's network, process, and IPC namespaces, which blocks container escapes and privilege escalation that would otherwise expose the host directly. Option D is correct because disabling unnecessary system services on the node removes unused daemons and listening ports, shrinking the exploitable attack surface in line with CIS Kubernetes Benchmark node hardening guidance. Option A is wrong because loading all kernel modules increases the attack surface by exposing additional kernel code and potential vulnerabilities rather than reducing it. Option C is wrong because enabling SSH for all users broadens remote access and credential exposure instead of limiting it. Option E is wrong because allowing containers to run as root grants unnecessary privileges that can be leveraged to compromise the node.

Answer

Load all kernel modules to support any workload

Answer

Enable SSH access for all users for troubleshooting

Answer

Allow containers to run as root

Question 3

You need to configure a Kubernetes Pod to have an immutable root filesystem. Which field should you set in the Pod spec?

Accepted Answer

securityContext.readOnlyRootFilesystem: true. Setting `securityContext.readOnlyRootFilesystem: true` in the container's security context makes the container's root filesystem read-only, preventing the container from writing to its own filesystem unless explicitly allowed (e.g., via volume mounts). Option A (`spec.hostPID`) shares the host's PID namespace, not relevant. Option B (`allowPrivilegeEscalation`) controls whether a process can gain more privileges than its parent, not filesystem immutability. Option C (`runAsUser`) sets the user ID for the container, not filesystem permissions. Thus, only D achieves an immutable root filesystem.

Answer

spec.hostPID: true

Answer

securityContext.allowPrivilegeEscalation: false

Answer

securityContext.runAsUser: 1000

Question 4

You are investigating a compromised pod. You suspect the attacker used 'kubectl exec' to gain shell access. Which command can you use to check the audit logs for exec events?

Accepted Answer

kubectl get events. None of the listed commands can be used to check Kubernetes audit logs for exec events. Kubernetes audit logs are stored on control plane nodes, commonly at /var/log/kubernetes/audit/audit.log or in the configured audit backend, and are not exposed via 'kubectl get events', 'kubectl logs --audit', or 'kubectl describe pod'. 'kubectl exec' runs inside a container and cannot read control-plane audit files unless a hostPath mount is explicitly configured. To inspect exec audit events, access the control plane and use host-level tools such as 'grep exec /var/log/kubernetes/audit/audit.log' according to your audit log configuration.

Answer

kubectl exec -it pod-name -- cat /var/log/audit/audit.log

Answer

kubectl logs --audit

Answer

kubectl describe pod pod-name

Question 5

You need to detect any unexpected outbound connections from pods in the 'production' namespace. Which Falco rule condition is MOST appropriate?

Accepted Answer

evt.type=connect and container.id != host and not fd.snet in ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8"). It uses the `connect` syscall to detect outbound connection attempts from containers (excluding the host) and filters out private IP ranges (RFC 1918 and loopback) to flag only unexpected external destinations. This directly matches the requirement to detect unexpected outbound connections from pods in the 'production' namespace.

Answer

evt.type=sendto and fd.sip != "0.0.0.0"

Answer

container.id != host and evt.type=accept

Answer

proc.name = curl and evt.type=connect

Question 6

Which TWO of the following are valid methods to secure the etcd datastore in a Kubernetes cluster?

Accepted Answer

Enable TLS encryption for client-to-server communication.. Enabling TLS encryption for client-to-server communication ensures that all data transmitted between etcd clients (such as the Kubernetes API server) and the etcd server is encrypted, preventing eavesdropping and man-in-the-middle attacks. This is a fundamental security measure for protecting sensitive cluster state and secrets stored in etcd.

Answer

Use HTTP instead of HTTPS for better performance.

Answer

Disable client authentication to simplify configuration.

Answer

Expose the etcd port (2379) on a public IP for easier monitoring.

Question 7

A DevOps team is deploying a new microservice that processes sensitive payment data. The security policy requires that all file system writes outside the /tmp directory be logged and alerted. Which runtime security tool and configuration best achieves this requirement with minimal performance impact?

Accepted Answer

Deploy Falco with a rule: 'evt.type=open and evt.dir=< and fd.name startswith / and not fd.name startswith /tmp'. Falco is a runtime security tool that monitors system calls in real time. The provided rule specifically triggers an alert when a file is opened for writing (evt.dir=<) outside of /tmp, meeting the logging and alerting requirement with minimal performance impact since it only inspects syscalls without blocking them.

Answer

Use Seccomp profiles to block write syscalls outside /tmp

Answer

Implement an OPA Gatekeeper constraint to reject pods that write outside /tmp

Answer

Configure AppArmor to deny writes outside /tmp

Question 8

After setting up etcd encryption at rest using EncryptionConfiguration with aescbc, which resource stores the encryption key?

Accepted Answer

The EncryptionConfiguration file itself. When etcd encryption at rest is configured via an EncryptionConfiguration file, the encryption key is defined within that file itself under the 'keys' field for the specified provider (e.g., aescbc). The EncryptionConfiguration file is passed to the kube-apiserver via the --encryption-provider-config flag, and the key material is read from this file at startup. No separate Secret or ConfigMap stores the key; the file is the authoritative source.

Answer

A ConfigMap in the etcd namespace

Answer

A Secret in the kube-system namespace

Answer

An annotation on the etcd pod

Question 9

You are investigating a pod that may have been compromised. Which kubectl command allows you to run a shell inside the running container without overwriting the container's filesystem?

Accepted Answer

kubectl exec -it pod-name -- /bin/bash. `kubectl exec -it pod-name -- /bin/bash` attaches an interactive shell to the running container without modifying its filesystem. This command uses the container runtime's exec facility to spawn a new process inside the existing container, leaving the container's root filesystem unchanged. It is the standard method for runtime investigation without altering the container's state.

Answer

kubectl debug pod-name --image=busybox

Answer

kubectl run -it --image=busybox sh

Answer

kubectl attach pod-name

Question 10

Which TWO of the following are recommended CIS benchmark practices for securing etcd? (Choose two.)

Accepted Answer

Use TLS certificates for client-to-server communication. The CIS benchmark for etcd recommends using TLS certificates for client-to-server communication to ensure data in transit is encrypted and authenticated. This prevents man-in-the-middle attacks and unauthorized access to the etcd cluster, which stores critical cluster state and secrets.

Answer

Run etcd as root user

Answer

Disable authentication for etcd to reduce latency

Answer

Expose etcd to the public internet for easier management

Question 11

A developer wants to run a container that reads a secret from a mounted volume, not as an environment variable. Which volume type should they use?

Accepted Answer

secret. The `secret` volume type in Kubernetes is specifically designed to inject sensitive data (e.g., passwords, tokens) into pods as files mounted from a tmpfs-backed in-memory filesystem, avoiding exposure as environment variables. This ensures the secret is never written to disk on the node and is only accessible via the container's filesystem at the specified mount path, aligning with the developer's requirement to read from a mounted volume.

Answer

emptyDir

Answer

hostPath

Answer

configMap

Question 12

A security auditor wants to ensure that no container in the cluster has the CAP_SYS_ADMIN capability. Which of the following is the most effective way to enforce this cluster-wide?

Accepted Answer

Implement a mutating admission webhook that automatically drops CAP_SYS_ADMIN from all pods. A mutating admission webhook intercepts Pod creation requests and can automatically modify the pod spec to drop CAP_SYS_ADMIN before the pod is persisted. This approach works cluster-wide, is not deprecated like PodSecurityPolicy, and does not require modifying node-level components or relying on namespace-level enforcement that only warns or rejects but does not automatically drop capabilities.

Answer

Add a PodSecurityPolicy that drops CAP_SYS_ADMIN

Answer

Modify the kubelet to disallow CAP_SYS_ADMIN

Answer

Configure each namespace with 'pod-security.kubernetes.io/enforce: restricted'

Question 13

Which TWO actions would help secure the Kubernetes Dashboard?

Accepted Answer

Restrict access to the Dashboard using NetworkPolicies or authentication. Kubernetes NetworkPolicies can restrict ingress traffic to the Dashboard pod, ensuring only authorized sources can reach it. Additionally, enabling authentication (e.g., using the built-in token-based login or OIDC) prevents unauthenticated access, which is critical since the Dashboard has powerful cluster management capabilities.

Answer

Deploy Dashboard in the kube-system namespace

Answer

Bind Dashboard service account to cluster-admin

Answer

Expose Dashboard via NodePort for easy access

Question 14

An administrator runs `kubectl exec -it nginx-pod -- sh` and inside the container runs `curl http://example.com`. This succeeds. However, the administrator wants to detect such outbound connections using Falco. Which syscall should Falco monitor to detect this network connection?

Accepted Answer

connect. The `connect` syscall is invoked when a client initiates an outbound TCP connection, such as when `curl http://example.com` is run inside the container. Falco monitors syscalls at the kernel level, and detecting `connect` allows it to capture the destination IP and port of the outbound request. This is the correct syscall to monitor for outbound network connections.

Answer

open

Answer

execve

Answer

bind

Question 15

Which Kubernetes resource is used to define audit logging configuration?

Accepted Answer

A YAML file specified via `--audit-policy-file`. Kubernetes audit logging configuration is defined in a YAML file that specifies the audit policy rules, and this file is passed to the kube-apiserver via the `--audit-policy-file` command-line flag. This YAML file defines which events (e.g., requests to the API server) should be logged and at what level (e.g., Metadata, Request, RequestResponse). No other Kubernetes resource or CRD is used for this purpose.

Answer

PodSecurityPolicy

Answer

ConfigMap in kube-system

Answer

AuditPolicy CRD