CKS Practice Exam 55 — 20 Questions

Question 1

Which THREE of the following are required components to enable audit logging in Kubernetes? (Select three.)

Accepted Answer

The --audit-policy-file flag on kube-apiserver. Option A is correct because the kube-apiserver must be started with the --audit-policy-file flag pointing to the audit policy file; without this flag the API server has no policy to apply and audit logging cannot be enabled. Option B is correct because --audit-log-path tells the kube-apiserver where to write the audit log; specifying this flag is what actually enables the log backend and causes events to be recorded to a file. Option C is correct because an audit policy YAML file defines the rules (levels such as None, Metadata, Request, RequestResponse) that determine which requests are logged and at what detail, and it is the file referenced by --audit-policy-file. Option D is not required because --audit-dynamic-configuration is an optional feature that allows the audit policy to be changed at runtime without restarting the API server, not a prerequisite for basic audit logging. Option E is not required because an audit webhook backend is only one alternative sink for audit events; file-based logging via --audit-log-path satisfies the requirement without any webhook configuration.

Answer

The --audit-dynamic-configuration flag

Answer

An audit webhook backend

Question 2

Refer to the exhibit. A security engineer sees that podPidsLimit is set to -1. What security concern does this raise?

Accepted Answer

It disables PID limiting, allowing a single pod to consume all PIDs on the node, risking a fork bomb. Setting `podPidsLimit` to `-1` in Kubernetes disables PID limiting for pods, meaning a single pod can create an unlimited number of processes. This poses a security risk because a compromised or malicious pod could launch a fork bomb, exhausting all available PIDs on the node and causing a denial of service (DoS) for other workloads. The correct answer is C.

Answer

It sets a hard limit of 1 PID per pod, which may break workloads

Answer

It limits each container to 1000 PIDs

Answer

It enforces a default PID limit of 100 per pod

Question 3

An administrator wants to disable anonymous authentication to the Kubernetes API server. Which flag should be added to the kube-apiserver configuration?

Accepted Answer

--anonymous-auth=false. The `--anonymous-auth=false` flag explicitly disables anonymous authentication to the Kubernetes API server. When set to false, requests without valid authentication credentials are rejected with a 401 Unauthorized error, preventing unauthenticated access. This is the standard Kubernetes mechanism to disable anonymous authentication as documented in the kube-apiserver reference.

Answer

--disable-anonymous

Answer

--authorization-mode=RBAC

Answer

--enable-admission-plugins=DenyAnonymous

Question 4

Which TWO of the following are valid admission controllers in Kubernetes? (Select TWO)

Accepted Answer

MutatingAdmissionWebhook. MutatingAdmissionWebhook, is a valid admission controller that intercepts API requests and can modify them before they are persisted. It is part of the dynamic admission control mechanism, allowing external webhooks to mutate objects. Option C, ImagePolicyWebhook, is also a valid admission controller that enforces image policy checks by querying an external webhook before admitting a pod, making it a key component for supply chain security.

Answer

PodSecurityPolicy

Answer

AdmissionReview

Answer

OPA

Question 5

You have a Pod that uses a ServiceAccount token mounted via a projected volume. You want to ensure that the token has an expiration time and that the pod is not using a long-lived token. What is the most secure way to mount the token?

Accepted Answer

Use a projected volume with 'serviceAccountToken' and set 'expirationSeconds'. Using a projected volume with `serviceAccountToken` and setting `expirationSeconds` allows you to explicitly control the token's lifetime, ensuring it is short-lived and automatically rotated. This is the most secure approach as it prevents the use of long-lived tokens that could be compromised. The default service account token is a long-lived token with no expiration, which violates the principle of minimizing credential exposure.

Answer

Mount the default service account token at /var/run/secrets/kubernetes.io/serviceaccount

Answer

Set automountServiceAccountToken: false and manually mount a Secret containing a token

Answer

Use a ConfigMap to inject the token

Question 6

A security auditor runs kube-bench and reports that the kubelet is not configured with --protect-kernel-defaults. What is the impact of this misconfiguration?

