Certified Kubernetes Security Specialist CKS CKS Questions 151–225 | Page 3/12

151

MCQmedium

A pod is running with securityContext.seccompProfile.type: Unconfined. Which statement is true?

A.The container is limited to a set of allowed syscalls as defined by the runtime.

B.The container can make any system call.

C.Seccomp is not supported on this node.

D.The container is running with the host's seccomp profile.

AnswerB

This is the correct interpretation. When seccompProfile is set to Unconfined, Kubernetes explicitly configures the container to run without a seccomp profile, effectively disabling kernel seccomp filtering for that container. All system calls the container makes are passed through to the kernel without being checked against a seccomp allowlist or denylist. Other security mechanisms like Linux capabilities or AppArmor may still apply, but seccomp imposes no restrictions.

Why this answer

When `securityContext.seccompProfile.type` is set to `Unconfined`, the container is allowed to make any system call without restriction. Seccomp (secure computing mode) is a Linux kernel feature that filters syscalls; `Unconfined` explicitly disables this filter, granting the container full syscall access. This is the most permissive seccomp profile and is the default if no profile is specified in older Kubernetes versions.

Exam trap

Candidates often mistake Unconfined for using the node's seccomp profile or think it means seccomp is unsupported, when in fact it explicitly disables syscall filtering.

How to eliminate wrong answers

Option A is wrong because `Unconfined` means no syscall restrictions are applied, whereas a limited set of allowed syscalls corresponds to a `RuntimeDefault` or a custom profile. Option C is wrong because seccomp support is a kernel feature; if the node does not support seccomp, the pod would fail to start or fall back to `Unconfined`, but the statement 'Seccomp is not supported on this node' is not implied by the profile type. Option D is wrong because `Unconfined` does not use the host's seccomp profile; it disables seccomp entirely, while using the host's profile would require `Localhost` with a path to the host's profile file.

Full explanation →

152

MCQmedium

An administrator wants to enforce a custom AppArmor profile named 'k8s-apparmor-example' on a pod. The profile has been loaded on the node. Which annotation should be added to the pod's metadata to apply this profile?

A.container.apparmor.security.beta.kubernetes.io/nginx: localhost/k8s-apparmor-example

B.container.apparmor.security.beta.kubernetes.io/pod: localhost/k8s-apparmor-example

C.apparmor.security.beta.kubernetes.io/pod: k8s-apparmor-example

D.container.apparmor.security.beta.kubernetes.io/nginx: k8s-apparmor-example

AnswerA

This is correct. The annotation key uses the required 'container.' prefix followed by the exact container name 'nginx', and the value provides the 'localhost/' prefix to reference a preloaded AppArmor profile on the node. The kubelet reads this annotation and enforces the profile 'k8s-apparmor-example' on the nginx container, failing to start the container if the profile is not loaded on the node.

Why this answer

The annotation format for applying an AppArmor profile to a container in a pod is `container.apparmor.security.beta.kubernetes.io/<container_name>`. The value `localhost/k8s-apparmor-example` specifies that the profile named `k8s-apparmor-example` is loaded locally on the node. This annotation enforces the profile on the container named 'nginx'.

Exam trap

CNCF often tests the exact annotation syntax, specifically that the key must include `container.` and the container name, and the value must include `localhost/` for a custom profile, leading candidates to confuse the pod-level annotation with the container-level one.

How to eliminate wrong answers

Option B is wrong because the annotation key uses `pod` instead of the actual container name (`nginx`); the annotation must target a specific container, not the pod. Option C is wrong because the annotation key is missing the `container.` prefix and uses `pod` instead of the container name, and the value lacks the `localhost/` prefix required for a locally loaded profile. Option D is wrong because it is identical to Option A and is listed as correct, but the question expects only one correct answer; however, in the provided options, Option A is marked as correct and Option D is a duplicate, so Option D is considered wrong in the context of the answer set because it is not the designated correct choice.

Full explanation →

153

MCQeasy

Which of the following commands shows all loaded AppArmor profiles?

A.apparmor_parser

B.aa-status

C.aa-disable

D.aa-enforce

AnswerB

aa-status is the canonical command for displaying all loaded AppArmor profiles and their operational modes, such as enforce or complain. It queries the kernel's AppArmor subsystem through /sys/kernel/security/apparmor/profiles and also lists the processes currently confined by each profile. This makes it the correct tool when you need to see which profiles are active on the system.

Why this answer

The `aa-status` command displays the current status of AppArmor, including all loaded profiles, their enforcement mode (enforce/complain), and which processes are confined by them. This is the standard tool for listing active AppArmor profiles on a system.

Exam trap

The trap here is that candidates confuse `apparmor_parser` (which loads profiles) with `aa-status` (which lists them), or assume that `aa-enforce` or `aa-disable` somehow show profile status, when they are actually mode-changing commands.

How to eliminate wrong answers

Option A is wrong because `apparmor_parser` is used to load or compile AppArmor profiles from text files into the kernel, not to list currently loaded profiles. Option C is wrong because `aa-disable` is used to disable an AppArmor profile by removing its symbolic link from `/etc/apparmor.d/`, not to display profiles. Option D is wrong because `aa-enforce` is used to set a profile to enforce mode (actively blocking violations), not to list loaded profiles.

Full explanation →

154

MCQhard

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?

A.The pod's image pull secret is missing

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

C.The pod's resource requests exceed the available node capacity

D.The cluster only has control-plane nodes and the pod does not tolerate the control-plane taint

AnswerD

The scheduler reports only one node, tainted node-role.kubernetes.io/control-plane, and the pod declares no tolerations, so no node satisfies its scheduling requirements. With no worker nodes present, the pod remains Pending indefinitely until the taint is tolerated or capacity is added.

Why this answer

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.

Exam trap

The CKAD/CKS exams often test the distinction between different pod failure states (Pending vs. ImagePullBackOff vs. CrashLoopBackOff) and expect candidates to recognize that taint-related scheduling issues produce a specific message in 'kubectl describe pod', not resource or image errors.

How to eliminate wrong answers

Option A is wrong because a missing image pull secret would cause an ImagePullBackOff or ErrImagePull error, not a Pending state with a taint-related scheduling failure. Option B is wrong because an untrusted image rejected by an admission webhook would result in a pod creation failure (e.g., admission webhook denial), not a Pending state with a node taint message. Option C is wrong because resource requests exceeding node capacity would show a different error like 'Insufficient cpu' or 'Insufficient memory', not a taint-related message.

Full explanation →

155

Multi-Selecthard

Which THREE of the following are best practices for minimizing host access from containers to reduce the attack surface? (Select three.)

Select 3 answers

A.Avoid setting hostPID to true

B.Avoid setting hostNetwork to true

C.Avoid setting hostIPC to true

D.Disable swap on nodes

E.Avoid using hostPort in container port mappings

AnswersA, B, C

Setting hostPID to true places the container directly in the host's process ID namespace, letting it list and signal every process running on the node. An attacker who compromises such a container can inspect /proc entries for sensitive host processes, inject signals, or potentially escalate privileges. Therefore, avoiding hostPID is a fundamental pod security practice to preserve process isolation.

Why this answer

Setting hostPID to true allows a container to share the host's process ID namespace, enabling it to see all host processes and potentially access sensitive information or perform privilege escalation. Avoiding this setting reduces the attack surface by preventing containers from interacting with host-level processes, which is a key principle of namespace isolation in Kubernetes.

Exam trap

CNCF often tests the distinction between host access (namespace sharing) and host exposure (port mapping or resource limits), so candidates may mistakenly select options like hostPort or swap disabling as host access controls when they are actually about network exposure or system performance.

Full explanation →

156

MCQmedium

You need to create a NetworkPolicy that denies all ingress traffic to pods with label 'app: web' in the 'frontend' namespace, except for traffic from pods with label 'app: ingress' in the 'ingress' namespace. Which NetworkPolicy spec correctly achieves this?

A.ingress: - from: - namespaceSelector: matchLabels: name: ingress podSelector: matchLabels: app: ingress

B.ingress: - from: - namespaceSelector: matchLabels: app: ingress podSelector: {}

C.ingress: - from: - podSelector: matchLabels: app: ingress - namespaceSelector: matchLabels: kubernetes.io/metadata.name: ingress

D.ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: ingress podSelector: matchLabels: app: ingress

AnswerD

This is correct because a single 'from' entry containing both a namespaceSelector and a podSelector applies Boolean AND semantics: the source pod must run in a namespace that carries the 'kubernetes.io/metadata.name: ingress' label (i.e., the namespace literally named 'ingress') AND the pod itself must have the label 'app: ingress'. Since no other ingress rules exist, the policy defaults to deny all other ingress traffic, precisely matching the requirement. Using the standard metadata.name label ensures reliable namespace identification without relying on manually maintained labels.

Why this answer

It uses a single `from` entry with both a `namespaceSelector` (matching the `ingress` namespace by its `kubernetes.io/metadata.name` label) and a `podSelector` (matching pods with `app: ingress`). This combination restricts ingress traffic to only pods that are both in the `ingress` namespace AND have the label `app: ingress`, while implicitly denying all other ingress traffic to pods labeled `app: web` in the `frontend` namespace.

Exam trap

A common trap in CKS is to confuse AND vs OR logic in NetworkPolicy selectors. Option C uses separate 'from' entries (OR logic), making it overly permissive, while the correct approach combines namespaceSelector and podSelector in a single 'from' block (AND logic).

How to eliminate wrong answers

Option A is wrong because it uses a `namespaceSelector` with `matchLabels: {name: ingress}` but the `ingress` namespace may not have a label `name: ingress`; Kubernetes automatically assigns the `kubernetes.io/metadata.name` label, not `name`. Option B is wrong because it uses `podSelector: {}` which matches all pods in the selected namespace, but the `namespaceSelector` incorrectly uses `matchLabels: {app: ingress}` — namespaces do not have an `app` label by default, and even if they did, it would select the wrong namespace. Option C is wrong because it lists two separate `from` entries: the first allows traffic from any pod with `app: ingress` in any namespace, and the second allows traffic from any pod in the `ingress` namespace; this creates an OR condition, allowing traffic from pods with `app: ingress` in any namespace (including the `frontend` namespace), which violates the requirement to only allow traffic from the `ingress` namespace.

Full explanation →

157

MCQhard

A cluster administrator wants to allow only images from a specific registry (e.g., 'myregistry.io') to be deployed in the cluster. Which tool can be used to enforce this via admission control?

A.OPA/Gatekeeper

B.Helm

C.Calico

D.Prometheus

AnswerA

OPA/Gatekeeper is a validating admission webhook that intercepts API requests before they are persisted. It uses ConstraintTemplates written in Rego to define policies, such as restricting container images to a trusted registry, and Constraints to enforce them across namespaces. Because it integrates directly with the API server's admission phase, it can block any Pod that references an image outside the approved allowlist.

Why this answer

OPA/Gatekeeper is a Kubernetes admission controller that allows you to enforce custom policies, such as restricting container images to a specific registry. By defining a ConstraintTemplate and a Constraint that checks the image prefix (e.g., 'myregistry.io/'), Gatekeeper can reject any Pod creation that uses images from unauthorized registries. This directly addresses the requirement for registry-based admission control.

Exam trap

The trap here is that candidates often confuse Helm (a deployment tool) with an admission controller, or assume Calico (a network policy tool) can enforce image registry restrictions, when only OPA/Gatekeeper or similar admission webhooks can perform this validation.

How to eliminate wrong answers

Option B (Helm) is wrong because Helm is a package manager for Kubernetes that deploys charts, not an admission controller; it cannot enforce runtime policies on image registries. Option C (Calico) is wrong because Calico is a networking and network security solution (e.g., NetworkPolicies), not an admission control tool for validating image sources. Option D (Prometheus) is wrong because Prometheus is a monitoring and alerting system that collects metrics, not an admission controller that can block resource creation based on image registry.

Full explanation →

158

MCQeasy

Which of the following is a recommended setting from the CIS Kubernetes Benchmark for the kubelet?

A.--authorization-mode=AlwaysAllow

B.--anonymous-auth=true

C.--anonymous-auth=false

D.--read-only-port=10255

AnswerC

--anonymous-auth=false is the CIS-recommended hardening setting because it causes the kube-apiserver to reject all requests without a valid client certificate, bearer token, or other verified credentials. Disabling anonymous access eliminates the system:anonymous and system:unauthenticated identities from the authorization stage, meaning only authenticated users can be evaluated by RBAC. This reduces the attack surface by blocking unauthenticated remote calls, including potential privilege escalation through misconfigured RBAC bindings.

Why this answer

The CIS Kubernetes Benchmark recommends disabling anonymous authentication on the kubelet to ensure that all requests are authenticated. Setting `--anonymous-auth=false` forces the kubelet to reject requests from unauthenticated users, reducing the attack surface and preventing unauthorized access to the kubelet API.

Exam trap

The trap here is that candidates often confuse `--anonymous-auth` with authorization modes, mistakenly thinking that disabling anonymous auth is less important than setting a strict authorization mode, but the CIS Benchmark prioritizes disabling anonymous access as a foundational security control.

How to eliminate wrong answers

Option A is wrong because `--authorization-mode=AlwaysAllow` disables authorization checks, allowing any authenticated request to proceed, which violates the principle of least privilege and is not recommended by the CIS Benchmark. Option B is wrong because `--anonymous-auth=true` allows unauthenticated requests to the kubelet, which is explicitly discouraged as it opens the node to potential exploitation. Option D is wrong because `--read-only-port=10255` is a legacy insecure port that exposes read-only kubelet endpoints without authentication; the CIS Benchmark recommends disabling this port (setting it to 0) to avoid unauthenticated information disclosure.

Full explanation →

159

Multi-Selectmedium

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

Select 2 answers

A.Deleting the compromised pod immediately to stop the attack

B.Using crictl images to list container images on the node

C.Applying a NetworkPolicy to isolate a compromised pod

D.Using kubectl exec to gather forensic data from a running container

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

AnswersC, D

A NetworkPolicy that selects the compromised pod and has no ingress or egress rules enforces a default-deny policy for that pod, immediately cutting off command-and-control and lateral movement. This is a nondestructive containment action that preserves the pod's filesystem and live state for subsequent forensic collection. Ensure your CNI plugin (e.g., Calico, Cilium) actually enforces the policy—otherwise the rule will be silently ignored.

Why this answer

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.

Exam trap

Candidates may think that deleting the pod is the best immediate response, but the exam expects knowledge of proper incident response steps that preserve evidence and contain the threat.

Full explanation →

160

Multi-Selecthard

Which TWO of the following are effective methods to harden the kubelet against unauthorized access?

Select 2 answers

A.Set --read-only-port=10255

B.Enable --authentication-token-webhook

C.Enable the NodeRestriction admission controller

D.Configure --client-ca-file and --tls-cert-file to require client certificates

E.Set --anonymous-auth=true

AnswersB, D

Enabling --authentication-token-webhook makes the kubelet validate bearer tokens against the API server's TokenReview endpoint, so only authenticated, authorised identities can reach the kubelet API. This closes anonymous or unauthenticated access to the kubelet's HTTPS endpoint.

Why this answer

