CKS Practice Test 43 — 15 Questions

Question 1

Which TWO of the following are valid priority levels in Falco rules?

Accepted Answer

WARNING. In Falco rule definitions, the priority field accepts a fixed set of severity levels, and both WARNING (option C) and CRITICAL (option E) are among the valid values, alongside EMERGENCY, ALERT, ERROR, NOTICE, INFORMATIONAL, and DEBUG. WARNING is used for suspicious events that warrant attention but are not necessarily malicious, while CRITICAL denotes severe security events requiring immediate action, so both are legitimate priority levels recognized by the Falco rule schema. Options A (MEDIUM), B (LOW), and D (HIGH) are not part of Falco's defined priority enumeration, even though similar terms appear in other logging or severity frameworks, so they would be rejected or misinterpreted in a Falco rule's priority field.

Answer

MEDIUM

Answer

LOW

Answer

HIGH

Question 2

A Falco rule detects unexpected outbound connections. Which condition would identify a connection to an external IP not in the allowed list?

Accepted Answer

evt.type=connect and fd.ip not in (allowed_ips). Falco's connect event (evt.type=connect) fires when a process initiates an outbound connection, and the fd.ip field holds the destination IP of the socket. Filtering with 'fd.ip not in (allowed_ips)' therefore flags outbound connections to any IP outside the approved list, which is exactly the unexpected-egress detection described.

Answer

evt.type=accept and fd.ip not in (allowed_ips)

Answer

evt.type=listen and fd.ip not in (allowed_ips)

Answer

evt.type=bind and fd.ip not in (allowed_ips)

Question 3

Which crictl command lists all running containers on a node?

Accepted Answer

crictl ps. The crictl ps command lists running containers on a node by querying the CRI runtime, similar to docker ps. It shows container ID, image, state, and other details for containers currently running, and with the -a flag it also shows stopped containers.

Answer

crictl pods

Answer

crictl images

Answer

crictl stats

Question 4

A security team wants to ensure that all communication between the kubelet and the API server is encrypted. Which flag must be set on the kubelet to enforce this?

Accepted Answer

--kubeconfig. The `--kubeconfig` flag on the kubelet specifies the path to a kubeconfig file that contains the credentials and server address for the API server. When this flag is set, the kubelet uses TLS to authenticate and encrypt all communication with the API server, as the kubeconfig file typically references an HTTPS endpoint and includes client certificates or tokens. Without this flag, the kubelet may fall back to insecure or unencrypted connections, violating the requirement for encrypted communication.

Answer

--tls-cert-file

Answer

--node-status-update-frequency

Answer

--require-kubeconfig

Question 5

A pod is stuck in Pending state. 'kubectl describe pod' shows '0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate.' The pod does not specify any tolerations. What is the most likely cause?

Accepted Answer

The cluster only has control-plane nodes and the pod does not tolerate the control-plane taint. The error message '0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate' indicates that the only node in the cluster is a control-plane node, which by default has the node-role.kubernetes.io/control-plane taint. Since the pod does not specify any tolerations, it cannot be scheduled on that node, leaving it stuck in Pending state. This is the most likely cause because the cluster lacks worker nodes, and the pod is not designed to run on the control-plane.

Answer

The pod's image pull secret is missing

Answer

The pod uses an untrusted image that was rejected by an admission webhook

Answer

The pod's resource requests exceed the available node capacity

Question 6

Which THREE of the following are best practices for reducing the attack surface of Kubernetes nodes?

Accepted Answer

Minimize host access from containers (e.g., disable hostPID, hostNetwork). Option A is correct because disabling hostPID and hostNetwork prevents containers from sharing the node's process namespace and network stack, which blocks container escapes and lateral movement to host processes or interfaces. Option B is correct because minimal base images (e.g., distroless or Alpine) contain fewer packages, libraries, and utilities, shrinking the exploitable vulnerability surface inside the container. Option C is correct because disabling unnecessary system services on nodes (e.g., unused daemons, package managers, or listening ports) removes potential entry points and reduces the node's overall attack surface. Option D is incorrect because exposing the host network to containers increases risk by allowing direct access to node interfaces and services, which is the opposite of a hardening best practice. Option E is incorrect because running containers as root grants excessive privileges and makes privilege escalation or container breakout far more damaging; least-privilege non-root users are preferred.

Answer

Expose the host network to containers for better performance

Answer

Run containers as root to simplify permissions

Question 7

A security scan reports that the etcd data directory is not encrypted at rest. The cluster uses etcd v3.5. Which steps are required to enable encryption?

Accepted Answer

Create an EncryptionConfiguration resource with aescbc, restart API server with --encryption-provider-config. Etcd data encryption at rest in Kubernetes is implemented via an EncryptionConfiguration resource that specifies a provider (e.g., aescbc) and a key. The kube-apiserver must be restarted with the --encryption-provider-config flag pointing to that configuration file, which instructs the API server to encrypt resources before writing them to etcd. This is the only supported method for enabling encryption at rest in Kubernetes clusters using etcd v3.5.

Answer

Use etcdctl to encrypt the data directory

Answer

Set --encryption-provider=secretbox on etcd

Answer

Set ETCD_ENABLE_ENCRYPTION=true environment variable

Question 8

You are implementing a Gatekeeper policy to deny pods that run as root. Which Rego rule should you include in the ConstraintTemplate?

Accepted Answer