Accepted Answer

Kernel parameters may be modified, potentially reducing node security. The `--protect-kernel-defaults` flag ensures that the kubelet enforces kernel parameter hardening, preventing modifications that could weaken node security. Without it, a compromised or misconfigured pod could alter kernel settings (e.g., `net.ipv4.ip_forward`, `vm.overcommit_memory`), reducing the overall security posture of the node. This does not affect image pulling, pod scheduling, or kubelet startup.

Answer

Container runtime will not be able to pull images

Answer

The node will be unable to schedule pods

Answer

The kubelet will refuse to start

Question 7

You need to enable encryption at rest for secrets in an existing cluster. Which resource should you create?

Accepted Answer

EncryptionConfiguration. To enable encryption at rest for Kubernetes secrets, you must create an EncryptionConfiguration resource. This object defines which encryption providers (e.g., AES-CBC, KMS, or secretbox) should be used to encrypt secrets stored in etcd. Once defined, you must pass the EncryptionConfiguration file to the kube-apiserver via the `--encryption-provider-config` flag and restart the API server for the encryption to take effect.

Answer

ConfigMap

Answer

Secret

Answer

CustomResourceDefinition

Question 8

You need to audit all API requests to the cluster. Which set of apiserver flags should be configured?

Accepted Answer

--audit-log-path, --audit-policy-file. To audit all API requests to the cluster, configure `--audit-log-path` to write audit events to a file and `--audit-policy-file` to provide an audit policy that matches all API requests. The policy file must contain a rule that logs all requests; otherwise only the requests matching the policy rules are audited.

Answer

--audit-log-maxage, --audit-log-maxbackup

Answer

--audit-webhook-config-file, --audit-webhook-mode

Answer

--audit-dynamic-configuration

Question 9

Which of the following correctly adds the NET_ADMIN capability to a container in a Kubernetes pod?

Accepted Answer

securityContext:
  capabilities:
    add:
    - NET_ADMIN. In Kubernetes, the correct field to add a Linux capability to a container is `capabilities.add` in the container's `securityContext`. Option B uses `add: - NET_ADMIN` at the container level, which is the proper syntax. Option D uses `cap_add`, which is Docker Compose syntax and invalid in Kubernetes. Option A uses `cap_add` with `ALL`, which adds all capabilities and is not specific. Option C places the `securityContext` at the pod spec level, but the pod-level `securityContext` does not support a `capabilities` field; capabilities must be set in each container's `securityContext`. Therefore, C is invalid, not just less precise.

Answer

securityContext:
  capabilities:
    cap_add:
    - ALL

Answer

securityContext:
  capabilities:
    cap_add:
    - NET_ADMIN
(but placed at pod spec level)

Answer

securityContext:
  capabilities:
    cap_add:
    - NET_ADMIN

Question 10

Which kubectl flag disables anonymous authentication on the API server?

Accepted Answer

--anonymous-auth=false. The kube-apiserver uses the `--anonymous-auth` flag to control whether anonymous requests are allowed. Setting `--anonymous-auth=false` disables anonymous authentication, meaning the API server will reject requests that do not present valid credentials. This is a critical hardening step to ensure only authenticated users can access the cluster.

Answer

--anonymous-enabled=false

Answer

--no-anonymous

Answer

--disable-anonymous

Question 11

An administrator runs kube-bench on a node and sees a warning about the kubelet anonymous authentication being enabled. Which kubelet flag should be set to disable anonymous access?

Accepted Answer

--anonymous-auth=false. The kubelet's `--anonymous-auth` flag controls whether requests to the kubelet API that are not rejected by other authentication modules are treated as anonymous requests. Setting `--anonymous-auth=false` disables anonymous access, requiring all requests to present valid credentials. This directly addresses the kube-bench warning about anonymous authentication being enabled, which is a security concern as it allows unauthenticated access to the kubelet's API.

Answer

--anonymous-auth=true

Answer

--enable-anonymous=false

Answer

--disable-anonymous=true

Question 12

