CKS Timed Hard Questions — 25 Difficult Questions

Question 1

A pod in namespace 'ns1' has automountServiceAccountToken: false. However, the container still has a mounted service account token at /var/run/secrets/kubernetes.io/serviceaccount. What is the most likely cause?

15 minute time limit — choose an answer to begin.

Accepted Answer

The automountServiceAccountToken field is set in the container spec instead of the pod spec. The `automountServiceAccountToken` field is a pod-level setting. If it is set to `false` in the pod spec, the kubelet will not automatically mount the service account token. However, if the field is mistakenly set inside a container spec (which is not a valid field for containers), the pod-level setting is ignored, and the default behavior (mounting the token) applies. This is why the token still appears mounted despite the intention to disable it.

Answer

The kubelet is configured to always mount tokens

Answer

The namespace has a default automountServiceAccountToken: true

Answer

The pod is using a custom service account with automountServiceAccountToken: true

Question 2

A pod is scheduled on a node that has the AppArmor profile 'my-profile' loaded in complain mode. The pod annotation specifies 'localhost/my-profile' but the container is running without the profile being enforced. What is the most likely cause?

Accepted Answer

The profile is in complain mode, not enforce mode. AppArmor profiles can operate in either 'enforce' or 'complain' mode. When a profile is loaded in complain mode, violations are logged but not blocked, so the container runs without enforcement. The pod annotation 'localhost/my-profile' correctly references the profile, but the profile itself is not set to enforce mode, which is why the container is running without the profile being enforced.

Answer

The pod must run as privileged to use AppArmor

Answer

The annotation is missing the 'localhost/' prefix

Answer

The profile is not loaded on the node

Question 3

A pod is stuck in Pending state. 'kubectl describe pod' shows the event: '0/4 nodes are available: 1 node had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 Insufficient memory.' The pod YAML does not specify any tolerations. Which command would allow the pod to schedule on the control-plane node?

Accepted Answer

Edit the pod YAML to add tolerations for node-role.kubernetes.io/control-plane. The pod is failing to schedule on the control-plane node due to the `node-role.kubernetes.io/control-plane` taint, which by default prevents pods without a matching toleration from being scheduled. Since the pod YAML does not specify any tolerations, editing it to add a toleration for that taint (e.g., `tolerations: - key: node-role.kubernetes.io/control-plane operator: Exists`) explicitly allows the pod to run on the control-plane node, resolving the Pending state.

Answer

kubectl taint nodes control-plane node-role.kubernetes.io/control-plane-

Answer

kubectl cordon control-plane

Answer

kubectl delete pod --all

Question 4

An attacker exploited a container escape vulnerability. The team wants to mitigate such attacks by restricting containers from accessing the host's kernel capabilities. Which set of capabilities should be dropped from all containers?

Accepted Answer

SYS_ADMIN, SYS_MODULE, SYS_PTRACE. SYS_ADMIN, SYS_MODULE, and SYS_PTRACE are the most dangerous capabilities that enable container escape. SYS_ADMIN grants broad administrative privileges (e.g., mounting filesystems, accessing /proc/1/environ), SYS_MODULE allows loading kernel modules, and SYS_PTRACE permits tracing processes outside the container. Dropping these three capabilities is a key mitigation against kernel-level escapes.

Answer

CHOWN, DAC_OVERRIDE, FOWNER

Answer

KILL, SETPCAP, SYS_CHROOT

Answer

NET_RAW, NET_ADMIN, NET_BIND_SERVICE

Question 5

You have a Kyverno policy that validates images are from a specific registry. However, a pod using an image from that registry is still blocked. The pod YAML includes 'imagePullPolicy: Always'. What could be the issue?

Accepted Answer

The pod uses a different registry name than the one in the policy (e.g., a mirror). Kyverno validates the image registry against the exact string specified in the policy. If the pod references an image from a mirror (e.g., `myregistry.io/nginx` instead of `myregistry.io/nginx`), or if the registry name differs (e.g., `docker.io` vs `registry-1.docker.io`), the validation fails even though the actual image content may be identical. The `imagePullPolicy: Always` is irrelevant to the registry check; it only affects when the kubelet pulls the image.

Answer

The imagePullPolicy is set to Always, causing Kyverno to ignore the registry check

Answer

Kyverno cannot validate images with a tag

Answer

The policy is missing the 'validate' rule type

Question 6

An organization uses a private container registry and wants to ensure that only images built from a specific CI/CD pipeline are deployed. Which combination of measures provides the strongest guarantee?

Accepted Answer

Generate signed attestations with in-toto during the CI pipeline and verify them using an admission webhook like Kyverno.. It implements a complete chain of custody for container images. In-toto generates signed attestations that record every step of the CI/CD pipeline (e.g., source code checkout, build, test), and an admission webhook like Kyverno verifies these attestations before allowing a pod to run. This ensures that only images that passed the exact, attested pipeline are deployed, providing the strongest guarantee against unauthorized or tampered images.

Answer

Implement network policies to restrict egress from pods to the registry.

Answer

Grant registry write access only to the CI system's service account.

Answer

Use a static analysis tool to check the Dockerfile before building.

Answer

Use a unique registry path and restrict access via firewall rules.

Question 7