To harden the kubelet's own HTTPS endpoint, enable --authentication-token-webhook to validate bearer tokens via the Kubernetes TokenReview API, and configure --client-ca-file with --tls-cert-file to require and validate client certificates. NodeRestriction is an admission controller that limits what the kubelet can modify in the API server; it does not protect the kubelet endpoint from unauthorized access.

Exam trap

The kubelet's own API endpoint is protected by authentication and authorization settings such as --anonymous-auth=false, --authentication-token-webhook, --client-ca-file, and --authorization-mode=Webhook. NodeRestriction limits a compromised kubelet's API-server access but does not harden the kubelet itself against incoming unauthorized requests.

Full explanation →

161

MCQeasy

Which of the following is a recommended CIS benchmark setting for the kubelet?

A.--anonymous-auth=true

B.--anonymous-auth=false

C.--protect-kernel-defaults=false

D.--read-only-port=10255

AnswerB

Setting `--anonymous-auth=false` explicitly rejects all requests that cannot be authenticated, including those mapped to `system:anonymous` and `system:unauthenticated`. This is the CIS-recommended hardening control because it forces every interaction with the control plane or kubelet to present a valid X.509 client certificate, bearer token, or other approved credential, thereby eliminating a common attack path where an unauthenticated remote actor can query system metadata or issue unprivileged requests.

Why this answer

The CIS benchmark for Kubernetes recommends disabling anonymous authentication on the kubelet to ensure that all requests to the kubelet API are authenticated. Setting `--anonymous-auth=false` forces the kubelet to reject requests from unauthenticated users, preventing potential unauthorized access to node-level operations such as pod logs, exec, and port-forwarding.

Exam trap

CNCF often tests the distinction between kubelet flags that control authentication versus authorization, and candidates may confuse `--anonymous-auth` with `--authentication-token-webhook` or incorrectly assume that disabling anonymous auth also blocks legitimate service account tokens.

How to eliminate wrong answers

Option A is wrong because `--anonymous-auth=true` allows unauthenticated requests to the kubelet, which violates the CIS benchmark and exposes the node to unauthorized access. Option C is wrong because `--protect-kernel-defaults=false` disables kernel parameter protection, which is a security hardening setting that should be `true`, not `false`, to ensure the kubelet enforces safe kernel defaults. Option D is wrong because `--read-only-port=10255` enables the read-only port on the kubelet, which serves unauthenticated read-only access and is deprecated; the CIS benchmark recommends disabling this port entirely (setting it to `0`).

Full explanation →

162

MCQmedium

You want to ensure that kubelet does not allow anonymous requests. Which flag must be set on the kubelet?

A.--anonymous-auth=false

B.--authentication-anonymous=false

C.--allow-anonymous=false

D.--read-only-port=0

AnswerA

The `--anonymous-auth=false` flag is the correct kubelet server flag to disable anonymous requests. When set to false, the kubelet's secure port (10250) rejects any request that does not present valid client credentials, returning HTTP 401. This is a core kubelet hardening setting that ensures only authenticated and authorized clients can interact with the kubelet API.

Why this answer

The kubelet's `--anonymous-auth` flag controls whether anonymous requests to the kubelet API are permitted. Setting `--anonymous-auth=false` explicitly denies all anonymous requests, ensuring that only authenticated users can interact with the kubelet. This is a critical hardening step to prevent unauthenticated access to node-level operations.

Exam trap

CNCF often tests the exact flag name `--anonymous-auth` versus similar-sounding alternatives like `--authentication-anonymous` or `--allow-anonymous`, exploiting the fact that candidates may guess based on generic naming conventions rather than knowing the precise kubelet flag syntax.

How to eliminate wrong answers

Option B is wrong because `--authentication-anonymous=false` is not a valid kubelet flag; the correct flag name is `--anonymous-auth`. Option C is wrong because `--allow-anonymous=false` does not exist as a kubelet flag; the kubelet uses `--anonymous-auth` for this purpose. Option D is wrong because `--read-only-port=0` disables the read-only port (port 10255) but does not affect anonymous authentication on the main kubelet API port (10250); anonymous requests can still be made on the secure port unless `--anonymous-auth=false` is set.

Full explanation →

163

MCQhard

A cluster has enabled the NodeRestriction admission controller. A developer is trying to create a pod with hostNetwork: true but is getting an error. What is the most likely reason?

A.The error is unrelated to NodeRestriction; the issue is likely a missing PodSecurityPolicy or Pod Security Admission that denies hostNetwork

B.The NodeRestriction admission controller blocks pods with hostNetwork

C.The nodeSelector on the pod conflicts with NodeRestriction

D.The developer lacks RBAC permissions to create pods

AnswerA

The NodeRestriction admission controller only constrains kubelet-authorized requests that modify Node or status Pod objects; it never evaluates pod specs for fields like hostNetwork. A denial mentioning hostNetwork is instead characteristic of either a deprecated PodSecurityPolicy admission plugin or the newer Pod Security Admission (baseline/restricted) which explicitly rejects hostNetwork: true. Therefore the error is not caused by NodeRestriction but by a cluster security policy.

Why this answer

The NodeRestriction admission controller only limits node self-updates to kubelet nodes, preventing them from modifying their own labels, taints, or other node objects. It does not block pods with `hostNetwork: true`. The error is most likely caused by a missing PodSecurityPolicy or Pod Security Admission (PSA) that denies pods with `hostNetwork: true`, as these are the mechanisms that enforce host namespace restrictions.

Exam trap

The trap here is that candidates confuse NodeRestriction (which restricts kubelet node updates) with PodSecurityPolicy or Pod Security Admission (which restrict pod security contexts like hostNetwork), leading them to incorrectly attribute the error to NodeRestriction.

How to eliminate wrong answers

Option B is wrong because NodeRestriction does not block pods with `hostNetwork`; it restricts kubelet modifications to node objects. Option C is wrong because `nodeSelector` is not affected by NodeRestriction; NodeRestriction only applies to node updates by the kubelet, not pod scheduling. Option D is wrong because the error is about admission control, not RBAC; if the developer lacked RBAC permissions to create pods, they would get a Forbidden error, not an admission-related error.

Full explanation →

164

MCQeasy

Which command can be used to view the current set of admission webhooks in the cluster?

A.kubectl get webhooks

B.kubectl get validatingwebhookconfigurations

C.kubectl get webhookconfigurations

D.kubectl get admissionwebhooks

AnswerB

This is the correct command. ValidatingWebhookConfiguration is a real admissionregistration.k8s.io/v1 resource that defines validation webhooks. Running 'kubectl get validatingwebhookconfigurations' lists all registered validating webhook configurations, which contain the webhook client configuration, rules, and failure policy. These resources are cluster-scoped and directly represent the admission webhooks that validate API requests.

Why this answer

Admission webhooks in Kubernetes are configured via `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` resources. The command `kubectl get validatingwebhookconfigurations` retrieves all validating admission webhooks currently registered in the cluster, which is the standard way to list them.

Exam trap

The trap here is that candidates may assume a generic `webhooks` or `admissionwebhooks` resource exists, but Kubernetes requires the exact resource names `validatingwebhookconfigurations` and `mutatingwebhookconfigurations`.

How to eliminate wrong answers

Option A is wrong because there is no `webhooks` resource type in Kubernetes; the correct resource types are `validatingwebhookconfigurations` and `mutatingwebhookconfigurations`. Option C is wrong because `webhookconfigurations` is not a valid Kubernetes API resource; the proper plural form is `validatingwebhookconfigurations` or `mutatingwebhookconfigurations`. Option D is wrong because `admissionwebhooks` is not a valid Kubernetes API resource; admission webhooks are managed through the specific `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` objects.

Full explanation →

165

Multi-Selecthard

Which THREE of the following are best practices for reducing the attack surface of Kubernetes nodes? (Select three.)

Select 3 answers

A.Use read-only root filesystems for containers where possible

B.Allow privileged containers for debugging

C.Disable unnecessary system services on nodes

D.Run containers as root to simplify management

E.Minimize host access from containers (avoid hostPID, hostNetwork, hostIPC)

AnswersA, C, E

Setting the container's root filesystem to read-only via securityContext or readOnlyRootFilesystem forces any write to use ephemeral volumes like emptyDir or a writable tmpfs, so malware cannot persist by modifying binaries, configuration, or libraries. It also prevents container processes from dropping malicious files onto the underlying image layers, significantly limiting post-exploitation activity. Where a container genuinely needs temporary writes, mount a dedicated emptyDir volume rather than loosening the root filesystem.

Why this answer