You need to configure the Kubernetes API server to enable audit logging at the 'Metadata' level for all requests. Which flag should be used when starting the kube-apiserver?

Accepted Answer

--audit-policy-file=/etc/kubernetes/audit-policy.yaml. Audit logging is enabled by specifying --audit-policy-file pointing to a policy file. The policy file defines the level. The flag itself is --audit-policy-file.

Answer

--feature-gates=Auditing=true

Answer

--audit-log-path=/var/log/audit.log

Answer

--audit-log-maxsize=100

Question 13

Which THREE of the following are valid audit stages in Kubernetes audit logging? (Select THREE.)

Accepted Answer

ResponseStarted. In Kubernetes audit logging, the audit policy's `stage` field accepts exactly four values: RequestReceived, ResponseStarted, ResponseComplete, and Panic. Option B (RequestReceived) is correct because it is the stage generated as soon as the API server receives the request, before the response is sent. Option A (ResponseStarted) is correct because it is emitted once the response headers have been sent but before the response body is fully transmitted, which applies to long-running requests like watch operations. Option E (ResponseComplete) is correct because it is generated after the response body has been fully sent and the request lifecycle is finished. Option C (ResponseBuffered) is not a valid stage — no such value exists in the audit.k8s.io API. Option D (RequestProcessing) is also invalid; the API server does not expose a stage by that name, so it cannot be configured in an audit policy.

Answer

ResponseBuffered

Answer

RequestProcessing

Question 14

Which THREE of the following are recommended steps during incident response for a compromised pod? (Choose three.)

Accepted Answer

Take a memory dump of the container for analysis. Option A is correct because capturing a memory dump of the container preserves volatile evidence such as running processes, injected code, and in-memory credentials before the pod is terminated or restarted. Option C is correct because kubectl logs retrieves container stdout/stderr history and kubectl exec allows live inspection of the filesystem, processes, and network state for forensic collection. Option D is correct because applying a NetworkPolicy that denies egress traffic contains the compromised pod, preventing data exfiltration or command-and-control communication while investigation continues. Option B is not recommended because deleting the entire namespace destroys evidence and may disrupt unrelated workloads. Option E is not recommended because restarting the pod immediately destroys volatile memory and runtime artifacts needed for root-cause analysis.

Answer

Delete the entire namespace containing the pod

Answer

Immediately restart the pod to stop the attack

Question 15

Which TWO of the following are valid audit levels in a Kubernetes audit policy? (Select TWO.)

Accepted Answer

None. Option B (None) is a valid audit level: it tells the API server not to log matching requests at all, which is useful for excluding noisy or sensitive events from the audit log. Option C (Metadata) is also valid: it logs request metadata such as the user, timestamp, resource, verb, and whether the request succeeded, but omits the request and response bodies. Kubernetes audit policies define exactly these levels — None, Metadata, Request, and RequestResponse — so the remaining choices do not belong: Response (A) is not a level (the response-body level is RequestResponse), Log (D) is not a defined audit level, and Full (E) is not a Kubernetes audit level name.

Answer

Response

Answer

Log

Answer

Full

Question 16

Which THREE of the following are recommended incident response steps when a container is compromised?

Accepted Answer

Copy the container's filesystem using kubectl cp for offline analysis. Option B is correct because copying the container's filesystem with kubectl cp preserves volatile evidence for offline forensic analysis before the container is destroyed or restarted. Option C is correct because kubectl logs captures the container's stdout/stderr output, which may contain indicators of compromise, attacker commands, or error traces useful for scoping the incident. Option D is correct because applying a NetworkPolicy to the pod isolates it from other workloads, limiting lateral movement and exfiltration while still keeping the container alive for investigation. Option A is wrong because ignoring a compromise allows the attacker to persist and expand access. Option E is wrong because immediately terminating the pod destroys volatile evidence such as memory, running processes, and network connections, and may trigger automated redeployment that erases the compromised instance before it can be examined.

Answer

Ignore the incident and monitor for further activity

Answer

Immediately terminate the pod to contain the threat