A cluster has both ImagePolicyWebhook and a mutating webhook that adds a sidecar. The admin notices that even when ImagePolicyWebhook rejects an image, the mutating webhook has already added the sidecar. What admission ordering issue is occurring?

Accepted Answer

Validating webhooks should run before mutating webhooks. In Kubernetes, admission controllers are invoked in a fixed order: mutating admission controllers (including MutatingAdmissionWebhook) run before validating ones (including ImagePolicyWebhook and ValidatingAdmissionWebhook). Therefore, the mutating webhook that adds the sidecar runs before ImagePolicyWebhook validates the image. This means even if ImagePolicyWebhook rejects the image, the sidecar has already been added. The issue is that validating webhooks should run before mutating webhooks to prevent such problems, but the fixed order prevents this. Option B is wrong because using a validating webhook still runs after mutating webhooks. Option C is a workaround but not related to the ordering issue. Option D is incorrect because you cannot change the order of built-in admission controllers; the order is fixed.

Answer

Use a validating webhook instead of ImagePolicyWebhook

Answer

The mutating webhook should be configured to skip pods with certain images

Answer

The ImagePolicyWebhook should be placed before the mutating webhook in the webhook configuration

Question 8

You need to run kube-bench on a control plane node. Which command should you use?

Accepted Answer

kube-bench run --targets=master. `kube-bench` uses the `--targets` flag to specify which CIS benchmark targets to scan, and for control plane nodes, the correct target is `master` (not `controlplane`). This is because the CIS Kubernetes Benchmark historically refers to the control plane node as the 'master' node, and `kube-bench` follows that naming convention.

Answer

kube-bench run --targets=controlplane

Answer

kube-bench run --targets=node

Answer

kube-bench run --targets=etcd

Question 9

You need to ensure that all pods in a namespace have the label 'security: high' added automatically upon creation. Which admission controller should you use?

Accepted Answer

MutatingWebhookConfiguration. A MutatingWebhookConfiguration intercepts pod creation requests and can automatically add the label 'security: high' to pods in a namespace. This admission controller mutates the object before it is persisted, ensuring all pods receive the label without manual intervention.

Answer

PodSecurityPolicy (deprecated)

Answer

ResourceQuota

Answer

ValidatingAdmissionPolicy

Question 10

Which THREE of the following are best practices for securing a Kubernetes cluster using OPA Gatekeeper? (Choose three.)

Accepted Answer

Enforce that containers set runAsNonRoot: true.. Enforcing `runAsNonRoot: true` via OPA Gatekeeper ensures that containers run with a non-root user ID, mitigating the risk of privilege escalation attacks. This aligns with the Kubernetes Pod Security Standards (PSS) 'restricted' profile and is a key control for minimizing microservice vulnerabilities.

Answer

Allow privileged containers for system-critical workloads.

Answer

Allow containers to use hostNetwork for easier service discovery.

Question 11

Which TWO of the following are effective measures to harden the Kubernetes API server against unauthorized access?

Accepted Answer

Enable the NodeRestriction admission controller. The NodeRestriction admission controller limits the Node and Pod objects a kubelet can modify, preventing compromised nodes from accessing or modifying resources beyond their own. This is a key hardening measure because it enforces the principle of least privilege directly within the API server's admission chain, reducing the blast radius of a node compromise.

Answer

Set --anonymous-auth=true to allow all users

Answer

Enable audit logging to detect unauthorized attempts

Answer

Disable all authentication mechanisms and rely on network policies

Question 12

Which THREE of the following are correct statements about seccomp in Kubernetes? (Select 3)

Accepted Answer

Seccomp can be configured using the securityContext.seccompProfile field. The `securityContext.seccompProfile` field in a Pod or container spec allows you to configure seccomp profiles directly in the Kubernetes API. This field supports values like `RuntimeDefault`, `Localhost`, and `Unconfined`, enabling fine-grained control over system call filtering without requiring manual profile loading on the node.

Answer

Seccomp profiles can only be applied to privileged containers

Answer

Seccomp can only restrict system calls, not allow them

Question 13

A pod has been compromised. You want to isolate it from other pods while preserving its network state for forensics. Which NetworkPolicy rule achieves this?

Accepted Answer

Create a NetworkPolicy with podSelector matching the compromised pod and empty ingress/egress rules (deny all). A NetworkPolicy with a `podSelector` matching the compromised pod and empty `ingress` and `egress` rules (i.e., no rules specified) defaults to denying all traffic to and from that pod. This isolates the pod from all other pods in the cluster while preserving its network state for forensics, as the pod remains running and its network interfaces are untouched.

Answer

Deny all ingress and egress traffic to/from the pod's namespace

Answer

Add a label to the pod and create a NetworkPolicy allowing only traffic from a forensic pod

Answer

Delete the pod

Question 14

Which THREE of the following are valid flags for enabling admission plugins on the API server?

Accepted Answer

--enable-admission-plugins=AlwaysPullImages. `--enable-admission-plugins=AlwaysPullImages` is the valid flag to enable the AlwaysPullImages admission plugin on the kube-apiserver. This flag accepts a comma-separated list of plugin names, and AlwaysPullImages is a built-in admission controller that forces every new Pod to pull images again, even if they already exist on the node, enhancing security by ensuring only authorized images are used.

Answer

--plugin-dir=/admission

Answer

--admission-control=NodeRestriction

Question 15

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 16

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 17

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 18

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 19

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 20

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