Using a read-only root filesystem for containers (e.g., setting `readOnlyRootFilesystem: true` in the container's security context) prevents attackers from writing malicious binaries or modifying system files inside the container, even if they gain code execution. This reduces the attack surface by limiting the container's ability to persist changes or escalate privileges through file system manipulation.

Exam trap

CNCF often tests the misconception that privileged containers are acceptable for debugging in production, but the CKS exam emphasizes that privileged mode should never be used in production environments because it disables all security controls and grants host-level capabilities.

Full explanation →

166

MCQmedium

The Kubernetes Dashboard is deployed in the cluster. To secure it, which of the following is a recommended practice?

A.Create a NodePort service to access it externally

B.Access it via kubectl proxy

C.Use an Ingress without TLS

D.Expose it using a LoadBalancer service for easy access

AnswerB

Using `kubectl proxy` creates a local HTTP proxy to the Kubernetes API server, which authenticates your requests using your existing kubeconfig credentials and forwards them over the cluster's internal network to the Dashboard service. By default, the proxy binds to 127.0.0.1 on your local machine, so the Dashboard is only accessible from your localhost and is never exposed to the cluster network or the public internet. This leverages the API server's built-in SSL/TLS transport and RBAC, ensuring that only users with valid cluster permissions can access the Dashboard, making it the recommended secure method.

Why this answer

Accessing the Kubernetes Dashboard via `kubectl proxy` is recommended because it creates an authenticated HTTP proxy between your local machine and the Kubernetes API server. This ensures that all traffic to the Dashboard is tunneled through the API server's authentication and authorization mechanisms, preventing direct exposure of the Dashboard to the network and reducing the attack surface.

Exam trap

CNCF often tests the misconception that exposing the Dashboard via a NodePort or LoadBalancer is acceptable for convenience, but the trap is that these methods bypass the API server's authentication layer, which is a fundamental security requirement for the Dashboard.

How to eliminate wrong answers

Option A is wrong because creating a NodePort service exposes the Dashboard on a high port across all cluster nodes, bypassing API server authentication and allowing potential network-level attacks. Option C is wrong because using an Ingress without TLS exposes the Dashboard over unencrypted HTTP, making it vulnerable to man-in-the-middle attacks and credential interception. Option D is wrong because exposing the Dashboard via a LoadBalancer service grants direct external access without the API server's authentication proxy, violating the principle of least privilege and increasing the risk of unauthorized access.

Full explanation →

167

MCQeasy

A developer is building a container image and wants to ensure that the image is free from known vulnerabilities before pushing it to a registry. The developer decides to use Trivy. Which command should the developer run to scan the image for vulnerabilities?

A.trivy fs --security-checks vuln myapp:latest

B.trivy config myapp:latest

C.trivy repository myapp:latest

D.trivy image myapp:latest

AnswerD

The trivy image command scans a container image for vulnerabilities. It pulls the image from the local Docker daemon or a registry, analyzes the installed packages, and reports any known CVEs. This is the standard way to use Trivy for image scanning. The command outputs a table of vulnerabilities by default.

Why this answer

The trivy image command is designed to scan container images for vulnerabilities. It retrieves the image, analyzes its layers, and matches installed packages against vulnerability databases. The other options either target different artifact types (filesystem, configuration files) or use a non-existent subcommand, so they would not achieve the desired scan.

Exam trap

The trap here is mixing up Trivy subcommands, such as using fs or config when the target is a container image rather than a directory or IaC file.

Full explanation →

168

MCQmedium

A security scanner reports that a microservice container image contains a critical vulnerability (CVE-2024-1234) in a system library. The team cannot immediately rebuild the image. What is the most effective temporary mitigation at the Kubernetes level?

A.Apply a NetworkPolicy to block egress traffic from the Pod

B.Apply a custom seccomp profile that blocks the vulnerable syscall

C.Apply an AppArmor profile to the Pod

D.Use a PodSecurityPolicy to drop all capabilities

AnswerB

A custom seccomp profile restricts the set of syscalls a process may make, and if the scanner mapped the library CVE to a specific syscall, denying that syscall creates a direct mitigation at the kernel boundary. Even when the vulnerable library remains in the image, the exploit cannot complete because the necessary syscall is rejected with EPERM. This is the only option that acts directly on syscall invocation.

Why this answer

A custom seccomp (secure computing mode) profile can restrict the system calls (syscalls) a container is allowed to make. By blocking the specific vulnerable syscall exploited by CVE-2024-1234, you can prevent the vulnerability from being triggered at runtime without rebuilding the image. This is a temporary, Kubernetes-native mitigation that directly addresses the attack vector at the syscall level.

Exam trap

CNCF often tests the distinction between seccomp (syscall filtering) and AppArmor/SELinux (MAC on files and capabilities), leading candidates to confuse AppArmor as a syscall blocker when it is not.

How to eliminate wrong answers

Option A is wrong because blocking egress traffic with a NetworkPolicy only prevents outbound network connections; it does not prevent exploitation of a local system library vulnerability, which typically does not require network egress. Option C is wrong because AppArmor profiles enforce mandatory access control (MAC) on file paths, network, and capabilities, but they do not filter syscalls; seccomp is the correct mechanism for syscall-level restriction. Option D is wrong because dropping all capabilities with a PodSecurityPolicy (or Pod Security Admission) removes Linux capabilities like CAP_NET_RAW, but it does not block specific syscalls; the vulnerable syscall may still be invoked even with no capabilities.

Full explanation →

169

MCQmedium

You have enabled encryption at rest for Kubernetes Secrets by configuring an EncryptionConfiguration object and restarting the API server. After the configuration, you create a new Secret. However, when you retrieve the Secret using 'kubectl get secret mysecret -o yaml', the 'data' field still shows base64-encoded plaintext. Is the Secret encrypted at rest?

A.No, because only Secrets in namespaces with a specific annotation are encrypted.

B.Yes, but only if the Secret was created after the API server restart.

C.No, because the data is still visible in the API response.

D.Yes, because encryption at rest applies to the storage layer (etcd), not the API response.

AnswerD

EncryptionConfiguration encrypts Secret objects at the etcd storage layer, so the on-disk data is ciphertext. The API server decrypts before returning responses, which is why kubectl still shows base64-encoded plaintext — base64 is an encoding, not encryption, and does not indicate the at-rest state.

Why this answer

Encryption at rest in Kubernetes protects data when it is stored in etcd, the underlying key-value store. The API server decrypts the data transparently when serving it via the API, so the base64-encoded plaintext visible in `kubectl get secret -o yaml` is the decrypted output, not the raw encrypted data. The EncryptionConfiguration object ensures that new or updated Secrets are encrypted before being written to etcd, but the API response always shows the plaintext after decryption.

Exam trap

The trap here is that candidates mistakenly believe that if the Secret data is readable in the kubectl output, it is not encrypted at rest. However, encryption at rest applies to the storage layer (etcd), and the API server decrypts on retrieval.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not require a namespace annotation to enable encryption at rest; encryption is applied cluster-wide based on the EncryptionConfiguration resource. Option B is wrong because encryption at rest applies to any Secret written to etcd after the API server restart, regardless of when it was created, as long as the EncryptionConfiguration is active. Option C is wrong because the visibility of plaintext in the API response is expected—encryption at rest protects data on disk (etcd), not in transit or in API responses, which are decrypted by the API server before serving.

Full explanation →

170

MCQmedium

A developer creates a pod with the following YAML: apiVersion: v1 kind: Pod metadata: name: mypod spec: serviceAccountName: default automountServiceAccountToken: true containers: - name: app image: nginx What is the security concern with this configuration?

A.The pod does not specify resource limits

B.The container runs as root

C.The service account token is automatically mounted, potentially providing excessive permissions

D.The pod uses the 'default' namespace

AnswerC

By default, Kubernetes mounts the service account token into every pod at /var/run/secrets/kubernetes.io/serviceaccount/token unless automountServiceAccountToken is explicitly set to false. This token is a bearer credential that grants API access based on the service account's RBAC bindings, and using the default service account often includes more permissions than the application actually needs. If the container is compromised, an attacker can retrieve this token and authenticate to the Kubernetes API to escalate privileges, read secrets, or disrupt other workloads. Thus, automatically mounting the token is the most direct security concern.

Why this answer

Setting `automountServiceAccountToken: true` (or omitting it, as it defaults to true) causes the pod to automatically mount the service account token of the `default` service account into the container. This token can grant excessive permissions if the default service account has been bound to roles with broad access, such as cluster-admin or other privileged RBAC bindings, which is a common misconfiguration. An attacker who compromises the container can then use this token to authenticate to the Kubernetes API server and perform unauthorized actions within the cluster.

Exam trap

CNCF often tests the misconception that the `default` service account is always safe or that the namespace choice is the primary risk, when in fact the automatic mounting of the service account token—especially when combined with overly permissive RBAC bindings—is the direct security concern.

How to eliminate wrong answers

Option A is wrong because while resource limits are a best practice for preventing resource starvation, their absence is not a direct security concern related to service account token exposure or privilege escalation. Option B is wrong because running as root inside a container is a security concern, but the provided YAML does not explicitly set `securityContext.runAsNonRoot` or `runAsUser`, so it is not guaranteed that the container runs as root; the nginx image may run as a non-root user by default in newer versions, and the question specifically asks about the security concern with the given configuration, which highlights the token mount. Option D is wrong because using the 'default' namespace is not inherently a security issue; namespaces are logical isolation boundaries, and the security risk comes from the service account token being mounted, not the namespace itself.

Full explanation →

171

Multi-Selectmedium

Which TWO of the following are tools for image signing and verification? (Select TWO)

Select 2 answers

A.Cosign

B.Trivy

C.kubesec

D.Syft

E.Notary

AnswersA, E

Cosign is a CLI tool from the Sigstore project specifically designed for signing and verifying container images. It supports traditional key-based signing as well as keyless signing using ephemeral keys bound to OIDC identities, and it stores signatures as separate tags in an OCI registry. Verification retrieves the signature and checks it against the image digest, optionally enforcing policy at deploy time through admission controllers like Kyverno.

Why this answer

Cosign is correct because it is a tool specifically designed for container image signing and verification, leveraging Sigstore's keyless signing capabilities and integration with OCI registries. It enables developers to sign images using ephemeral keys and verify signatures against transparency logs, ensuring supply chain integrity.

Exam trap

The CKS exam often tests the distinction between tools that perform signing/verification versus those that scan for vulnerabilities or generate SBOMs, leading candidates to confuse Trivy or Syft with signing tools.

Full explanation →

172

MCQmedium

You run 'kubectl exec -it <pod> -- /bin/sh' inside a pod that has an immutable root filesystem. What happens?

A.The command fails with an error because the container has an immutable root filesystem

B.The shell starts and can write to any directory because 'exec' bypasses the restriction

C.The shell starts successfully, but any attempt to write to the root filesystem will be denied

D.The pod is restarted with a writable filesystem

AnswerC

A successful kubectl exec starts a shell only if the container image contains that shell binary; the readOnlyRootFilesystem flag does not block process creation. Once the shell is running, it inherits the container's read-only root mount, meaning operations like touch /file or redirecting output to /root/out.txt will fail with a read-only file system error. Only paths backed by writable volumes defined in the pod spec, such as emptyDir or a mounted persistent volume, will accept writes.

Why this answer

When a container has an immutable root filesystem (e.g., readOnlyRootFilesystem: true in Kubernetes), the root filesystem is mounted as read-only. Running 'kubectl exec' to start a shell will succeed because the shell binary is already present and executable. However, any attempt to write to the root filesystem (e.g., creating a file) will be denied with a 'Read-only file system' error.

The shell itself does not bypass the restriction.

Exam trap

CKS often tests the misconception that 'exec' provides privileged access that bypasses securityContext restrictions, when in fact it operates within the same constraints.

How to eliminate wrong answers

Option A is wrong because the command does not fail; the shell starts successfully since the binary is readable and executable. Option B is wrong because 'exec' does not bypass the read-only restriction; it simply runs a process in the container's existing namespaces and filesystem. Option D is wrong because the pod is not restarted; the immutable filesystem is a static configuration, and no restart is triggered by an exec command.

Full explanation →

173

MCQeasy

What is the purpose of the 'automountServiceAccountToken: false' setting in a Pod spec?

A.It disables the service account controller

B.It prevents the automatic mounting of the service account token into the pod

C.It deletes the service account after the pod starts

D.It prevents the pod from using any service account

AnswerB

When automountServiceAccountToken is set to false on a Pod or on the ServiceAccount it references, the kubelet does not automatically project the service account token into the container filesystem at the default path /var/run/secrets/kubernetes.io/serviceaccount/token. This reduces the risk of token extraction from a compromised container. The pod still runs with the specified service account identity, but the credential is not provided automatically; any use of the token would require explicit, manual mounting.

Why this answer

Setting `automountServiceAccountToken: false` in a Pod spec prevents the automatic mounting of the Kubernetes service account token (a JWT) into the Pod's filesystem at `/var/run/secrets/kubernetes.io/serviceaccount/token`. This is a security hardening measure to reduce the attack surface for compromised containers, as the token can be used to authenticate to the Kubernetes API server. By default, Kubernetes mounts this token into every Pod, so explicitly disabling it is necessary when the Pod does not require API access.

Exam trap

CNCF often tests the misconception that disabling token mounting also disables the service account entirely, but the service account remains assignable and usable for other purposes (e.g., RBAC bindings), and the token can still be manually mounted if needed.

How to eliminate wrong answers

Option A is wrong because disabling the automatic mount of the service account token does not affect the service account controller; the controller continues to manage service accounts and their tokens independently. Option C is wrong because the setting does not delete the service account after the Pod starts; service accounts are persistent resources that remain until explicitly deleted. Option D is wrong because the Pod can still use a service account (e.g., via `serviceAccountName`), but the token is not automatically mounted; the Pod could still access the token if manually mounted or if the service account is used for other purposes like pod identity.

Full explanation →

174

MCQmedium

A DevOps engineer wants to ensure that a container image is signed and the signature is verified before deployment. Which Cosign command verifies an image signature?

A.cosign sign

B.cosign check

C.cosign verify

D.cosign attest

AnswerC

cosign verify is the correct command because it verifies the digital signature of a container image against a trusted public key. It checks that the signature is valid for the image's digest and that the image has not been tampered with. If the signature is missing or invalid, the command fails, thereby confirming the image's authenticity and integrity.

Why this answer

The `cosign verify` command is used to check the signature of a container image against the public key that was used to sign it. This ensures the image's integrity and authenticity before deployment, which is a core requirement of the CKS Supply Chain Security domain.

Exam trap

The trap here is that candidates confuse `cosign verify` with `cosign attest`, as both deal with image integrity, but `attest` creates metadata while `verify` checks the actual signature.

How to eliminate wrong answers

Option A is wrong because `cosign sign` is used to create and attach a signature to a container image, not to verify an existing signature. Option B is wrong because `cosign check` is not a valid Cosign command; the correct command for verification is `cosign verify`. Option D is wrong because `cosign attest` is used to create an in-toto attestation (a signed metadata statement about the image), not to verify the image's signature.

Full explanation →

175

MCQmedium

A container needs to run with the NET_ADMIN capability to modify network settings. The cluster enforces the baseline Pod Security Standard. Which securityContext configurations are valid? (Select all that apply.)

A.capabilities: add: ["NET_ADMIN"]

B.linuxCapabilities: add: ["NET_ADMIN"]

C.capabilities: drop: ["ALL"] add: ["NET_ADMIN"]

D.capabilities: drop: ["NET_ADMIN"]

AnswerA, C

Correct. Adding NET_ADMIN directly is allowed under the baseline PSS.

Why this answer

Under the baseline Pod Security Standard (PSS), both options A and C are valid because the baseline profile permits adding specific capabilities like NET_ADMIN. Option A directly adds NET_ADMIN to the container's capabilities. Option C drops all capabilities first and then adds NET_ADMIN, which is also compliant because dropping all is allowed under baseline, and then adding NET_ADMIN is permitted.

Option B uses an invalid field name (linuxCapabilities should be capabilities). Option D drops NET_ADMIN, which would remove the required capability.

Exam trap

Candidates often assume that dropping all capabilities is required (as in the restricted profile) even when the baseline profile is in effect. Both option A and C are valid under baseline; the trap is thinking only one is correct.

How to eliminate wrong answers

Option B is wrong because `linuxCapabilities` is not a valid field in the Kubernetes securityContext; the correct field is `capabilities`. Option C is wrong because dropping all capabilities (`drop: ["ALL"]`) is unnecessary under the baseline PSS, which does not require dropping all capabilities, and it would remove capabilities that the container might need for normal operation, potentially breaking functionality. Option D is wrong because dropping NET_ADMIN would remove the very capability required to modify network settings, making the container unable to perform its intended task.

Full explanation →

176

MCQeasy

Which flag should you set on the kube-apiserver to disable anonymous authentication?

A.--disable-anonymous=true

B.--anonymous-auth=false

C.--enable-anonymous-auth=false

D.--auth-mode=RBAC

AnswerB

Setting --anonymous-auth=false instructs the kube-apiserver to reject any request that does not arrive with valid credentials from one of its configured authenticators (client certificates, bearer tokens, OIDC, webhooks). Without this flag, unauthenticated requests are mapped to the system:anonymous user and system:unauthenticated group and proceed to the authorization stage, where RBAC rules or other authorizers may or may not have permissions. Disabling anonymous authentication means such requests immediately get a 401 Unauthorized response, effectively reducing the attack surface for pre-auth exploitation.

Why this answer

The `--anonymous-auth` flag on the kube-apiserver controls whether anonymous requests are allowed. Setting `--anonymous-auth=false` explicitly disables anonymous authentication, meaning requests without valid credentials will be rejected with a 401 Unauthorized response. This is the correct parameter to harden the API server against unauthenticated access.

Exam trap

The trap here is that candidates confuse authentication flags with authorization flags (like `--authorization-mode=RBAC`) or invent non-existent flags like `--disable-anonymous`, when the actual flag uses a simple boolean `--anonymous-auth`.

How to eliminate wrong answers

Option A is wrong because `--disable-anonymous=true` is not a valid kube-apiserver flag; the correct flag is `--anonymous-auth`. Option C is wrong because `--enable-anonymous-auth=false` does not exist; the flag uses the `--anonymous-auth` boolean directly, not a negated form. Option D is wrong because `--auth-mode=RBAC` is not a valid flag; RBAC is configured via `--authorization-mode=RBAC` and controls authorization, not authentication, so it does not disable anonymous access.

Full explanation →

177

MCQmedium

A security engineer wants to enable mutual TLS (mTLS) between services in an Istio service mesh. Which Istio resource should be used to define the mTLS mode for the entire mesh?

A.DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL

B.PeerAuthentication with mTLS mode set to STRICT

C.VirtualService with tls configuration

D.ServiceEntry with mTLS enabled

AnswerB

PeerAuthentication with mTLS mode set to STRICT is the correct approach because PeerAuthentication is the Istio policy resource that enforces TLS at the server side. When mode: STRICT is applied, the sidecar proxy requires all incoming connections to use mutual TLS and rejects plaintext traffic, thereby enforcing mTLS for the selected workloads. This can be set at the mesh, namespace, or workload level, making it the standard way to enable mesh-wide mTLS.

Why this answer

PeerAuthentication is the Istio resource specifically designed to define the authentication policy for workloads, including the mTLS mode. Setting `mTLS.mode: STRICT` in a PeerAuthentication policy enforces mutual TLS for all traffic within the mesh, ensuring that every service-to-service connection requires a valid client certificate. This is the correct resource for mesh-wide mTLS enforcement, as it operates at the authentication layer rather than the traffic routing layer.

Exam trap

A common pitfall in the CKS exam is confusing DestinationRule (which handles traffic routing and connection pool settings) with PeerAuthentication (which handles mTLS enforcement). Candidates often choose DestinationRule because it has a tls field, but for mesh-wide mTLS, PeerAuthentication with mode: STRICT is the correct resource.

How to eliminate wrong answers

Option A is wrong because DestinationRule with `trafficPolicy.tls.mode: ISTIO_MUTUAL` configures TLS settings for traffic routing and load balancing, but it does not enforce authentication or mTLS at the service identity level; it only specifies the TLS mode for connections to a specific host, not the entire mesh. Option C is wrong because VirtualService is used for traffic routing, retries, and fault injection, not for defining mTLS or authentication policies; it has no `tls` configuration for mTLS mode. Option D is wrong because ServiceEntry is used to register external services into the mesh, not to define mTLS policies for internal mesh traffic; enabling mTLS on a ServiceEntry would apply to external endpoints, not the entire mesh.

Full explanation →

178

MCQeasy

What is the default seccomp profile applied when a pod's security context has 'seccompProfile.type: RuntimeDefault'?

A.The profile defined in /var/lib/kubelet/seccomp/default.json

B.Unconfined (no seccomp)

C.The Docker default profile, which blocks around 300 syscalls

D.The container runtime's default seccomp profile, which blocks around 40 syscalls

AnswerD

With seccompProfile.type set to RuntimeDefault, the kubelet asks the container runtime (e.g., containerd) to apply its built-in default seccomp filter. This runtime-owned profile blocks roughly 40 syscalls that are considered dangerous or unnecessary in a container, such as mounting filesystems or kernel module loading, while allowing normal application syscalls. It is the correct answer because it accurately names both the source (the runtime) and the approximate number of blocked syscalls.

Why this answer

When `seccompProfile.type: RuntimeDefault` is set in a pod's security context, the container runtime (e.g., containerd or CRI-O) applies its own default seccomp profile. This runtime default profile is a curated allowlist that blocks approximately 40 syscalls known to be dangerous or unnecessary for containers, providing a balance between security and compatibility. It is not the Docker default (which blocks ~300 syscalls) but a more permissive profile tailored to the runtime's container model.

Exam trap

CNCF often tests the misconception that `RuntimeDefault` refers to Docker's legacy default profile (which blocks ~300 syscalls), when in fact it refers to the container runtime's own default (which blocks ~40 syscalls), and candidates may confuse it with `Unconfined` or a custom localhost path.

How to eliminate wrong answers

Option A is wrong because `/var/lib/kubelet/seccomp/default.json` is a custom seccomp profile path that can be specified via `seccompProfile.type: Localhost`, not the default applied by `RuntimeDefault`. Option B is wrong because `Unconfined` is a separate seccomp profile type (`seccompProfile.type: Unconfined`) that disables seccomp entirely, whereas `RuntimeDefault` explicitly enables the runtime's default restrictions. Option C is wrong because the Docker default profile blocks around 300 syscalls and is not the profile applied by `RuntimeDefault`; the runtime default (e.g., containerd's) is more permissive, blocking only about 40 syscalls, and is independent of Docker's profile.