deny[{"msg": msg}] { msg := "container runs as root"; not input.spec.containers[_].securityContext.runAsNonRoot }. Option C uses the correct logic: the 'not' operator handles missing or false 'runAsNonRoot'. It also returns the expected object format {"msg": "..."}, which Gatekeeper requires. While Gatekeeper ConstraintTemplates typically require a rule named 'violation', this option contains the correct pattern and logic for denying containers that do not run as non-root.

Answer

allow[{"msg": msg}] { msg := "container runs as root"; input.spec.containers[_].securityContext.runAsNonRoot == false }

Answer

deny[msg] { msg := "container runs as root"; not input.spec.containers[_].securityContext.runAsNonRoot }

Answer

deny[msg] { input.spec.containers[_].securityContext.runAsNonRoot == false }

Question 9

Which TWO of the following are best practices for securing the container supply chain?

Accepted Answer

Scan images for vulnerabilities in a CI pipeline before deploying.. Scanning images for vulnerabilities in a CI pipeline before deployment is a best practice because it catches known CVEs early, preventing vulnerable images from reaching production. Tools like Trivy, Clair, or Grype integrate into CI/CD to enforce policy gates, ensuring only compliant images proceed.

Answer

Embed API keys directly in container images for authentication.

Answer

Allow all images from any registry without verification to speed up development.

Answer

Use mutable tags like 'latest' for easier updates.

Question 10

A pod is running in the 'default' namespace with a container that has an immutable root filesystem (readOnlyRootFilesystem: true). The application writes logs to /var/log/app.log. What will happen?

Accepted Answer

The write to /var/log/app.log fails, and the container may crash or log an error. When a container is configured with `readOnlyRootFilesystem: true`, its entire root filesystem is mounted as read-only. Since `/var/log/app.log` resides within the root filesystem, any attempt to write to it will fail with a permission error. This can cause the application to crash or log an error, depending on how the application handles write failures.

Answer

The container will be automatically restarted by the kubelet

Answer

The write succeeds because logs are written to a temporary filesystem

Answer

Kubernetes will create an emptyDir volume to hold the logs

Question 11

Which of the following is a best practice for storing sensitive data like passwords in Kubernetes?

Accepted Answer

Store them in Secrets and mount them as volumes. Kubernetes Secrets are designed to store sensitive data such as passwords, API keys, and certificates. Mounting a Secret as a volume ensures the data is written to a tmpfs in-memory filesystem (not to disk), reducing the risk of exposure via host filesystem access. This approach also avoids leaking secrets through environment variable dumps or logs, and supports automatic rotation when the Secret is updated.

Answer

Store them in ConfigMaps

Answer

Store them as environment variables in the Pod spec

Answer

Store them as labels on Pods

Question 12

You want to drop all Linux capabilities from a container. Which securityContext field should you set?

Accepted Answer

capabilities.drop: ["ALL"]. Setting `capabilities.drop: ["ALL"]` in the container's `securityContext` removes all Linux capabilities from the container's process, effectively running it with zero capabilities. This is the standard Kubernetes approach to drop all capabilities, as defined in the Pod Security Standards and the container runtime interface (CRI).

Answer

capabilities.allow

Answer

capabilities.add: ["ALL"]

Answer

dropCapabilities: true

Question 13

A security team wants to detect anomalous process executions in containers without modifying the container images or requiring agents inside containers. Which approach is most suitable?

Accepted Answer

Deploy Falco as a DaemonSet using eBPF probe to monitor system calls.. Falco, deployed as a DaemonSet with an eBPF probe, can monitor system calls at the kernel level without modifying container images or requiring agents inside containers. This allows it to detect anomalous process executions in real time by analyzing syscall events from the host, which is the most suitable approach for runtime security monitoring in Kubernetes.

Answer

Configure CRI-O to log all container process starts to syslog.

Answer

Enable Kubernetes audit logging and parse the logs for process events.

Answer

Use OPA Gatekeeper to enforce allowed process lists in pod specs.

Question 14

An administrator wants to enforce the Pod Security Standard 'restricted' for all pods in the 'secure' namespace. Which kubectl command correctly enables the PodSecurity admission controller for that namespace?

Accepted Answer

kubectl label ns secure pod-security.kubernetes.io/enforce=restricted. The Pod Security Standards are enforced on namespaces using the `pod-security.kubernetes.io/enforce` label set to the desired policy level (e.g., `restricted`). The `kubectl label` command applies this label to the namespace, which triggers the PodSecurity admission controller to enforce the restricted policy on all pods created in that namespace.

Answer

kubectl annotate ns secure pod-security.kubernetes.io/enforce=restricted

Answer

kubectl label ns secure pod-security.kubernetes.io/enforce-version=restricted

Answer

kubectl label ns secure pod-security.kubernetes.io/audit=restricted

Question 15

You are auditing your cluster's supply chain security. You need to generate a Software Bill of Materials (SBOM) for a container image. Which tool should you use?

Accepted Answer

Syft. Syft is a CLI tool specifically designed to generate a Software Bill of Materials (SBOM) from container images and filesystems. It uses a pluggable cataloger engine to extract package metadata (e.g., dpkg, RPM, APK, Python, Java) and outputs the SBOM in standard formats like CycloneDX or SPDX, directly addressing the requirement for supply chain security auditing.

Answer

Trivy

Answer

Kubesec

Answer

Checkov