Question 17

Which TWO of the following are valid Falco rule priorities?

Accepted Answer

WARNING. Falco rule priorities follow the syslog severity scale, and both WARNING (option B) and CRITICAL (option D) are valid members of that scale, sitting between NOTICE/ERROR and ALERT/EMERGENCY respectively. The full set of valid Falco priorities is EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFORMATIONAL, and DEBUG, so any rule's priority field must be one of these exact strings. MEDIUM (option A), HIGH (option C), and LOW (option E) are not part of the syslog/Falco priority enumeration — they resemble generic severity labels from other tools but are not accepted values in a Falco rule definition.

Answer

MEDIUM

Answer

HIGH

Answer

LOW

Question 18

Which TWO of the following are valid techniques to detect and respond to runtime incidents in a Kubernetes cluster? (Select TWO.)

Accepted Answer

Applying a NetworkPolicy to isolate a compromised pod. Option C is correct because applying a NetworkPolicy to a compromised pod lets you isolate it at the network layer — by selecting the pod with a label selector and defining ingress/egress rules (or an empty egress/ingress set) you cut off lateral movement and C2 traffic while keeping the pod alive for investigation, which is a standard containment step in runtime incident response. Option D is correct because kubectl exec into a running container allows you to collect volatile forensic evidence — running processes, open sockets, environment variables, and in-memory artifacts — that would be lost if the pod were deleted or restarted, making it a valid detection/response technique. Option A is not a valid detection technique: deleting the pod destroys evidence and, if the workload is managed by a ReplicaSet/Deployment, the controller immediately recreates it, so the attack resumes. Option B is not a runtime incident detection/response technique: crictl images only enumerates images cached on the node and provides no runtime behavioral insight. Option E is not correct here because kubectl logs --previous only retrieves logs from a previously terminated container instance and does not itself detect or respond to a live runtime incident.

Answer

Deleting the compromised pod immediately to stop the attack

Answer

Using crictl images to list container images on the node

Answer

Running kubectl logs --previous to view logs of a terminated container

Question 19

Which TWO of the following are true about Kubernetes audit logging?

Accepted Answer

Audit stages include 'RequestReceived', 'ResponseStarted', 'ResponseComplete', and 'Panic'. Option B is correct because Kubernetes defines exactly four audit stages — RequestReceived, ResponseStarted, ResponseComplete, and Panic — which determine when an event is recorded during the request lifecycle. Option C is correct because the API server is configured with the --audit-policy-file flag to specify the audit policy file that defines what to log and at which level. Option A is not correct because enabling audit logging requires API server flags (such as --audit-policy-file and --audit-log-path), which means the kube-apiserver must be restarted. Option D is not correct because the Request level logs only the request body, not the response body. Option E is not correct because the Metadata level logs request metadata (user, timestamp, resource, verb) but not the request body.

Answer

Audit logging can be enabled without restarting the API server

Answer

The 'Request' level logs both request and response bodies

Answer

The 'Metadata' level logs the request body

Question 20

Which TWO tools can be used to directly interact with the container runtime (without going through the Kubernetes API) for troubleshooting?

Accepted Answer

ctr. Options C and D are correct because both ctr and crictl are command-line tools that talk directly to the container runtime rather than to the Kubernetes API server. ctr is the CLI shipped with containerd and interacts with the containerd daemon (via its socket, e.g. /run/containerd/containerd.sock) to list, inspect, and manage containers and images. crictl is a CRI-compatible CLI that connects to any CRI-compliant runtime endpoint (containerd or CRI-O) using the --runtime-endpoint flag, making it ideal for node-level troubleshooting when the API server or kubelet is unavailable. The unmarked options do not belong: kubelet (A) is the node agent that itself calls the CRI, not a tool for directly interacting with the runtime; docker (B) is a higher-level engine/CLI that is not the Kubernetes CRI runtime in modern clusters; and kubectl (E) communicates exclusively through the Kubernetes API server, which the question explicitly excludes.

Answer

kubelet

Answer

docker

Answer

kubectl