Full explanation →

179

Multi-Selectmedium

Which THREE of the following are valid fields in an EncryptionConfiguration YAML to encrypt secrets at rest?

Select 3 answers

A.providers

B.resources

C.apiVersion

D.key

E.kind

AnswersB, C, E

"resources" is a required top-level field in an EncryptionConfiguration. It is an array of objects, each of which contains a "resources" list (e.g., secrets, configmaps) and a "providers" list (e.g., aescbc, identity). This field defines which resource types are encrypted and in what order the providers are used for encryption and decryption, making it the core of the configuration.

Why this answer

`resources` is a valid field in an EncryptionConfiguration YAML that specifies which Kubernetes resources (e.g., secrets) should be encrypted. The EncryptionConfiguration object defines how to encrypt data at rest in etcd, and the `resources` field lists the resource types to encrypt, such as `secrets`. Without this field, the encryption configuration would not know which resources to apply encryption to.

Exam trap

CNCF often tests the distinction between top-level fields and nested fields in EncryptionConfiguration, so candidates mistakenly select `providers` as a top-level field when it actually belongs under `resources`.

Full explanation →

180

MCQmedium

A security best practice is to avoid storing sensitive data in environment variables. Instead, secrets should be mounted as volumes. Which of the following YAML snippets correctly mounts a Kubernetes Secret named 'db-secret' as a volume at /etc/secrets?

A.volumes: - name: secret-volume secret: name: db-secret containers: - name: app volumeMounts: - name: secret-volume mountPath: /etc/secrets

B.volumes: - name: secret-volume configMap: name: db-secret containers: - name: app volumeMounts: - name: secret-volume mountPath: /etc/secrets

C.volumes: - name: secret-volume secret: secretName: db-secret containers: - name: app volumeMounts: - name: secret-volume mountPath: /etc/secrets

D.containers: - name: app env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password

AnswerC

This option correctly defines a Secret volume by specifying the 'secretName' field to reference the 'db-secret' Secret object, then mounts it at the desired path of /etc/secrets. Mounting the Secret as a volume exposes each key as a file containing the corresponding value, which is a more secure pattern than passing secrets via environment variables because files are less likely to appear in process listings or container logs. This is the correct way to satisfy the requirement of using a volume to store sensitive data.

Why this answer

It uses the `secret` volume type with the `secretName` field to reference the 'db-secret' Secret, and mounts it at /etc/secrets via a volumeMount. This adheres to the best practice of mounting secrets as volumes rather than injecting them as environment variables, which can be exposed in process listings or logs.

Exam trap

The CKS exam often tests the distinction between the `name` field (used for the volume's name) and the `secretName` field (used to reference the Secret object), leading candidates to incorrectly choose Option A which uses `name` instead of `secretName`.

How to eliminate wrong answers

Option A is wrong because it uses the `secret` volume type with a `name` field directly under `secret`, but the correct field to specify the Secret's name is `secretName`, not `name`. Option B is wrong because it uses a `configMap` volume type instead of `secret`, which would mount a ConfigMap named 'db-secret' rather than the intended Secret. Option D is wrong because it injects the secret value as an environment variable using `secretKeyRef`, which violates the best practice of avoiding sensitive data in environment variables.

Full explanation →

181

Multi-Selecthard

Which THREE of the following are best practices for securing the software supply chain in Kubernetes?

Select 3 answers

A.Run containers as root to avoid permission issues

B.Sign container images and verify signatures in the CI/CD pipeline

C.Use admission controllers like OPA/Gatekeeper to enforce image policies

D.Use mutable tags like 'latest' for easier updates

E.Scan container images for known vulnerabilities before deployment

AnswersB, C, E

Signing images with tools like Cosign and verifying those signatures during CI/CD ensures tampered or unauthorised artefacts never reach the registry or cluster. This satisfies the supply chain requirement by establishing cryptographic provenance before deployment, catching compromise at the earliest pipeline stage.

Why this answer

Option B is correct because cryptographically signing container images (e.g., with Sigstore/Cosign or Notary) and verifying those signatures in the CI/CD pipeline ensures that only trusted, unmodified images are deployed, preventing tampering and supply-chain injection. Option C is correct because admission controllers such as OPA/Gatekeeper (or Kyverno) enforce policies at admission time, blocking images that violate rules like untrusted registries, missing signatures, or disallowed configurations before pods are created. Option E is correct because scanning images for known CVEs (e.g., with Trivy, Grype, or Clair) before deployment identifies vulnerable dependencies and base images, allowing remediation prior to production.

Option A is not a best practice: running containers as root violates least privilege and increases the blast radius of a compromise; instead, use non-root users and restricted security contexts. Option D is not a best practice: mutable tags like 'latest' are non-deterministic and can silently pull different images, undermining reproducibility and integrity; immutable, digest-pinned tags should be used instead.

Exam trap

The CNCF CKS exam often tests the misconception that running containers as root is acceptable for 'simplicity' or that mutable tags are harmless, but both directly undermine supply chain security guarantees.

Full explanation →

182

Multi-Selecthard

Which THREE of the following are characteristics of container sandboxing runtimes like gVisor and Kata Containers?

Select 3 answers

A.They eliminate the need for seccomp profiles

B.They require setting spec.runtimeClassName in the pod spec

C.They have higher performance overhead compared to runc

D.They share the host kernel directly

E.They provide stronger isolation than default runc

AnswersB, C, E

Kubernetes selects the container runtime for a pod through the optional `.spec.runtimeClassName` field, which references a pre-defined RuntimeClass object. The RuntimeClass has a handler like 'runsc' or 'kata' that tells the kubelet which runtime to use. If omitted, the default runc runtime is used; therefore, opting into sandboxing requires explicitly setting runtimeClassName in the pod spec.

Why this answer

Container sandboxing runtimes like gVisor and Kata Containers are not the default runtime in Kubernetes. To use them, you must specify the runtime class name in the pod spec via `spec.runtimeClassName`. This field references a `RuntimeClass` resource that defines which container runtime (e.g., `gvisor`, `kata`) should be used for that pod, overriding the default runc runtime.

Exam trap

The CKS exam often tests the misconception that sandboxing runtimes eliminate the need for other security mechanisms like seccomp, when in reality they are complementary layers, and that these runtimes share the host kernel (they do not, which is the entire point of their isolation).

Full explanation →

183

Multi-Selectmedium

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

Select 2 answers

A.Response

B.None

C.Metadata

D.Log

E.Full

AnswersB, C

None is a valid and correct Kubernetes audit level. When set in an audit policy rule, None means that no audit event is logged for requests that match that rule. It is commonly used to exclude high-noise, low-risk endpoints such as health checks, static assets, or service account token requests. Using None for specific rules helps reduce storage and performance overhead while still logging important actions at other levels.

Why this answer

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.

Exam trap

CKS often tests the exact four audit levels (None, Metadata, Request, RequestResponse) and candidates frequently confuse them with logging levels or invent plausible-sounding names like 'Response', 'Log', or 'Full'.

Full explanation →

184

MCQhard

A cluster uses PodSecurity admission. A namespace has the label 'pod-security.kubernetes.io/enforce: baseline'. A user creates a pod that runs a container with 'privileged: true'. What happens?

A.The pod is rejected by the admission controller.

B.The pod is created but flagged with a warning.

C.The pod is created successfully because privileged is allowed at baseline.

D.The pod is created but the privileged setting is ignored.

AnswerA

Correct. Pod Security Admission operates at admission time: when the enforce label is set on a namespace, any pod manifest that violates the policy is rejected by the API server before it is persisted. A pod requesting privileged access (e.g., via `securityContext.privileged: true`) clearly fails the baseline profile, which forbids privileged containers. Consequently, the API server returns a validation error and the pod is never created within the namespace.

Why this answer

The PodSecurity admission controller enforces the configured security level based on the namespace label. The 'baseline' level prohibits privileged containers, so a pod with 'privileged: true' violates the policy. The admission controller rejects the pod immediately, preventing its creation.

Exam trap

The trap here is that candidates may confuse the 'baseline' profile with the 'privileged' profile, or assume that the enforce mode only warns, when in fact it blocks the pod creation entirely.

How to eliminate wrong answers

Option B is wrong because when the enforce mode is set to 'baseline', the admission controller does not just warn; it actively rejects pods that violate the policy. Option C is wrong because the 'baseline' profile explicitly disallows privileged containers; only the 'privileged' profile allows them. Option D is wrong because the PodSecurity admission controller does not silently ignore violations; it either rejects the pod or, in warn mode, logs a warning, but enforce mode means rejection.

Full explanation →

185

MCQhard

A security engineer is hardening a Kubernetes cluster and wants to ensure that any container attempting to load a kernel module is immediately detected and logged. They have deployed Falco on all nodes. Which Falco rule condition should they use to detect this activity?

A.evt.type=mmap and fd.type=module

B.evt.type=execve and proc.name contains modprobe

C.evt.type=init_module or evt.type=finit_module

D.evt.type=open and fd.name contains /lib/modules

AnswerC

Loading a kernel module involves the init_module or finit_module system calls. Falco can detect these by matching evt.type against those syscall names. This condition directly targets the kernel module loading activity, making it the correct choice for detecting when a container attempts to load a kernel module into the host kernel.

Why this answer

To detect kernel module loading, Falco must monitor the init_module and finit_module system calls, which are the actual kernel interfaces for loading modules. Matching evt.type against these syscall names provides direct, reliable detection regardless of which user-space tool or method is used to initiate the load. This condition is precise and minimizes false positives.

Exam trap

The trap here is focusing on user-space tools like modprobe instead of the underlying syscalls, which are the definitive indicator of kernel module loading.

Full explanation →

186

MCQmedium

Which of the following is a best practice for securing container images?

A.Hardcode passwords in Dockerfile as environment variables for convenience

B.Use minimal base images like distroless or Alpine

C.Use the latest tag for base images to get the newest features

D.Run containers as root to simplify permission management

AnswerB

Minimal base images like distroless or Alpine drastically reduce the attack surface by containing only the essential libraries and binaries needed to run the application, eliminating package managers, shells, and other utilities that attackers could exploit. This reduces both the number of known Common Vulnerabilities and Exposures (CVEs) and the potential for privilege escalation through less hardened components. Distroless images go further by having no shell or package manager, making them immutable and harder to compromise at runtime, while Alpine provides a small footprint and a package manager for easier dependency management. Choosing a minimal base is a foundational step in a defense-in-depth strategy.

Why this answer

Using minimal base images like distroless or Alpine significantly reduces the attack surface by eliminating unnecessary packages, libraries, and utilities that could contain vulnerabilities. Distroless images contain only the application and its runtime dependencies, while Alpine uses musl libc and BusyBox to keep the image size small and minimize the number of Common Vulnerabilities and Exposures (CVEs) that need to be patched.

Exam trap

The CKS exam tests the misconception that using the 'latest' tag is safe for development or that running as root is acceptable for simplicity, but it strictly enforces immutable tags and non-root execution as part of supply chain security.

How to eliminate wrong answers

Option A is wrong because hardcoding passwords in a Dockerfile as environment variables exposes secrets in plaintext within the image layers, making them accessible to anyone with access to the image or registry, and violates the principle of least privilege. Option C is wrong because using the 'latest' tag for base images introduces unpredictability and breaks reproducibility, as the tag can point to different image versions over time, potentially pulling in breaking changes or unpatched vulnerabilities. Option D is wrong because running containers as root violates the Pod Security Standards (PSS) 'restricted' profile and Kubernetes security best practices, as it allows the container to escape to the host via kernel vulnerabilities, and should be avoided by using a non-root user in the Dockerfile or the securityContext.runAsNonRoot field.

Full explanation →

187

MCQmedium

A cluster administrator has configured EncryptionConfiguration to encrypt secrets at rest using a local key. After applying the configuration, the administrator creates a new secret. How can they verify that the secret is encrypted at rest?

A.Run kubectl get secret -o yaml and check for an encryption annotation.

B.Use kubectl describe secret and look for 'Encrypted: true'.

C.Check the apiserver logs for encryption status messages.

D.Use etcdctl to read the secret directly from etcd and verify it is encrypted.

AnswerD

Reading the secret directly from etcd with etcdctl bypasses the API server's decryption layer, giving you the raw bytes as stored. When encryption at rest is enabled, the stored value begins with a 'k8s:enc:' prefix followed by the encryption provider name (e.g., 'aescbc'), and the payload is ciphertext. This is the only reliable method to verify that a secret is encrypted on disk, because it shows the actual storage format without any API server processing.

Why this answer

Encryption at rest is applied at the etcd storage layer, not at the Kubernetes API level. To verify that a secret is actually encrypted when stored, you must read it directly from etcd using etcdctl (with the appropriate endpoint and certificate flags). If the encryption configuration is working, the secret data will appear as base64-encoded ciphertext (e.g., starting with 'k8s:enc:aescbc:...') rather than plaintext base64 of the original secret data.

Exam trap

The trap here is that candidates assume Kubernetes CLI commands like kubectl get or describe can reveal encryption status, when in fact the API server transparently decrypts data on retrieval, so you must bypass the API server and inspect the storage backend directly.

How to eliminate wrong answers

Option A is wrong because kubectl get secret -o yaml returns the secret after it has been decrypted by the API server, so the output shows the plaintext data, not the encrypted form; there is no encryption annotation added by the EncryptionConfiguration. Option B is wrong because kubectl describe secret does not show an 'Encrypted: true' field; the describe output only displays metadata and the size of the data, not encryption status. Option C is wrong because the API server logs may indicate that encryption configuration was loaded or report errors, but they do not provide a per-secret verification that the stored data is encrypted; the definitive check is reading the raw value from etcd.

Full explanation →

188

MCQhard

A cluster has the ImagePolicyWebhook admission controller enabled. A pod creation is denied with the message 'image policy check failed'. The webhook server returns an error. Which of the following could be a valid reason?

A.The image is not signed by a trusted authority

B.The container runtime is out of date

C.The image tag does not exist in the registry

D.The pod specification has a hostNetwork: true

AnswerA

The ImagePolicyWebhook admission controller is deliberately configured to forward each image reference to an external webhook that can enforce a trust policy, typically requiring a cryptographic signature from an approved signer (e.g., via Sigstore/cosign or a private PKI). When no valid signature is found, or the signature chain does not resolve to a configured trusted authority, the webhook returns an 'admit=false' verdict, and kube-apiserver rejects the Pod before it is stored. Therefore, a denial by this controller directly indicates that the image failed the trust/signature check, not that the image is missing from the registry or that the node is misconfigured.

Why this answer

The ImagePolicyWebhook admission controller intercepts pod creation requests and queries an external webhook server to determine whether the image should be allowed. If the webhook returns an error (e.g., HTTP 5xx or a denial response), the admission controller fails the request with 'image policy check failed'. A common reason for the webhook to deny the request is that the image is not signed by a trusted authority, as the webhook may be configured to enforce image signature verification (e.g., using Notary or Sigstore).

Exam trap

The trap here is that candidates confuse admission controller errors with runtime or registry errors, but the ImagePolicyWebhook specifically checks image policy (e.g., signing) and not image existence, runtime compatibility, or pod security contexts.

How to eliminate wrong answers

Option B is wrong because an outdated container runtime does not cause an admission webhook to fail; it would cause runtime errors, not admission denial. Option C is wrong because a missing image tag would result in a pull error from the container runtime, not an admission webhook policy check failure. Option D is wrong because hostNetwork: true is a security context setting that may be restricted by PodSecurityPolicy or other admission controllers, but it is not evaluated by the ImagePolicyWebhook, which only inspects image metadata.

Full explanation →

189

Multi-Selecteasy

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

Select 2 answers

A.kubelet

B.docker

C.ctr

D.crictl

E.kubectl

AnswersC, D

ctr is containerd's native CLI that connects directly to the containerd daemon through its gRPC socket, typically /run/containerd/containerd.sock. It operates below the CRI layer and can access containerd's low-level primitives such as images, snapshots, tasks, and namespaces, providing direct and unabstracted interaction with the container runtime on the host. On many Kubernetes nodes, containerd is the underlying runtime, so ctr is a legitimate direct tool, though it requires explicit namespace knowledge when inspecting pod containers.

Why this answer

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.

Exam trap

The trap is assuming docker is still the runtime on modern clusters; since Kubernetes 1.24 removed the dockershim, docker is not the runtime, and kubectl goes through the API server rather than the runtime.

Full explanation →

190

MCQhard

You are writing a Rego policy for OPA/Gatekeeper to deny pods that do not have runAsNonRoot set to true. Which Rego statement should the ConstraintTemplate contain?

A.violation[msg] { not input.request.object.spec.securityContext.runAsNonRoot == true }

B.deny[msg] { input.request.object.spec.securityContext.runAsNonRoot == true }

C.allow[msg] { input.request.object.spec.securityContext.runAsNonRoot == false }

D.deny[msg] { input.request.object.spec.containers[_].securityContext.runAsNonRoot == true }

AnswerA

The violation rule is the only construct Gatekeeper's constraint framework evaluates for admission decisions. By using 'not input...runAsNonRoot == true', the expression is satisfied whenever the field is absent, undefined, or set to false — including pods that omit pod-level securityContext entirely — so every non-compliant pod is denied while explicitly compliant pods pass. This matches the intended policy exactly.

Why this answer

The Rego rule `violation[msg]` is the standard pattern for Gatekeeper ConstraintTemplates to deny a resource. The condition `not input.request.object.spec.securityContext.runAsNonRoot == true` triggers a violation when the field is missing or set to false, ensuring pods do not have `runAsNonRoot` set to true. This directly enforces the requirement to deny pods without the security context.

Exam trap

The CKS exam often tests the distinction between pod-level and container-level security contexts, and the trap here is that candidates may incorrectly use `deny[msg]` with a positive condition or check container-level fields instead of the pod-level `runAsNonRoot` field.

How to eliminate wrong answers

Option B is wrong because it uses `deny[msg]` with a condition that checks `runAsNonRoot == true`, which would deny pods that have it set correctly, the opposite of the requirement. Option C is wrong because it uses `allow[msg]`, which is not a valid Rego keyword in Gatekeeper; the correct pattern is `violation[msg]` or `deny[msg]`, and the condition `runAsNonRoot == false` would allow pods without the setting, failing to deny them. Option D is wrong because it checks `runAsNonRoot` only at the container level (`spec.containers[_].securityContext.runAsNonRoot`), but the requirement is to check the pod-level `spec.securityContext.runAsNonRoot`, and it also uses `deny[msg]` with a condition that would deny pods with the setting set to true.

Full explanation →

191

Multi-Selecteasy

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

Select 2 answers

A.MEDIUM

B.LOW

C.WARNING

D.HIGH

E.CRITICAL

AnswersC, E

WARNING is a valid Falco priority and represents a mid-to-high severity condition that should be investigated but does not necessarily require immediate emergency response. It sits between NOTICE and ERROR in Falco's syslog-compatible priority ladder. For example, detecting a shell inside a container often uses WARNING or NOTICE depending on policy.

Why this answer

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.

Exam trap

The trap is assuming that common severity labels like HIGH, MEDIUM, or LOW are valid in Falco, when in fact Falco uses syslog-style priorities.

Full explanation →

192

Multi-Selectmedium

Which TWO of the following are CIS Benchmark recommendations for securing the Kubernetes API server? (Select TWO)

Select 2 answers

A.Disable RBAC

B.Enable audit logging

C.Disable anonymous authentication

D.Enable anonymous authentication

E.Use TLS 1.0

AnswersB, C

CIS recommends enabling audit logging on the Kubernetes API server to capture a chronological record of all API requests, including who made them, what actions were attempted, and the outcome. These logs are essential for detecting suspicious activities, investigating security incidents, and satisfying compliance requirements. Configuring an audit policy with the appropriate verbosity and event types ensures that critical security-relevant events are logged without excessive noise.

Why this answer

The CIS Benchmark for Kubernetes recommends enabling audit logging to record all API server requests, which is essential for security monitoring, incident response, and compliance. Audit logs capture the sequence of actions performed by users, administrators, and system components, providing an immutable record that can be analyzed for suspicious activity or policy violations.

Exam trap

CNCF often tests the distinction between authentication and authorization, so candidates may confuse disabling anonymous authentication (a correct security practice) with enabling RBAC (also correct), but the trap is that the question asks for two specific CIS Benchmark recommendations, and disabling RBAC is never recommended—it is a dangerous misconfiguration.

Full explanation →

193

Multi-Selectmedium

Which two of the following are best practices for container image security? (Select TWO.)

Select 2 answers

A.Maximize the number of layers to improve caching

B.Run containers as a non-root user

C.Use pinned SHA digests for base images

D.Use the 'latest' tag for flexibility

E.Use old base images to avoid breaking changes

AnswersB, C

Running containers as a non-root user follows the principle of least privilege. If a process is compromised, a non-root user inside the container cannot perform privileged operations on the host kernel, such as writing to host system files or using raw sockets. Even with a container escape, the attacker would lack root privileges on the host, significantly reducing the blast radius. Use USER instructions in the Dockerfile and avoid privileged containers.

Why this answer

Running containers as a non-root user follows the principle of least privilege, reducing the risk of privilege escalation if the container is compromised. By default, Docker containers run as root, but using the USER directive in the Dockerfile or specifying a non-root user at runtime (e.g., --user 1000) limits the attacker's ability to modify system files or escape the container.

Exam trap

A common trap is thinking that the 'latest' tag is safe for production because it always gets the newest version. Actually, 'latest' is mutable and can point to any arbitrary image, including malicious ones, making it a supply chain risk.

Full explanation →

194

MCQeasy

Which kubectl command creates a validating webhook configuration that calls an external HTTPS endpoint for pod validation?

A.kubectl create admission webhook --validate

B.kubectl run webhook --image=...

C.kubectl apply -f webhook.yaml

D.kubectl create validatingwebhookconfiguration --url=https://...

AnswerC

`kubectl apply -f webhook.yaml` is the correct approach because ValidatingWebhookConfiguration is a declarative API resource defined in YAML. The manifest contains the essential fields: clientConfig (url or service reference and caBundle), rules, failurePolicy, and admissionReviewVersions. Running kubectl apply sends this manifest to the API server, which persists the configuration and immediately activates the webhook for matching requests. This is the only reliable way to create such cluster-scoped admission configurations.

Why this answer

`kubectl apply -f webhook.yaml` is the standard way to create any Kubernetes resource, including a ValidatingWebhookConfiguration, from a YAML manifest. The manifest defines the webhook's client configuration, including the external HTTPS endpoint, CA bundle, and rules for pod validation. There is no dedicated `kubectl create` subcommand for webhooks; the resource must be defined declaratively in a YAML file.

Exam trap

The trap here is that candidates assume there is a dedicated `kubectl create` subcommand for webhooks (like `kubectl create validatingwebhookconfiguration`), but Kubernetes requires webhooks to be defined declaratively via YAML/JSON, not imperatively with flags.

How to eliminate wrong answers

Option A is wrong because `kubectl create admission webhook --validate` is not a valid kubectl command; Kubernetes does not have a built-in `admission webhook` subcommand. Option B is wrong because `kubectl run webhook --image=...` creates a Pod, not a ValidatingWebhookConfiguration resource; it would run a container but not register any webhook with the API server. Option D is wrong because `kubectl create validatingwebhookconfiguration --url=https://...` is not a valid syntax; kubectl's `create` subcommand does not support inline `--url` flags for webhooks—the resource must be defined via a YAML file or JSON.

Full explanation →

195

MCQmedium

Which kubectl command can be used to view the audit log policy currently in use by the API server?

A.kubectl logs -n kube-system kube-apiserver-<node> | grep audit

B.kubectl describe clusterrolebinding audit

C.kubectl get -n kube-system pods kube-apiserver-<node> -o yaml | grep audit-policy-file

D.kubectl get auditpolicy

AnswerC

This command is correct because it retrieves the complete JSON/YAML specification of the kube-apiserver static pod from the cluster's API. Inside that output, the container's command array contains the --audit-policy-file flag, and the volume mounts section shows the corresponding hostPath mapping, such as /etc/kubernetes/audit-policy.yaml. By grepping for 'audit-policy-file', you directly extract the exact path to the audit policy file. This is the standard, non-intrusive way to verify which audit policy the API server is using, since static pod specs are automatically reflected in the pod object.

Why this answer

The audit policy file path is specified in the kube-apiserver manifest (usually a static pod YAML in /etc/kubernetes/manifests/). Running `kubectl get pod kube-apiserver-<node> -n kube-system -o yaml` and grepping for `audit-policy-file` reveals the exact path to the policy file currently in use, which is the authoritative way to confirm which audit policy the API server is loading.

Exam trap

The trap here is that candidates assume audit logs can be viewed via `kubectl logs` (Option A) or that audit policies are a native Kubernetes resource (Option D), when in fact the audit policy is a file referenced by a command-line flag in the API server manifest and must be inspected indirectly.

How to eliminate wrong answers

Option A is wrong because `kubectl logs` shows the API server's runtime logs, which may contain audit log entries but does not reveal the audit policy file path or its contents; grepping for 'audit' in logs is unreliable and not the intended method to view the policy. Option B is wrong because `clusterrolebinding audit` is not a standard Kubernetes resource; there is no default ClusterRoleBinding named 'audit' related to audit policies, and this command would fail or return unrelated RBAC information. Option D is wrong because `kubectl get auditpolicy` is not a valid kubectl command; audit policies are not a native Kubernetes API resource and cannot be retrieved with `kubectl get`.

Full explanation →

196

Multi-Selecthard

Which TWO of the following are valid AppArmor profile modes? (Select 2 correct answers)

Select 2 answers

A.enforce

B.disabled

C.audit

D.unconfined

E.complain

AnswersA, E

Enforce is the default and primary AppArmor profile mode: when a profile is loaded in enforce mode, the kernel actively blocks any operation that violates the profile's rules and logs the denial to the audit log. This is the mode used in production to actually restrict a container's capabilities, because it rejects unauthorized syscalls, file accesses, or network operations rather than merely reporting them.

Why this answer

AppArmor profile modes determine how the Mandatory Access Control (MAC) policy is applied. 'Enforce' (option A) actively enforces the profile's rules, blocking any actions that violate the policy and logging the denial. 'Complain' (option E) logs policy violations without blocking them, allowing for testing and debugging of profiles before switching to enforce mode.

Exam trap

The CNCF-CKS exam often tests the distinction between profile modes and module states; the trap here is that 'disabled' and 'audit' sound plausible but are not actual AppArmor profile modes—'disabled' refers to the AppArmor kernel module being off, and 'audit' is a rule-level flag, not a profile mode.

Full explanation →

197

MCQhard

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?

A.kubectl logs <pod> && kubectl describe pod <pod>

B.kubectl cp <pod>:/ -c <container> /tmp/forensic && kubectl logs <pod> --previous

C.kubectl exec <pod> -- cat /proc/1/cmdline && kubectl exec <pod> -- ls -la /

D.kubectl exec -it <pod> -- bash && kubectl exec <pod> -- cat /var/log/syslog

AnswerA

Running `kubectl logs <pod>` and `kubectl describe pod <pod>` only retrieves the current container's stdout/stderr logs and pod metadata from the API server. These commands do not access the container's filesystem, process state, or previous terminated container instances, so critical forensic artifacts like binary payloads, configuration changes, or crash evidence remain hidden. Furthermore, they capture live data that can change during investigation, making them unsuitable for preserving a reliable evidentiary snapshot.

Why this answer

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.

Exam trap

A common trap is assuming `kubectl cp` is non-invasive because it copies files. In reality, `kubectl cp` uses `kubectl exec` to run `tar` inside the container, which changes the container's state. Any command executed via `kubectl exec`—including those under the hood of `kubectl cp`—is disallowed when the requirement is to preserve the container's state.

Non-invasive options are limited to read-only API calls like `kubectl logs` and `kubectl describe`.

How to eliminate wrong answers

Option A is wrong because `kubectl logs` and `kubectl describe pod` only retrieve metadata and current logs, but do not capture the container's filesystem or state for offline analysis, and `kubectl logs` may alter the log stream or trigger log rotation. Option C is wrong because `kubectl exec` runs commands inside the container, which modifies the container's state (e.g., creates new processes, updates /proc, changes atime on accessed files), potentially destroying forensic evidence. Option D is wrong because `kubectl exec -it -- bash` opens an interactive shell that creates new processes and modifies the container's runtime state, and `cat /var/log/syslog` may not exist in containerized environments (containers typically log to stdout/stderr, not syslog), while also altering file access times.

Full explanation →

198

Drag & Dropmedium

Arrange the steps to configure and use kube-bench to audit a Kubernetes cluster's security.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

kube-bench audits CIS benchmarks. After installation, run it, analyze results, remediate, and re-audit.

Full explanation →

199

MCQeasy

Which flag should be set on the kube-apiserver to disable anonymous authentication?

A.--enable-anonymous=false

B.--anonymous-auth=false

C.--anonymous-enabled=false

D.--authentication-mode=Anonymous

AnswerB

This is the correct flag. The kube-apiserver defaults --anonymous-auth to true, allowing requests without credentials to be attributed to the system:anonymous user in the system:unauthenticated group. Setting --anonymous-auth=false forces the apiserver to reject every unauthenticated request with a 401 HTTP error unless they present a valid bearer token or client certificate. Disable it only when you have guaranteed all legitimate clients, including health probes and kubelets, authenticate through other means such as the kubeconfig's client certificates.

Why this answer

The `--anonymous-auth=false` flag explicitly disables anonymous authentication on the kube-apiserver. By default, anonymous requests are allowed (with a system:anonymous user), so setting this flag to false prevents unauthenticated users from accessing the API server. This is a key hardening measure to ensure only authenticated clients can interact with the cluster.

Exam trap

The trap here is that candidates confuse the `--anonymous-auth` flag with non-existent variants like `--enable-anonymous` or `--anonymous-enabled`, or mistakenly think anonymous authentication is controlled via an `--authentication-mode` flag.

How to eliminate wrong answers

Option A is wrong because `--enable-anonymous=false` is not a valid kube-apiserver flag; the correct flag uses `--anonymous-auth`, not `--enable-anonymous`. Option C is wrong because `--anonymous-enabled=false` is not a recognized flag; the kube-apiserver uses `--anonymous-auth` to control anonymous access. Option D is wrong because `--authentication-mode=Anonymous` does not exist; authentication modes are configured via `--authorization-mode` and `--authentication-token-webhook`, and anonymous authentication is controlled by the `--anonymous-auth` flag, not a mode setting.

Full explanation →

200

MCQhard

A pod is in a CrashLoopBackOff state. You run 'kubectl logs pod-name' and see: 'Error: failed to start container: exec: "/app": stat /app: no such file or directory'. What is the most likely cause?

A.The pod is out of memory

B.The container's working directory is incorrect

C.The pod has a liveness probe that is failing

D.The container image is missing the /app executable

AnswerD

This is correct: when the container image's ENTRYPOINT or CMD references an executable that is not present in the image filesystem, the container runtime fails to fork the process with an error such as 'exec: /app: no such file or directory' or 'executable file not found in $PATH'. This error is written to the container's stderr and appears in `kubectl logs`, and the container exits immediately with a non-zero exit code, causing the kubelet to restart it and enter CrashLoopBackOff. The fix is either to rebuild the image with the executable correctly installed or to adjust the command in the pod spec.

Why this answer

The error message 'exec: "/app": stat /app: no such file or directory' indicates that the container runtime (e.g., containerd) cannot find the executable specified in the container's ENTRYPOINT or CMD. This occurs when the container image does not include the /app binary or script at that path, causing the container to fail immediately on start and enter CrashLoopBackOff. Option D correctly identifies that the container image is missing the /app executable.

Exam trap

CNCF often tests the distinction between container startup failures (e.g., missing executable) and runtime failures (e.g., probe failures or resource limits), so candidates may confuse a liveness probe failure (which occurs after the container is running) with an exec error that prevents the container from starting at all.

How to eliminate wrong answers

Option A is wrong because an out-of-memory (OOM) condition would typically result in an OOMKilled status or a different error in logs, such as 'container exited with code 137', not a 'no such file or directory' exec error. Option B is wrong because an incorrect working directory (WORKDIR) does not prevent the container from starting; the container would still execute the entrypoint, though it might fail later if it tries to access files relative to that directory. Option C is wrong because a failing liveness probe would cause the container to be restarted by kubelet after the probe fails, but the initial startup error is a container runtime exec failure, not a probe-related issue.

Full explanation →

201

MCQeasy

Which of the following is a best practice when writing a Dockerfile for a containerized application?

A.Run the application as the root user for file permissions

B.Use a minimal base image such as distroless or alpine

C.Hardcode credentials in the Dockerfile for convenience

D.Use the latest tag for the base image to get the newest features

AnswerB

A minimal base image such as distroless or alpine reduces the attack surface by excluding shells, package managers and unnecessary libraries, directly satisfying the CKS requirement to minimise vulnerabilities in the container image. Distroless removes the package manager entirely, while alpine uses musl libc and a smaller package set.

Why this answer

Using a minimal base image like distroless or alpine reduces the attack surface by eliminating unnecessary packages, libraries, and utilities that could be exploited. This aligns with the principle of least privilege and minimizes the number of Common Vulnerabilities and Exposures (CVEs) in the container, which is critical for supply chain security in Kubernetes environments.

Exam trap

A common pitfall is assuming that using the 'latest' tag is safe because it gets security patches automatically, but in reality, 'latest' is mutable and can introduce unexpected vulnerabilities or break reproducibility, which is critical for supply chain security in Kubernetes environments.

How to eliminate wrong answers

Option A is wrong because running the application as root inside a container violates the principle of least privilege; if the container is compromised, an attacker gains root access on the host (due to shared kernel), and Kubernetes security contexts should enforce non-root users. Option C is wrong because hardcoding credentials in a Dockerfile exposes secrets in the image layers, making them accessible to anyone with image pull access and violating secure supply chain practices; secrets should be injected via Kubernetes Secrets or external vaults at runtime. Option D is wrong because using the 'latest' tag introduces unpredictability and breaks reproducibility; base image updates can introduce breaking changes or new vulnerabilities without explicit version pinning, which undermines supply chain integrity.

Full explanation →

202

MCQmedium

A security team wants to ensure that all API requests to the cluster are authenticated and uses RBAC for authorization. Which two flags must be set on the kube-apiserver?

A.--anonymous-auth=false --authorization-mode=Webhook

B.--enable-admission-plugins=NodeRestriction --authorization-mode=AlwaysAllow

C.--anonymous-auth=true --authorization-mode=ABAC

D.--anonymous-auth=false --authorization-mode=RBAC

AnswerD

Disabling anonymous access with --anonymous-auth=false ensures that every request must be authenticated before it is processed. Setting --authorization-mode=RBAC makes the API server evaluate each request against RBAC policy objects (Role, ClusterRole, RoleBinding, ClusterRoleBinding). Together these flags enforce the security team's requirement: only authenticated users, acting under explicitly assigned RBAC permissions, can perform API operations.

Why this answer

Setting --anonymous-auth=false disables unauthenticated requests, ensuring all API calls require authentication, and --authorization-mode=RBAC enforces Role-Based Access Control for authorization. This combination aligns with the security team's requirement for authenticated and RBAC-authorized API requests, as RBAC is the standard Kubernetes authorization mode for fine-grained access control.

Exam trap

The trap here is that candidates may confuse authentication with authorization, thinking that setting --anonymous-auth=false alone satisfies the requirement, or they may mistakenly choose ABAC (option C) because it is an authorization mode, but the question explicitly requires RBAC, not ABAC.

How to eliminate wrong answers

Option A is wrong because --authorization-mode=Webhook delegates authorization to an external HTTP service, not RBAC, and --anonymous-auth=false alone does not enforce RBAC. Option B is wrong because --authorization-mode=AlwaysAllow permits all requests without any authorization checks, violating the requirement for RBAC, and --enable-admission-plugins=NodeRestriction is an admission controller, not an authorization mode. Option C is wrong because --anonymous-auth=true allows unauthenticated requests, bypassing authentication, and --authorization-mode=ABAC uses Attribute-Based Access Control, not RBAC.

Full explanation →

203

Multi-Selectmedium

Which TWO of the following are valid methods to apply a seccomp profile to a Kubernetes pod? (Select two.)

Select 2 answers

A.Using the field: spec.seccompProfile

B.Using the pod annotation: seccomp.security.alpha.kubernetes.io/pod

C.Using the field: securityContext.seccompProfile.type

D.Using the command line flag: --seccomp-profile when running kubectl run

E.Using the pod annotation: container.seccomp.security.alpha.kubernetes.io

AnswersB, C

The annotation seccomp.security.alpha.kubernetes.io/pod is a legacy but still functional method to apply a seccomp profile to the entire pod. It predates the seccompProfile field in securityContext and is deprecated in favor of the structured API, yet many existing workloads still rely on it. Placing this key on the Pod object tells the runtime to use the referenced profile, making it a valid approach.

Why this answer

The seccomp.security.alpha.kubernetes.io/pod annotation was the original method to apply a seccomp profile to an entire pod in Kubernetes versions prior to v1.19. This annotation specifies the seccomp profile path or type (e.g., 'runtime/default' or 'localhost/<profile>') for the pod's containers, and it remains valid in older clusters or when using legacy configurations.

Exam trap

CNCF often tests the distinction between the GA field (securityContext.seccompProfile) and the deprecated annotation method, and candidates may confuse the incomplete annotation format (e.g., missing container name) with a valid option.

Full explanation →

204

Multi-Selectmedium

Which TWO of the following are secure practices for managing secrets in Kubernetes? (Select TWO.)

Select 2 answers

A.Store secrets as environment variables

B.Use a CSI driver to mount secrets as volumes

C.Embed secrets in container images

D.Use an external secrets manager like Vault with a sidecar

E.Store secrets in a ConfigMap

AnswersB, D

A CSI driver for secrets, such as the Secrets Store CSI Driver, mounts secrets as formatted files into the pod's filesystem, pulling them from external providers like Vault or AWS Secrets Manager at runtime. This avoids storing sensitive data in Kubernetes etcd, enables secrets to be rotated without restarting pods, and keeps secrets out of environment variables and container images, significantly reducing exposure.

Why this answer

The CSI (Container Storage Interface) driver for secrets allows secrets to be mounted as volumes without storing them in etcd or exposing them in environment variables. This approach leverages the CSI driver's ability to fetch secrets from external providers (e.g., HashiCorp Vault) on-demand, ensuring secrets are never persisted in Kubernetes objects and reducing the attack surface. It also supports rotation without pod restarts, as the volume content can be updated dynamically.

Exam trap

A common trap in Kubernetes exams is the misconception that storing secrets as environment variables is secure because they are 'in-memory'. However, environment variables are easily exposed through pod logs, exec commands, and /proc, making them less secure than volume mounts with proper access controls.

Full explanation →

205

MCQhard

A cluster uses containerd and a security team wants to block containers from loading kernel modules. They apply a pod with securityContext.seccompProfile.type set to Localhost and a profile that returns SCMP_ACT_ERRNO for the init_module and finit_module syscalls. The pod starts but a test binary still loads a module. Which is the most likely cause?

A.The seccomp profile must be stored in the container image rather than referenced by the pod, so the runtime ignored it.

B.The pod needs privileged: true for the profile to be enforced, since restricted pods skip seccomp filtering.

C.Seccomp filters cannot block init_module or finit_module because those syscalls are resolved by the kernel before the filter runs.

D.The container process runs with CAP_SYS_MODULE and the seccomp profile's default action is SCMP_ACT_ALLOW, so the errno rule was placed after a broader allow rule that matched first.

AnswerD

Seccomp evaluates rules in order and applies the first matching rule, so an early broad allow for the syscall group can shadow the later errno rule. Combined with CAP_SYS_MODULE, which grants the capability needed to load modules, the container bypasses the intended block. Reordering the deny rule above the allow and dropping the capability closes the gap.

Why this answer

Seccomp applies the first matching rule, so a broad allow placed before the errno rule for init_module and finit_module neutralizes the block. Keeping CAP_SYS_MODULE also lets the process attempt module loads. Ordering the deny rules first and removing the capability ensures the filter actually stops module loading in this container.

Exam trap

The trap here is assuming that listing a syscall with an errno action always blocks it, when an earlier matching allow rule or a retained capability can let the call succeed.

Full explanation →

206

MCQhard

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?

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

B.Use a projected volume with 'serviceAccountToken' and set 'expirationSeconds'

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

D.Use a ConfigMap to inject the token

AnswerB

A projected volume with a serviceAccountToken source and expirationSeconds issues a short-lived, audience-bound token that the kubelet rotates automatically, satisfying the requirement that the pod not rely on a long-lived legacy token. Plain secret mounts or automountServiceAccountToken alone cannot enforce expiry.

Why this answer

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.

Exam trap

This exam often tests the misconception that the default service account token is secure because it is automatically mounted, but the trap is that it is a long-lived token with no expiration, whereas the projected volume with `expirationSeconds` provides a short-lived, automatically rotated token that aligns with security best practices.

How to eliminate wrong answers

Option A is wrong because mounting the default service account token at /var/run/secrets/kubernetes.io/serviceaccount provides a long-lived token that does not expire, increasing the risk of credential misuse. Option C is wrong because setting `automountServiceAccountToken: false` and manually mounting a Secret containing a token still uses a static, long-lived token stored in a Secret, which lacks automatic rotation and expiration. Option D is wrong because a ConfigMap is used for non-sensitive configuration data and cannot inject a ServiceAccount token; tokens are sensitive credentials and must be handled via Secrets or projected volumes.

Full explanation →

207

MCQmedium

Which of the following is the correct kubectl command to view the OPA Gatekeeper ConstraintTemplates in the cluster?

A.kubectl get gatekeeper-constrainttemplates

B.kubectl describe opa constrainttemplate

C.kubectl get constrainttemplates

D.kubectl get crd -o name | grep constraint

AnswerC

This is the correct command because 'constrainttemplates' is the exact plural name of the custom resource served by the Kubernetes API after Gatekeeper's CRD is installed. kubectl get constrainttemplates works without specifying a namespace because these resources are cluster-scoped, and it directly returns the actual instances of the ConstraintTemplate custom resource, not just the CRD definition. It leverages the standard dynamic API discovery mechanism, so no additional flags or 'opa' references are required.

Why this answer

OPA Gatekeeper registers its constraints as custom resources in Kubernetes, and the standard `kubectl get constrainttemplates` command retrieves all ConstraintTemplate resources from the cluster. This works because Gatekeeper uses the Kubernetes API aggregation layer, making ConstraintTemplates a top-level resource type that kubectl can query directly.

Exam trap

The trap here is that candidates may confuse the resource name (e.g., adding 'gatekeeper-' or 'opa' prefix) or think they need to query CRDs instead of the actual resource instances, when in fact Gatekeeper resources are standard Kubernetes custom resources accessible via their short names.

How to eliminate wrong answers

Option A is wrong because `kubectl get gatekeeper-constrainttemplates` is not a valid kubectl command; Gatekeeper resources are accessed via their short name `constrainttemplates`, not with a hyphenated prefix. Option B is wrong because `kubectl describe opa constrainttemplate` uses an incorrect resource name (`opa` is not a valid resource type) and the wrong verb for listing; `describe` is for a specific resource instance, not for listing all templates. Option D is wrong because while `kubectl get crd -o name | grep constraint` would list CRD names containing 'constraint', it does not directly list the ConstraintTemplate instances themselves—only the CRD definitions, which is an indirect and incomplete approach.

Full explanation →

208

Multi-Selecthard

Which THREE of the following are recommended steps during incident response for a compromised pod?

Select 3 answers

A.Apply a NetworkPolicy to isolate the pod

B.Restart the pod by deleting and recreating it

C.Delete the pod immediately to stop the attack

D.Use kubectl exec to collect running processes and network connections

E.Preserve the pod and its logs for investigation

AnswersA, D, E

Applying a NetworkPolicy isolates the compromised pod by restricting ingress and egress traffic, satisfying the containment requirement during incident response. This prevents lateral movement to other workloads while preserving the pod for forensic analysis, rather than deleting it immediately. NetworkPolicy enforcement depends on a CNI plugin that supports it, such as Calico or Cilium.

Why this answer

Option A is correct because applying a NetworkPolicy to the compromised pod isolates it from other workloads, blocking lateral movement and command-and-control traffic while keeping the pod alive for analysis. Option D is correct because using kubectl exec to collect running processes and network connections captures volatile forensic evidence (e.g., process lists, sockets) that would be lost if the pod were terminated. Option E is correct because preserving the pod and its logs maintains the evidence chain for investigation, including container logs and cluster events needed to determine the attack's scope and root cause.

Option B is not recommended because deleting and recreating the pod destroys volatile evidence and may allow the attacker to re-establish persistence. Option C is not recommended because immediately deleting the pod erases forensic artifacts and prevents understanding the compromise, even though it might stop the immediate attack.

Exam trap

A common trap is that deleting or restarting a compromised pod is a safe containment action, when in fact it destroys critical forensic evidence and violates the 'preserve before eradicate' principle taught in the CKS curriculum.

Full explanation →

209

Multi-Selecthard

Which TWO practices improve supply chain security for container images? (Select two.)

Select 2 answers

A.Scanning images for CVEs before deployment

B.Storing secrets in the Dockerfile

C.Signing images with Cosign

D.Using the 'latest' tag for easy updates

E.Running containers as root

AnswersA, C

Scanning images for CVEs before deployment is a preventive security control that identifies known vulnerabilities in base images and installed packages by comparing them against up-to-date CVE databases. Integrating this scan into the CI/CD pipeline prevents compromised or outdated images from reaching production, reducing the risk of exploitation from publicly documented flaws and enabling teams to remediate critical issues before they are deployed.

Why this answer

Scanning images for CVEs before deployment is a core supply chain security practice because it identifies known vulnerabilities in the base image and installed packages before the container enters production. Tools like Trivy, Grype, or Clair compare the image's package inventory against vulnerability databases (e.g., NVD, OSV), allowing teams to reject or patch images with critical flaws. This proactive measure prevents attackers from exploiting unpatched software in the runtime environment.

Exam trap

A common mistake is to assume that vulnerability scanning alone is sufficient for supply chain security, while overlooking the need for image signing (e.g., with Cosign) to ensure integrity and authenticity. Both are correct answers in this question.

Full explanation →

210

Multi-Selectmedium

Which THREE of the following are restrictions enforced by the 'baseline' Pod Security Standard? (Select three.)

Select 3 answers

A.Host network access (hostNetwork) is not allowed

B.Capabilities must be limited to a minimal set (drop: ["ALL"] is not required but must not add dangerous capabilities)

C.Seccomp profile must be set to RuntimeDefault or Localhost

D.Privilege escalation must be disabled (AllowPrivilegeEscalation: false)

E.Containers must run as non-root (runAsNonRoot: true)

AnswersA, B, D

The baseline profile explicitly forbids setting hostNetwork: true, which would place the pod in the host's network namespace and expose all physical network interfaces. This isolation ensures that processes in containers cannot bind to host ports or sniff/monitor host traffic, providing a hard boundary between the pod and the underlying host. Enabling hostPID or hostIPC is also forbidden, but hostNetwork is specifically called out in the option.

Why this answer

The 'baseline' Pod Security Standard (PSS) enforces several restrictions to provide a reasonable level of security without breaking most workloads. The three correct restrictions are:

A: Host network access (hostNetwork) is not allowed. The baseline profile prohibits sharing host namespaces, including hostNetwork, to isolate pods from the host network.

B: Capabilities must be limited to a minimal set. While the baseline profile does not require dropping all capabilities (drop: ["ALL"]), it prohibits adding dangerous capabilities such as CAP_SYS_ADMIN, CAP_NET_RAW, or CAP_SYS_PTRACE. This prevents escalation of privileges through capability misuse.

D: Privilege escalation must be disabled (AllowPrivilegeEscalation: false). This is a baseline requirement to prevent processes from gaining more privileges than their parent.

Option C (seccomp profile must be set to RuntimeDefault or Localhost) and Option E (containers must run as non‑root) are both requirements of the 'restricted' profile, not the baseline. Therefore, they are incorrect selections.

Exam trap

The CKS exam often tests the distinction between baseline and restricted profiles, and the trap here is that candidates confuse the baseline's capability restriction (which only blocks dangerous capabilities, not all) with the restricted profile's stricter requirement to drop all capabilities.

Full explanation →

211

MCQmedium

An administrator wants to perform static analysis on Kubernetes manifest files to find security misconfigurations. Which tool is specifically designed for this?

A.Trivy

B.Cosign

C.Kubesec

D.Syft

AnswerC

Kubesec parses manifest YAML directly, without a running cluster, and scores it against security controls such as privileged containers, host namespaces and missing resource limits. That static, file-based scanning satisfies the stem's requirement to find misconfigurations before deployment, unlike runtime admission controllers or cluster-wide audit tools.

Why this answer

Kubesec (option C) is specifically designed for static analysis of Kubernetes manifest files to identify security misconfigurations. It evaluates YAML or JSON manifests against a set of built-in security best practices, such as ensuring containers run as non-root, avoiding privileged escalation, and setting read-only root filesystems. While Trivy can also scan Kubernetes manifests for misconfigurations as part of its broader vulnerability and IaC scanning capabilities, Kubesec is purpose-built for Kubernetes manifest security analysis and is the most specific tool among the choices.

Exam trap

CNCF often tests the distinction between general-purpose security scanners and purpose-built Kubernetes manifest analyzers. Although Trivy is a popular scanner that includes Kubernetes manifest misconfiguration scanning, it is a broader tool not specifically designed for this task; Kubesec is the dedicated tool for static analysis of Kubernetes YAML manifests. Candidates may choose Trivy due to its popularity, but Kubesec is the correct answer for a tool specifically designed for Kubernetes manifest security.

How to eliminate wrong answers

Option A (Trivy) is wrong because it is a vulnerability scanner for container images, filesystems, and Git repositories, not a static analyzer for Kubernetes manifest files. Option B (Cosign) is wrong because it is a tool for signing and verifying container image signatures, not for analyzing Kubernetes manifest configurations. Option D (Syft) is wrong because it generates a Software Bill of Materials (SBOM) from container images and filesystems, not for static analysis of Kubernetes manifests.

Full explanation →

212

MCQeasy

Which of the following is a recommended Dockerfile best practice to improve container security?

A.Hardcode secrets in environment variables in the Dockerfile

B.Run the container as root to simplify permission management

C.Use a non-root user with USER directive

D.Copy the entire host filesystem into the image

AnswerC

The USER directive drops container processes from root to an unprivileged account, so a compromised workload cannot write to protected paths or escalate host privileges. This directly satisfies the Dockerfile best-practice requirement by enforcing least privilege at runtime.

Why this answer

Running containers as root is a major security risk; if an attacker compromises the container, they gain root access to the container and potentially the host via kernel exploits. The USER directive in a Dockerfile switches the container's runtime user to a non-root user (e.g., USER 1000), reducing the blast radius by limiting privileges within the container. This aligns with the principle of least privilege and is a recommended best practice in the CKS exam for supply chain security.

Exam trap

A common trap in the CKS exam is assuming root inside a container is safe due to namespace isolation, but root still has dangerous capabilities (e.g., CAP_SYS_ADMIN) and can exploit kernel vulnerabilities to escape the container.

How to eliminate wrong answers

Option A is wrong because hardcoding secrets in environment variables in the Dockerfile embeds sensitive data in the image layers, making them accessible to anyone who can pull the image or inspect the layers; secrets should be injected at runtime via Kubernetes Secrets or Docker secrets. Option B is wrong because running the container as root unnecessarily elevates privileges, increasing the risk of container breakout and host compromise; containers should run with the least privileges needed. Option D is wrong because copying the entire host filesystem into the image (e.g., COPY / /app) creates a massive, insecure image that exposes all host files and directories, violating supply chain security and image minimization principles.

Full explanation →

213

Multi-Selectmedium

Which TWO of the following are recommended actions to harden service account security in a Kubernetes cluster? (Select TWO)

Select 2 answers

A.Delete all service accounts except the default one

B.Use a single service account for all workloads

C.Avoid granting cluster-admin ClusterRole to service accounts

D.Grant cluster-admin to all service accounts for simplicity

E.Disable automountServiceAccountToken for pods that do not require API access

AnswersC, E

Cluster-admin is a highly privileged, cluster-wide role that grants unrestricted control over all resources, including nodes, secrets, and namespaces. Granting it to a service account means any pod using that account can effectively destroy or exfiltrate the entire cluster. Instead, service accounts should be bound only to the minimal RBAC roles required for their specific API interactions; cluster-admin should be reserved exclusively for rare, break-glass human operations with strong auditing controls.

Why this answer

Granting the cluster-admin ClusterRole to a service account provides unrestricted superuser access across the entire cluster, violating the principle of least privilege. The CKS exam emphasizes that service accounts should be bound only to the minimal RBAC permissions required for their function, and cluster-admin should never be used for routine workloads.

Exam trap

CNCF often tests the misconception that deleting all non-default service accounts or using a single shared service account simplifies management, when in fact these actions break security boundaries and are explicitly discouraged in Kubernetes hardening guides.

Full explanation →

214

MCQmedium

You want to ensure that a pod only runs on nodes that have a specific label, 'disktype=ssd'. Which field should be specified in the pod spec?

A.affinity.nodeAffinity

B.nodeName

C.nodeSelector

D.tolerations

AnswerC

nodeSelector is a straightforward pod spec field that restricts the pod to nodes carrying all the specified label key-value pairs. The scheduler treats this as a hard constraint: if no node has the required labels, the pod remains Pending and is never scheduled onto a mismatched node. This exactly satisfies the need to ensure the pod runs only on nodes with a given label, as it enforces the label match at scheduling time without requiring additional configuration.

Why this answer

C is correct because `nodeSelector` is the simplest and most direct field in a Pod spec for constraining which nodes the Pod can be scheduled on based on node labels. By setting `nodeSelector` with `disktype: ssd`, the scheduler will only place the Pod on nodes that have that exact label key-value pair, making it the ideal choice for this straightforward label-based scheduling requirement.

Exam trap

CNCF often tests the distinction between `nodeSelector` (simple label match) and `nodeAffinity` (advanced label matching with operators), leading candidates to overcomplicate and choose `nodeAffinity` when `nodeSelector` is the correct, minimal answer.

How to eliminate wrong answers

Option A is wrong because `affinity.nodeAffinity` provides more complex and flexible scheduling rules (e.g., required vs. preferred constraints, matchExpressions with operators like In/NotIn), but it is not the simplest field for a basic label match; the question asks for a field to ensure the pod only runs on nodes with a specific label, and `nodeSelector` is the correct minimal field. Option B is wrong because `nodeName` directly assigns the Pod to a specific node by name, bypassing the scheduler entirely and ignoring labels; it does not use the `disktype=ssd` label and would fail if the named node does not have that label. Option D is wrong because `tolerations` allow a Pod to be scheduled on nodes with matching taints, but they do not actively select nodes based on labels; tolerations only permit scheduling on tainted nodes, they do not enforce that a node must have a specific label.

Full explanation →

215

MCQmedium

A security analyst needs to detect and record attempts to modify Kubernetes audit-relevant resources. The cluster already forwards audit logs to a SIEM. Which configuration ensures the API server records both the request and the response for changes to Secrets, while keeping other requests at a lighter level?

A.Set --audit-policy-file to a policy that places a rule with level: RequestResponse and resources: [{group: "", resources: ["secrets"]}] above a catch-all rule with level: Metadata.

B.Set --audit-policy-file to a policy with a rule at level: Request for secrets and a catch-all at level: RequestResponse.

C.Set --audit-policy-file to a policy with a single rule at level: RequestResponse and no resource restriction.

D.Set --audit-policy-file to a policy with a rule at level: Metadata for secrets and a catch-all at level: None.

AnswerA

Audit rules are evaluated in order and the first matching rule wins, so a specific rule for secrets at RequestResponse captures both request and response bodies for Secret changes. The later catch-all at Metadata keeps the rest of the traffic lightweight. This ordering and level pairing is exactly what the requirement describes.

Why this answer

Audit policy rules are matched in order, and the first match determines the level. A resource-specific rule at RequestResponse placed above a broad Metadata rule records full request and response bodies for Secret changes while keeping other traffic light. Reversing the order or using a broad RequestResponse rule would either miss the bodies or flood the audit backend.

Exam trap

The trap here is forgetting that audit rules are first-match-wins, so a broad rule placed above a specific rule silently overrides the intended per-resource level.

Full explanation →

216

MCQmedium

A cluster uses a custom mutating admission webhook that adds a sidecar container to all pods. After an upgrade, the webhook crashes and pods cannot be created. What is the best way to prevent this scenario in future?

A.Run multiple replicas of the webhook

B.Set the webhook's failurePolicy to Ignore

C.Disable admission webhooks in the cluster

D.Create a validating webhook as a backup

AnswerB

Setting failurePolicy: Ignore tells the API server to bypass the webhook if it cannot be reached or returns an error, allowing pod creation to proceed without the mutation. This guarantees availability but at the cost of correctness, as the pod may miss required mutations. It is a standard mitigator for webhook outages, but should be used only when the mutation is non-critical or the mutation can be enforced elsewhere.

Why this answer

Setting the webhook's failurePolicy to Ignore ensures that if the webhook fails (e.g., crashes or times out), the API server will bypass the webhook and allow the pod creation to proceed. This prevents a single point of failure from blocking all pod creation, which is critical for cluster availability. The default failurePolicy is Fail, which would cause the entire admission request to fail if the webhook is unreachable.

Exam trap

The trap here is that candidates often think high availability (multiple replicas) is sufficient, but the CKS exam tests the understanding that failurePolicy is the direct mechanism to prevent a single webhook failure from blocking all pod creation, regardless of replica count.

How to eliminate wrong answers

Option A is wrong because running multiple replicas of the webhook improves availability but does not prevent the scenario where all replicas crash or the webhook service becomes unreachable; the failurePolicy must be set to Ignore to handle such cases. Option C is wrong because disabling admission webhooks entirely removes the sidecar injection capability and is an overreaction that breaks the intended functionality, not a best practice for resilience. Option D is wrong because a validating webhook cannot serve as a backup for a mutating webhook; it operates on a different phase and cannot perform mutations, and it would also suffer from the same failurePolicy issue if not configured correctly.

Full explanation →

217

MCQhard

You are using Open Policy Agent (OPA) Gatekeeper to enforce pod security. You want to create a constraint that denies pods unless they have readOnlyRootFilesystem set to true. Which Rego rule in a ConstraintTemplate correctly implements this?

A.violation[{"msg": msg}] { container := input.review.object.spec.containers[_] container.securityContext.readOnlyRootFilesystem == true msg := "readOnlyRootFilesystem must be true" }

B.violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not container.securityContext.readOnlyRootFilesystem msg := "readOnlyRootFilesystem must be true" }

C.violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not container.securityContext.readOnlyRootFilesystem == false msg := "readOnlyRootFilesystem must be true" }

D.violation[{"msg": msg}] { container := input.review.object.spec.containers[_] container.securityContext.readOnlyRootFilesystem == false msg := "readOnlyRootFilesystem must be true" }

AnswerB

This is the correct implementation because `not container.securityContext.readOnlyRootFilesystem` succeeds when the field is either absent (undefined) or explicitly `false`, exactly the non-compliant cases. In Rego, `not` on an undefined reference returns true, so a pod that omits `securityContext` or sets the key to `false` is caught. Conversely, a container with `readOnlyRootFilesystem: true` makes the inner expression true, so `not` fails and no violation is generated.

Why this answer

It uses `not container.securityContext.readOnlyRootFilesystem` to trigger a violation when the field is missing, false, or nil. In Rego, `not` succeeds when the expression inside it fails, so this rule denies any pod where any container does not have `readOnlyRootFilesystem` explicitly set to `true`. This matches the requirement to deny pods unless the field is `true`.

Exam trap

CNCF often tests the nuance that `not` in Rego catches both `false` and undefined values, whereas an explicit `== false` check misses undefined fields — a common pitfall for candidates who think only explicit `false` values should be denied.

How to eliminate wrong answers

Option A is wrong because it creates a violation when `readOnlyRootFilesystem == true`, which would deny pods that are actually compliant — the opposite of the requirement. Option C is wrong because `not container.securityContext.readOnlyRootFilesystem == false` is a double negative that evaluates to true when the field is `true` or missing, but it fails to catch cases where the field is explicitly `false` (since `false == false` is true, `not` makes it false, so no violation). Option D is wrong because it only denies pods where `readOnlyRootFilesystem == false`, but it misses pods where the field is missing entirely (nil), which should also be denied.

Full explanation →

218

Multi-Selecthard

Which TWO of the following are true about AppArmor profiles in Kubernetes?

Select 2 answers

A.AppArmor profiles can be loaded in 'enforce' or 'complain' mode

B.The profile name in the annotation should be just the profile name without the 'localhost/' prefix

C.If the profile is not loaded on the node, the pod will be rejected

D.The annotation key for a container is 'container.apparmor.security.beta.kubernetes.io/<profile_name>'

E.AppArmor profiles are automatically loaded from a ConfigMap

AnswersA, C

AppArmor profiles support two execution modes: enforce and complain. In enforce mode, any operation that violates the profile is blocked and the process is denied permission, while in complain mode the same violation is logged to the system log but allowed to proceed. The mode is set inside the profile file (e.g., 'flags=(enforce)') or specified during loading via apparmor_parser, and Kubernetes does not alter it once the profile is loaded on the node.

Why this answer

AppArmor profiles operate in two modes: 'enforce' (where violations are blocked and logged) and 'complain' (where violations are only logged without blocking). This is a fundamental characteristic of AppArmor, and Kubernetes supports both modes when referencing profiles via annotations.

Exam trap

The trap here is that candidates often confuse the annotation key format (thinking it uses the profile name instead of the container name) or forget that the 'localhost/' prefix is mandatory when referencing a node-local profile.

Full explanation →

219

Multi-Selectmedium

Which TWO admission plugins are recommended by the CIS benchmark to be enabled on the kube-apiserver? (Choose two.)

Select 2 answers

A.AlwaysDeny

B.NodeRestriction

C.ServiceAccount

D.AlwaysAdmit

E.PodSecurityPolicy

AnswersB, C

This admission plugin restricts the Node authorization mode, limiting kubelet API access to only the node's own identity and specific node-related resources. It ensures that a compromised kubelet cannot modify other nodes or perform broad API actions. CIS specifically recommends enabling NodeRestriction to enforce the principle of least privilege for kubelet credentials, reducing the blast radius of node compromise.

Why this answer

The CIS Benchmark for Kubernetes recommends enabling the NodeRestriction and ServiceAccount admission plugins on the kube-apiserver. NodeRestriction limits the Node identity's ability to modify Node and Pod objects, enforcing the principle of least privilege for kubelets. ServiceAccount ensures that every Pod is assigned a default ServiceAccount and that the token is automatically mounted, which is essential for secure pod-to-API-server communication.

Exam trap

CNCF often tests the misconception that deprecated or removed plugins like PodSecurityPolicy are still recommended, or that blanket deny/admit plugins are viable hardening measures, when in fact the CIS Benchmark focuses on least-privilege and default-secure plugins like NodeRestriction and ServiceAccount.

Full explanation →

220

MCQhard

A security engineer wants to enforce that all images in the cluster must come from a trusted registry 'trusted-registry.io'. They are using OPA/Gatekeeper. Which constraint template and constraint combination would achieve this?

A.A constraint template that checks 'spec.containers[*].image' contains 'trusted-registry.io' and a constraint that denies if it does.

B.A constraint template that allows all images and a constraint that audits violations.

C.A constraint template that checks 'spec.containers[*].image' starts with 'trusted-registry.io/' and a constraint that denies if it does not.

D.A constraint template that checks 'spec.containers[*].image' equals 'trusted-registry.io' and a constraint that denies if it does not.

AnswerC

Gatekeeper's `K8sAllowedRepos` template evaluates each container's `image` field against an allowed-prefix list, denying any pod whose image does not begin with `trusted-registry.io/`. This directly satisfies the stem's constraint that every image originate from the trusted registry, enforced at admission before workloads are created.

Why this answer

The constraint template must enforce that container images originate from the trusted registry by checking that the image string starts with 'trusted-registry.io/'. This ensures that only images from that specific registry are allowed, and the constraint denies any pod that does not meet this condition. OPA/Gatekeeper uses Rego policies to evaluate the image field and reject non-compliant resources during admission control.

Exam trap

The CKS exam often tests the difference between 'contains' and 'startswith' in Rego policies, where candidates mistakenly choose 'contains' thinking it is sufficient, but it fails to prevent images from untrusted registries that include the trusted string in their path.

How to eliminate wrong answers

Option A is wrong because checking that the image 'contains' the registry string is too permissive; an image like 'malicious-registry.io/trusted-registry.io' would incorrectly pass. Option B is wrong because allowing all images with only audit violations does not enforce denial; Gatekeeper must actively deny non-compliant resources to enforce the policy. Option D is wrong because checking that the image 'equals' the registry string is too restrictive; it would require the entire image reference to be exactly 'trusted-registry.io', which is not a valid image path and would reject all legitimate images from that registry.

Full explanation →

221

MCQeasy

A developer wants to sign a container image using Cosign. Which command should they run after building and pushing the image to a registry?

A.cosign sign myrepo/myapp:latest

B.cosign verify myrepo/myapp:latest

C.cosign attest myrepo/myapp:latest

D.cosign generate-key-pair

AnswerA

Cosign stores signatures as OCI artefacts in the same registry as the image, so signing requires only the image reference. Running cosign sign against myrepo/myapp:latest generates a keyless or key-based signature attached to that digest, satisfying the post-push signing requirement.

Why this answer

The `cosign sign` command is used to sign a container image and attach the signature to the image in the registry. After building and pushing the image, running `cosign sign myrepo/myapp:latest` generates a digital signature using a private key and stores it as an OCI artifact (e.g., `sha256-...sig`) in the same registry, enabling later verification of the image's integrity and origin.

Exam trap

The CKS exam often tests the distinction between signing (`cosign sign`) and verification (`cosign verify`), trapping candidates who confuse the action of creating a signature with the action of checking one.

How to eliminate wrong answers

Option B is wrong because `cosign verify` is used to validate an existing signature against a public key, not to create a signature. Option C is wrong because `cosign attest` attaches an in-toto attestation (a signed statement about the image's provenance or metadata) rather than a simple signature; it is not the primary command for signing. Option D is wrong because `cosign generate-key-pair` creates a new public/private key pair but does not sign any image; it is a prerequisite step, not the signing command itself.

Full explanation →

222

MCQeasy

Which of the following is a characteristic of Kata Containers compared to gVisor?

A.Kata Containers require no additional configuration in Kubernetes

B.Kata Containers have lower overhead than gVisor

C.Kata Containers use lightweight VMs to isolate containers

D.Kata Containers provide a user-space kernel that intercepts system calls

AnswerC

Kata Containers use lightweight virtual machines to isolate containers, providing a hardware-level security boundary. Each container or pod runs inside its own VM, using a guest kernel and hardware virtualization (e.g., via QEMU, Cloud Hypervisor, or Firecracker), while still offering container interfaces like OCI. This design delivers stronger isolation than standard runc or even gVisor, because a separate kernel and hardware virtualization protect against many host-validating side channels. This is precisely the defining characteristic of Kata Containers.

Why this answer

Kata Containers use lightweight virtual machines (VMs) to provide strong hardware-enforced isolation for containers. Each container runs inside its own minimal VM with a separate kernel, offering security comparable to a VM while maintaining container-like performance and orchestration. This is the defining characteristic that distinguishes Kata Containers from gVisor.

Exam trap

The trap here is that candidates confuse gVisor's user-space kernel approach (system call interception) with Kata Containers' hardware virtualization, leading them to select option D, which accurately describes gVisor but not Kata Containers.

How to eliminate wrong answers

Option A is wrong because Kata Containers require additional configuration in Kubernetes, such as installing the Kata runtime handler and configuring a RuntimeClass in the cluster. Option B is wrong because Kata Containers have higher overhead than gVisor due to the full VM and separate kernel per container, whereas gVisor intercepts system calls in user space with lower resource consumption. Option D is wrong because it describes gVisor's architecture (a user-space kernel that intercepts system calls), not Kata Containers, which use hardware virtualization.

Full explanation →

223

MCQeasy

What is the recommended way to provide TLS certificates to the API server?

A.Use --tls-cert-file and --tls-private-key-file flags

B.Store certificates in a ConfigMap and mount them

C.Place certificates in /etc/kubernetes/pki/ without additional flags

D.Use --client-ca-file only

AnswerA

The --tls-cert-file and --tls-private-key-file flags are the canonical way to configure the kube-apiserver's HTTPS serving identity. When these flags are set, the API server presents the provided PEM-encoded certificate and uses the matching private key for all secure HTTPS connections from clients like kubectl. This is the only approach that directly wires a custom certificate/key pair into the API server's secure serving layer, and it is the same mechanism kubeadm uses to inject the generated apiserver certificate.

Why this answer

The recommended way to provide TLS certificates to the API server is by using the `--tls-cert-file` and `--tls-private-key-file` flags. These flags explicitly point the kube-apiserver to the certificate and key files, ensuring the server presents a valid TLS certificate for encrypted HTTPS communication. This is the standard, documented method for configuring TLS on the API server, as it allows the server to authenticate itself to clients.

Exam trap

The trap here is that candidates often confuse the purpose of `--client-ca-file` (for client authentication) with the server TLS flags, or assume that placing certificates in `/etc/kubernetes/pki/` is sufficient without setting the corresponding flags, because kubeadm automates this but the exam tests manual configuration knowledge.

How to eliminate wrong answers

Option B is wrong because ConfigMaps are designed for storing non-sensitive configuration data, not TLS private keys, which must be kept confidential; mounting a ConfigMap would expose the private key in plaintext, violating security best practices. Option C is wrong because while `/etc/kubernetes/pki/` is the default directory for certificates on a kubeadm cluster, the API server does not automatically load certificates from this path without the corresponding `--tls-cert-file` and `--tls-private-key-file` flags being set. Option D is wrong because `--client-ca-file` is used to specify the CA certificate for verifying client certificates (mutual TLS), not for providing the server's own TLS certificate and key.

Full explanation →

224

MCQmedium

You run 'kube-bench' and see a failure: '1.2.7 Ensure that the --kubelet-client-certificate and --kubelet-client-key arguments are set as appropriate'. What is the impact of this misconfiguration?

A.The apiserver will use the kubelet's own certificate

B.The kubelet will refuse to register with the cluster

C.The apiserver will use anonymous authentication when connecting to kubelets

D.The apiserver will reject all requests to kubelets

AnswerC

When the apiserver is not configured with a client certificate and key, it makes the HTTPS request to the kubelet without presenting any client certificate. The kubelet treats this as an unauthenticated connection; if --anonymous-auth is true (the default), it maps the caller to the user system:anonymous and may serve the request if anonymous access is permitted by its authorization policy. This is exactly the risk the CIS check addresses: a kubelet could authorize anonymous requests for pod logs or exec, so the apiserver must have a dedicated, trusted client certificate.

Why this answer

When the API server lacks a properly configured client certificate and key for kubelet communication, it falls back to anonymous authentication when making requests to kubelets. This means the kubelet cannot verify the API server's identity, allowing any unauthenticated request to be processed, which violates the principle of mutual TLS (mTLS) and weakens cluster security.

Exam trap

The trap here is that candidates often assume the API server will simply fail or reject requests when missing client certificates, but in reality, Kubernetes defaults to allowing anonymous authentication unless explicitly disabled, so the impact is a security bypass rather than a denial of service.

How to eliminate wrong answers

Option A is wrong because the API server does not use the kubelet's own certificate; it uses its own client certificate to authenticate to the kubelet, and the kubelet's certificate is used for the server side of the TLS handshake. Option B is wrong because kubelet registration with the cluster depends on the kubelet's bootstrap token or client certificate, not on the API server's kubelet client certificate; the kubelet will still register even if this flag is missing. Option D is wrong because the API server does not reject all requests; instead, it falls back to anonymous authentication, which may still allow requests to succeed but without proper authentication.

Full explanation →

225

MCQhard

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?

A.Add a PodSecurityPolicy that drops CAP_SYS_ADMIN

B.Modify the kubelet to disallow CAP_SYS_ADMIN

C.Implement a mutating admission webhook that automatically drops CAP_SYS_ADMIN from all pods

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

AnswerC

A mutating admission webhook intercepts every Pod creation or update request before the object is persisted, allowing it to patch the container's securityContext.capabilities.drop to include CAP_SYS_ADMIN (and often other dangerous capabilities as well). This is cluster-wide by default because webhooks apply to all namespaces unless you configure namespace selectors, and the mutation is recorded in the final Pod spec before any kubelet or container runtime sees it. Additionally, the webhook can log or annotate which pods were mutated, providing central auditability.

Why this answer

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.

Exam trap

The trap here is that candidates confuse Pod Security Standards (PSS) with automatic capability dropping, but the 'restricted' profile only enforces a deny-list on explicit capability requests, not a mutation to drop inherited capabilities.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (PSP) is deprecated since Kubernetes 1.21 and removed in 1.25, so it is not a viable cluster-wide enforcement mechanism for current clusters. Option B is wrong because the kubelet does not have a configuration to disallow specific Linux capabilities; capability enforcement is a pod-level security context concern, not a kubelet-level setting. Option D is wrong because the 'restricted' Pod Security Standard (PSS) profile does not automatically drop CAP_SYS_ADMIN; it only rejects pods that explicitly request it, but pods that do not explicitly set capabilities may still inherit it from the container runtime default.

Full explanation →

Certified Kubernetes Security Specialist CKS (CKS) — Questions 151–225