Certified Kubernetes Security Specialist CKS CKS Questions 526–600 | Page 8/12

526

MCQmedium

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

A.capabilities.allow

B.capabilities.add: ["ALL"]

C.capabilities.drop: ["ALL"]

D.dropCapabilities: true

AnswerC

Setting `capabilities.drop: ["ALL"]` instructs the container runtime to remove every Linux capability from the container's bounding and effective sets, including the default privileges such as CHOWN, DAC_OVERRIDE, and NET_BIND_SERVICE. This is the most hardened posture because the container processes retain only the bare minimum needed to run, and any syscall requiring a capability will fail with EPERM. It is the correct answer because it fully satisfies the requirement to drop all capabilities.

Why this answer

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

Exam trap

The trap in this question is that candidates may confuse `capabilities.drop` with `capabilities.add`, or expect a boolean field like `dropCapabilities`. However, Kubernetes requires an explicit list of capabilities to drop, and using `["ALL"]` is the correct way to drop all capabilities.

How to eliminate wrong answers

Option A is wrong because `capabilities.allow` is not a valid field in the Kubernetes `securityContext`; the correct field is `capabilities.add` to add capabilities. Option B is wrong because `capabilities.add: ["ALL"]` adds all Linux capabilities to the container, which is the opposite of dropping them and increases the attack surface. Option D is wrong because `dropCapabilities: true` is not a valid Kubernetes field; the correct syntax uses `capabilities.drop` with a list of capability names.

Full explanation →

527

MCQeasy

Which of the following is the correct flag to enable audit logging on the kube-apiserver?

A.--audit-file

B.--audit-log-path

C.--audit-policy-file

D.--audit-log-file

AnswerB

This is the correct flag to enable the file-based audit logging backend. When --audit-log-path is set to a file path, the apiserver begins writing JSON audit records there, and this is what actually activates audit logging. It is often paired with --audit-policy-file, but the policy only filters events; without --audit-log-path the apiserver writes no audit records at all.

Why this answer

`--audit-log-path` is the flag used to specify the file path where the kube-apiserver writes audit log entries. This flag is defined in the Kubernetes API server component and is required to enable audit logging; without it, no audit logs are written.

Exam trap

The trap here is that candidates confuse `--audit-policy-file` (which defines what to log) with the flag that actually enables logging, or misremember the exact flag name as `--audit-log-file` instead of the correct `--audit-log-path`.

How to eliminate wrong answers

Option A is wrong because `--audit-file` is not a valid kube-apiserver flag; the correct flag for specifying the audit log file path is `--audit-log-path`. Option C is wrong because `--audit-policy-file` specifies the path to the audit policy YAML file that defines which events to log, but it does not enable audit logging by itself—it must be used together with `--audit-log-path`. Option D is wrong because `--audit-log-file` is not a recognized flag; the correct flag name uses `--audit-log-path` as per the Kubernetes API server command-line options.

Full explanation →

528

MCQmedium

You run 'crictl ps' and see no output, but the node has running pods. What is the most likely cause?

A.The --runtime-endpoint flag is not set or points to the wrong socket

B.The container runtime is not Docker

C.The pod uses a different container runtime than CRI-O

D.The containers are in a different namespace

AnswerA

crictl relies on a CRI runtime endpoint to communicate with the container runtime. If --runtime-endpoint is omitted, crictl uses its built-in default, which usually points to a non-existent dockershim socket on modern CRI runtimes such as containerd or CRI-O. A wrong or missing endpoint means the gRPC connection silently fails, so crictl ps returns no output even though containers are running.

Why this answer

The `crictl ps` command queries the container runtime via the CRI (Container Runtime Interface) socket. If it returns no output while the node clearly has running pods (visible via `kubectl` or `kubelet`), the most likely cause is that the `--runtime-endpoint` flag is not set or points to the wrong socket. By default, `crictl` uses `/var/run/dockershim.sock` (deprecated) or may fall back to an incorrect path; if the actual runtime socket (e.g., `/run/containerd/containerd.sock` for containerd, or `/var/run/crio/crio.sock` for CRI-O) is not specified, the tool cannot connect to the runtime and returns an empty list.

Exam trap

The trap here is that candidates assume `crictl ps` shows all containers on the node, but it only shows containers managed by the CRI runtime at the specified endpoint — if the endpoint is misconfigured, it returns nothing even though pods are running.

How to eliminate wrong answers

Option B is wrong because the container runtime not being Docker is irrelevant — `crictl` works with any CRI-compliant runtime (containerd, CRI-O, etc.) and does not require Docker. Option C is wrong because `crictl` is designed to work with any CRI-compliant runtime; it does not care which specific runtime the pod uses as long as the endpoint is correct. Option D is wrong because containers are not namespaced in a way that hides them from `crictl`; `crictl` lists all containers managed by the runtime on that node, regardless of Kubernetes namespaces.

Full explanation →

529

MCQhard

A security policy requires that all container images must reference a specific SHA256 digest instead of a tag. You need to enforce this using Kyverno. Which Kyverno rule type and pattern would you use?

A.A generate rule that creates a ConfigMap with allowed digests

B.A mutate rule that replaces the image tag with a digest

C.A validate rule with a pattern that the image field matches '@sha256:'

D.A validate rule checking the annotation 'image.openshift.io/triggers'

AnswerC

A validate rule is the correct Kyverno mechanism because it asserts that the incoming resource matches a required pattern and rejects it otherwise. The pattern `spec.containers[*].image: "*@sha256:*"` enforces that every container image reference includes the immutable digest identifier, since a valid digest always appears as the `@sha256:` suffix. This directly implements the security policy at admission time, ensuring only images with explicit digests are deployed.

Why this answer

Kyverno's validate rules with a pattern can enforce that the image field in a Pod spec contains '@sha256:', ensuring only digest-based references are used. This directly meets the security policy requirement without altering the image reference or relying on external data.

Exam trap

The CKS exam often tests the distinction between validation and mutation rules, where candidates mistakenly choose a mutate rule to 'fix' the image reference instead of a validate rule to enforce the policy as written.

How to eliminate wrong answers

Option A is wrong because a generate rule creates resources like ConfigMaps but does not enforce image digest usage at admission time; it only provides data that must be referenced elsewhere. Option B is wrong because a mutate rule would automatically replace tags with digests, which violates the policy's intent to require explicit digest references from the user, not automatic remediation. Option D is wrong because the annotation 'image.openshift.io/triggers' is OpenShift-specific for triggering image updates, not a Kyverno mechanism for validating image references.

Full explanation →

530

Multi-Selecthard

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

Select 2 answers

A.Enable the NodeRestriction admission controller

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

C.Enable audit logging to detect unauthorized attempts

D.Disable all authentication mechanisms and rely on network policies

E.Configure the API server to use TLS certificates for client authentication

AnswersA, E

The NodeRestriction admission controller enforces that a kubelet may only modify the Node object it is assigned to, and cannot alter sensitive labels such as kubernetes.io/role or any label with a node.kubernetes.io/ prefix, nor request the node.k8s.io/v1 Node API for other nodes. This directly reduces the attack surface of a compromised worker node by preventing label-based privilege escalation or denial-of-service via node object corruption, working in tandem with Node authorization to enforce the principle of least privilege for node identity.

Why this answer

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

Exam trap

CNCF often tests the distinction between preventive controls (like admission controllers and authentication) and detective controls (like audit logging), so candidates mistakenly select audit logging as a hardening measure when it only detects, not prevents, unauthorized access.

Full explanation →

531

MCQeasy

Which crictl command lists all running containers on a node?

A.crictl pods

B.crictl images

C.crictl ps

D.crictl stats

AnswerC

crictl ps is the correct command because it queries the CRI runtime for all containers and, by default, filters to those in the running state. It displays each container's unique ID, the associated pod, name, and status, directly satisfying the question's request. This is the standard CRI-O/containerd equivalent of docker ps for inspecting active containers on a node.

Why this answer

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

Exam trap

The trap is confusing the CRI object hierarchy: candidates may pick crictl pods thinking it lists containers, but pods lists pod sandboxes while ps lists the containers themselves.

How to eliminate wrong answers

Option A is wrong because crictl pods lists pod sandboxes (the pod-level CRI objects), not the individual containers running within them. Option B is wrong because crictl images lists container images available on the node, not running containers. Option D is wrong because crictl stats displays resource usage statistics (CPU, memory) for running containers, not a listing of them.

Full explanation →

532

MCQmedium

An administrator runs 'trivy image --severity HIGH,CRITICAL myapp:v1.0' and sees no vulnerabilities. However, a security scan of the same image using a different tool reports several HIGH severity CVEs. What is the MOST likely reason for this discrepancy?

A.Trivy only scans the application layer and ignores the base image

B.The image was scanned with an outdated vulnerability database

C.Trivy cannot scan images stored in private registries

D.The other tool has false positives

AnswerB

Trivy's detection depends on its local vulnerability database. If that database is stale, newly published CVEs affecting the image's packages are absent from results, while a tool with a current feed flags them. Updating the database resolves the discrepancy.

Why this answer

Trivy relies on a local vulnerability database (e.g., the `trivy-db` or `trivy-java-db`) that must be regularly updated to include the latest CVE entries. If the database is outdated, Trivy will not detect recently published HIGH or CRITICAL vulnerabilities, even if they exist in the image. This is the most likely reason for the discrepancy, as a different tool may have a more current database.

Exam trap

Candidates may mistakenly think Trivy ignores base images or cannot handle private registries, when the real issue is an outdated CVE database. This discrepancy highlights that vulnerability scanners are only as good as their database freshness.

How to eliminate wrong answers

Option A is wrong because Trivy scans both the application layer and the base image layers (e.g., OS packages in Alpine, Ubuntu, etc.) by default; it does not ignore the base image. Option C is wrong because Trivy can scan images stored in private registries by using authentication (e.g., `--registry-auth` or environment variables like `TRIVY_USERNAME`/`TRIVY_PASSWORD`). Option D is wrong because while false positives are possible, the question states the other tool reports several HIGH severity CVEs, and the most likely explanation is an outdated database in Trivy, not systematic false positives in the other tool.

Full explanation →

533

Multi-Selectmedium

Which TWO admission plugins are recommended to be enabled for security hardening?

Select 2 answers

A.AlwaysPullImages

B.NodeRestriction

C.NamespaceLifecycle

D.PodSecurity

E.DefaultStorageClass

AnswersB, D

NodeRestriction is a core recommended admission plugin that limits what a kubelet may modify by ensuring a node can only alter its own Node object, its owned labels, and status fields, while preventing it from writing to other nodes or using arbitrary identities. It works tightly with the Node authorizer and prevents a compromised kubelet from escalating privileges by tainting or labeling other nodes or by requesting scoped certificates for a different node name, making it essential for node-level least privilege.

Why this answer

NodeRestriction is correct because it limits the Node object modifications a kubelet can make, preventing compromised nodes from modifying other nodes or escalating privileges. PodSecurity is correct because it enforces Pod Security Standards (baseline, restricted) via admission, replacing the deprecated PodSecurityPolicy with a built-in, stable mechanism for controlling pod security contexts.

Exam trap

CNCF often tests the distinction between plugins that are 'enabled by default' (like NamespaceLifecycle) versus those that are specifically 'recommended for security hardening' (like NodeRestriction and PodSecurity), causing candidates to pick default plugins that are not security-focused.

Full explanation →

534

MCQmedium

Which kubectl command(s) can you use to view the logs of a specific container in a multi-container pod? (Select all that apply)

A.kubectl logs <pod> -c <container>

B.kubectl logs <pod> --container <container>

C.kubectl logs <pod> <container>

D.kubectl logs <pod> --all-containers

AnswerA, B

The `-c` flag is the shorthand for `--container` and tells kubectl which container's logs to read from the pod. This is essential when the pod runs multiple containers, because kubectl logs by default only returns logs from the first container or fails with an ambiguity error. Both `-c` and `--container` are valid, so this command correctly targets a specific container.

Why this answer

The `kubectl logs` command supports both `-c` and `--container` flags to specify a container name in a multi-container pod. Both are equivalent and valid. The other options are either incorrect syntax or would display logs from all containers, which does not target a specific container.

Exam trap

CKS often tests kubectl command syntax; candidates might think positional arguments work for container names, but only flags are valid.

How to eliminate wrong answers

Option C is wrong because `kubectl logs <pod> <container>` is not valid syntax; the container must be specified with a flag. Option D is wrong because `--all-containers` displays logs from all containers in the pod, not a specific one, so it does not meet the requirement.

Full explanation →

535

MCQeasy

Which flag enables the PodSecurity admission plugin in kube-apiserver?

A.--enable-admission-plugins=PodSecurity

B.--admission-control=PodSecurity

C.--feature-gates=PodSecurity=true

D.--pod-security-policy=true

AnswerA

The kube-apiserver's admission control chain is configured via the --enable-admission-plugins flag, which accepts a comma-separated list of plugin names. PodSecurity is a built-in admission plugin that, when included in this list, enforces the Kubernetes Pod Security Standards on pod create and update operations. This is the only correct way to enable the plugin in a modern control plane.

Why this answer

The PodSecurity admission plugin is enabled in kube-apiserver by passing the `--enable-admission-plugins=PodSecurity` flag. This flag activates the built-in Pod Security Admission (PSA) controller, which replaced the deprecated PodSecurityPolicy (PSP) in Kubernetes v1.25. The plugin enforces the Pod Security Standards (baseline, restricted, privileged) at the namespace level based on labels.

Exam trap

Candidates often confuse enabling a feature gate with enabling an admission plugin; the trap here is that candidates confuse `--feature-gates=PodSecurity=true` (which only makes the plugin available) with `--enable-admission-plugins=PodSecurity` (which actually activates it), or they mistakenly use the deprecated `--admission-control` flag.

How to eliminate wrong answers

Option B is wrong because `--admission-control` is a legacy flag from older Kubernetes versions (pre-1.10) and is no longer supported; the correct flag is `--enable-admission-plugins`. Option C is wrong because `--feature-gates=PodSecurity=true` only enables the PodSecurity feature gate (which is needed for the plugin to be available), but does not actually activate the admission plugin itself; the plugin must be explicitly added via `--enable-admission-plugins`. Option D is wrong because `--pod-security-policy=true` is not a valid kube-apiserver flag; the PodSecurityPolicy admission controller was enabled via `--enable-admission-plugins=PodSecurityPolicy` (now deprecated and removed in v1.25), and the flag shown does not exist.

Full explanation →

536

MCQhard

An admin runs 'kubectl run test-pod --image=nginx:latest' and the Pod is created but immediately enters 'CrashLoopBackOff'. 'kubectl describe pod test-pod' shows 'Back-off restarting failed container'. Which admission controller might cause this if misconfigured?

A.ValidatingAdmissionWebhook

B.MutatingAdmissionWebhook

C.PodSecurity

D.PersistentVolumeClaimResize

AnswerB

A MutatingAdmissionWebhook can modify the Pod spec before it is persisted, so even a simple nginx image could end up with an altered command, injected sidecar, or changed entrypoint. Once admitted, kubelet runs the mutated container, and if the mutation causes the main process to exit (e.g., a sidecar and no nginx, or an invalid argument), the resulting restart loop appears as CrashLoopBackOff. This explains why a mutation, not an outright rejection, matches the symptom.

Why this answer

A MutatingAdmissionWebhook can modify Pod specifications (e.g., injecting sidecar containers, changing image names, or adding init containers) before the Pod is persisted. If the webhook misconfigures the Pod—such as replacing the image with a non-existent one or adding a failing init container—the container may fail to start, causing a CrashLoopBackOff. The 'Back-off restarting failed container' message indicates the container itself is failing, which aligns with a mutation that breaks the Pod's runtime behavior.

Exam trap

The trap here is that candidates often assume a Pod entering CrashLoopBackOff must be due to a security policy (PodSecurity) or a validation rejection, but the 'Back-off restarting failed container' message indicates the container ran and failed, which points to a mutation that altered the container's runtime configuration, not a rejection or security constraint.

How to eliminate wrong answers

Option A is wrong because ValidatingAdmissionWebhooks only reject or allow requests based on validation logic; they do not modify the Pod spec, so they cannot cause a container to fail at runtime due to a misconfiguration injected into the Pod. Option C is wrong because PodSecurity (formerly PodSecurityPolicy) enforces security contexts (e.g., privileged, hostNetwork) and would either reject the Pod or allow it; it does not mutate the Pod spec to cause a container crash. Option D is wrong because PersistentVolumeClaimResize is an admission controller that handles PVC resize requests, not Pod creation or container execution, so it has no impact on a Pod entering CrashLoopBackOff.

Full explanation →

537

MCQmedium

A Falco rule is triggered when a shell is spawned inside a container. Which syscall is typically used to detect shell execution?

A.clone

B.open

C.read

D.execve

AnswerD

Falco detects shell execution by monitoring the execve syscall, which replaces the calling process image with a new program. When a shell binary such as /bin/sh is launched inside a container, execve fires, letting the rule match the spawned process and satisfy the stem's requirement to detect shell execution.

Why this answer

Falco detects shell execution by monitoring the `execve` syscall, which is the standard Linux system call used to execute a new program. When a shell like `/bin/bash` or `/sh` is spawned inside a container, the kernel invokes `execve` to replace the current process image with the shell binary. Falco's rule engine matches this syscall against its default rule set (e.g., `run_shell_untrusted`) to trigger an alert.

Exam trap

Candidates often mistakenly think that shell execution is detected via process creation syscalls like `clone` or `fork`. However, Falco specifically monitors the `execve` syscall because that is the system call that actually loads the shell binary into memory. In the CKS exam, understanding this distinction is crucial for writing Falco rules.

How to eliminate wrong answers

Option A is wrong because `clone` is used to create a new process or thread (like a container), not to execute a shell binary; spawning a shell typically uses `execve` after `fork`/`clone`. Option B is wrong because `open` is used to open a file descriptor, not to execute a program; a shell spawn would not be detected by monitoring file opens. Option C is wrong because `read` reads data from a file descriptor and has no role in program execution; it is unrelated to shell invocation.

Full explanation →

538

MCQmedium

A pod runs with a service account that has a ClusterRoleBinding granting cluster-admin. What is the best practice to reduce the risk of privilege escalation?

A.Use a PodSecurityPolicy to restrict the service account

B.Delete the service account and create a new one without any roles

C.Create a more restrictive Role/ClusterRole with only required permissions and bind it to the service account, removing the cluster-admin binding

D.Add a NetworkPolicy to block outbound traffic from the pod

AnswerC

Create a dedicated ClusterRole or Role that contains only the exact verbs and resources required for the pod to function (e.g., get, list, watch on specific resources), then bind it to the service account via a RoleBinding or ClusterRoleBinding scoped appropriately. Remove the existing ClusterRoleBinding to the cluster-admin role, which grants unrestricted access to all resources and APIs. Verify with `kubectl auth can-i --as=system:serviceaccount:<ns>:<sa> --list` to confirm only the necessary permissions remain.

Why this answer

The principle of least privilege dictates that a service account should only have the permissions necessary for its function. By creating a more restrictive Role/ClusterRole with only required permissions and binding it to the service account, you remove the excessive cluster-admin privileges, directly reducing the risk of privilege escalation. This aligns with Kubernetes RBAC best practices for hardening cluster setup.

Exam trap

CNCF often tests the distinction between RBAC (who can do what) and other security controls like PodSecurityPolicy or NetworkPolicy, expecting candidates to recognize that only RBAC changes can directly reduce service account permissions.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (PSP) is a deprecated admission controller that controls pod security contexts (e.g., privileged containers, host namespaces), not RBAC permissions; it cannot restrict what a service account can do via ClusterRoleBindings. Option B is wrong because deleting the service account and creating a new one without any roles would break the pod's functionality entirely, as it would have no permissions to perform any API operations, which is not a practical security fix. Option D is wrong because NetworkPolicy controls network traffic at the pod level (e.g., ingress/egress rules), not RBAC permissions; it cannot prevent a service account from abusing its cluster-admin privileges to escalate privileges via the Kubernetes API.

Full explanation →

539

MCQmedium

You run 'kubectl auth can-i --list --as=admin' and see that the admin user has full cluster-admin access. Which command would create a ClusterRoleBinding for a user named 'viewer' with read-only access to all resources?

A.kubectl create rolebinding viewer-binding --clusterrole=view --user=viewer

B.kubectl create clusterrole viewer --verb=get,list,watch --resource=*

C.kubectl create clusterrolebinding viewer-binding --role=view --user=viewer

D.kubectl create clusterrolebinding viewer-binding --clusterrole=view --user=viewer

AnswerD

This is the correct command because it creates a ClusterRoleBinding named 'viewer-binding' that binds the built-in 'view' ClusterRole to the user 'viewer' at the cluster scope. The 'view' ClusterRole provides read-only access to most resources across all namespaces, which directly satisfies the permission to list resources. The `--clusterrole` flag correctly references a ClusterRole, and the binding applies cluster-wide.

Why this answer

It uses `kubectl create clusterrolebinding` to bind the built-in `view` ClusterRole (which grants read-only access: get, list, watch) to the user `viewer` at the cluster scope. A ClusterRoleBinding is required to grant permissions across all namespaces, and the `--clusterrole` flag correctly references the ClusterRole, not a Role.

Exam trap

The trap here is that candidates confuse `rolebinding` with `clusterrolebinding` and `--role` with `--clusterrole`, leading them to pick options that either limit permissions to a single namespace or use incorrect syntax for binding a ClusterRole.

How to eliminate wrong answers

Option A is wrong because `kubectl create rolebinding` creates a namespaced RoleBinding, which only grants permissions within a specific namespace (default if not specified), not across all resources cluster-wide. Option B is wrong because it creates a new ClusterRole with `*` as the resource, which is invalid syntax (resources must be specific, e.g., `'*'` is not a valid resource name) and it does not bind the role to the user. Option C is wrong because it uses `--role=view` instead of `--clusterrole=view`; `--role` expects a namespaced Role, not a ClusterRole, and a ClusterRoleBinding cannot reference a namespaced Role.

Full explanation →

540

MCQeasy

Which flag on the kubelet disables anonymous access?

A.--anonymous-auth=false

B.--disable-anonymous

C.--no-anonymous

D.--enable-anonymous-auth=false

AnswerA

The kubelet controls anonymous access through the --anonymous-auth flag, which is a boolean parameter that defaults to true. Setting this flag to false is the exact, documented mechanism to require authentication for every request to the kubelet's HTTPS endpoint, including requests from the kube-apiserver. This matches the equivalent flag used on the Kubernetes API server, making it the correct and precise way to disable unauthenticated access.

Why this answer

The `--anonymous-auth` flag on the kubelet controls whether anonymous requests are allowed. Setting `--anonymous-auth=false` explicitly disables anonymous access, requiring all requests to present valid authentication credentials. This is a critical hardening measure to prevent unauthenticated users from interacting with the kubelet API.

Exam trap

CNCF often tests the exact flag name and syntax, so candidates may confuse `--anonymous-auth` with `--enable-anonymous-auth` or invent non-existent flags like `--disable-anonymous` or `--no-anonymous`.

How to eliminate wrong answers

Option B is wrong because `--disable-anonymous` is not a valid kubelet flag; the kubelet uses `--anonymous-auth` to control anonymous access. Option C is wrong because `--no-anonymous` is not a recognized flag; the kubelet does not support a `--no-` prefix for this setting. Option D is wrong because `--enable-anonymous-auth=false` is not a valid flag; the correct flag is `--anonymous-auth`, and setting it to `false` disables anonymous access, not `--enable-anonymous-auth`.

Full explanation →

541

MCQhard

A developer creates a Dockerfile with 'FROM ubuntu:latest'. The security team recommends using a minimal base image. Which change minimizes the attack surface?

A.FROM gcr.io/distroless/base:latest

B.FROM alpine:latest

C.FROM scratch

D.FROM ubuntu:20.04

AnswerA

Distroless images are purpose-built to contain only the libraries, system files, and configuration needed to run a specific runtime (such as glibc, CA certificates, and timezone data), with no shell, package manager, or debugging tools. This strips out utilities an attacker could leverage and keeps the filesystem small, while still supporting dynamically linked applications — unlike scratch, which requires you to provide every dependency yourself.

Why this answer

The `gcr.io/distroless/base:latest` image is a minimal, language-specific base image that contains only the essential runtime dependencies (e.g., glibc, libssl) and no package manager, shell, or utilities. This drastically reduces the attack surface by eliminating unnecessary binaries and tools that could be exploited. In contrast, `ubuntu:latest` includes a full userland with apt, bash, and other utilities, increasing the potential for privilege escalation or supply chain attacks.

Exam trap

The CKS exam often tests the misconception that `alpine:latest` is the most minimal secure base image, but distroless images are even more minimal because they strip out the shell and package manager entirely, which is the key differentiator for attack surface reduction.

How to eliminate wrong answers

Option B is wrong because `alpine:latest` uses musl libc and BusyBox, which still includes a shell and common Unix utilities, providing more surface area than a distroless image. Option C is wrong because `FROM scratch` is an empty image that lacks even the minimal runtime libraries (e.g., glibc) required by most compiled applications, making it impractical for anything other than static binaries. Option D is wrong because `ubuntu:20.04` is still a full Ubuntu distribution with a package manager, shell, and numerous pre-installed tools, offering no reduction in attack surface compared to `ubuntu:latest`.

Full explanation →

542

MCQmedium

An administrator wants to restrict a service account to only be able to create pods in the 'development' namespace. Which RBAC configuration should be used?

A.Create a Role in the default namespace and a RoleBinding that binds the service account to that Role.

B.Create a Role in the 'development' namespace and a RoleBinding that binds the service account to that Role.

C.Create a ClusterRole and a ClusterRoleBinding that binds the service account to that ClusterRole.

D.Create a ClusterRole and a RoleBinding in the 'development' namespace.

AnswerB

Roles and RoleBindings are namespaced resources, so creating both in the 'development' namespace limits the service account's permissions to only the resources in that namespace. This directly satisfies the requirement of restricting the service account to the intended namespace, and it follows the principle of least privilege by avoiding any cluster-wide or cross-namespace permissions.

Why this answer

A Role is namespace-scoped and can only grant permissions within the namespace where it is created. By creating a Role in the 'development' namespace and binding the service account to it via a RoleBinding, the service account is restricted to creating pods only in that namespace, as required.

Exam trap

CNCF often tests the distinction between Role and ClusterRole scoping, and the trap here is that candidates may incorrectly choose a ClusterRole with a RoleBinding (Option D) thinking it restricts to a namespace, but the ClusterRole itself may grant broader permissions or include cluster-scoped resources, violating the principle of least privilege.

How to eliminate wrong answers

Option A is wrong because creating a Role in the default namespace and binding it to the service account would grant permissions only in the default namespace, not in the 'development' namespace. Option C is wrong because a ClusterRole combined with a ClusterRoleBinding grants permissions cluster-wide, across all namespaces, which is too permissive and does not restrict the service account to the 'development' namespace. Option D is wrong because while a RoleBinding in the 'development' namespace scopes the binding to that namespace, a ClusterRole is not namespace-scoped; using a ClusterRole in a RoleBinding still grants permissions defined in the ClusterRole, which could include cluster-scoped resources or be overly broad, and the question specifically requires restricting to pod creation only, which a Role can handle more precisely.

Full explanation →

543

MCQeasy

You want to isolate a compromised pod by blocking all network traffic to and from it. Which NetworkPolicy would you apply?

A.A policy with podSelector matching the pod, and only ingress rules denying from all

B.A policy with podSelector matching the pod, and policyTypes: [Ingress, Egress] with no rules

C.A policy with podSelector matching the pod, and egress rules allowing to 0.0.0.0/0

D.A policy with podSelector: {} and no rules

AnswerB

This is the correct method: a NetworkPolicy that selects the compromised pod via its podSelector and explicitly lists policyTypes: [Ingress, Egress] with no rules. With this configuration, the pod is isolated because the policy enforces an implicit deny: any traffic that is not explicitly allowed is dropped, and since there are no allow rules, all ingress and egress traffic is blocked. This effectively quarantines the pod without affecting other pods.

Why this answer

To isolate a compromised pod by blocking all network traffic, you need a NetworkPolicy that selects the pod and denies both ingress and egress. A policy with podSelector matching the pod and policyTypes: [Ingress, Egress] with no rules will deny all ingress and egress traffic because an empty rule set means no traffic is allowed. This effectively isolates the pod.

Exam trap

CKS often tests the misconception that a policy with only ingress rules blocks all traffic, when in fact egress remains open unless explicitly denied, leading candidates to choose incomplete isolation.

How to eliminate wrong answers

Option A is wrong because it only denies ingress, leaving egress traffic allowed, which does not fully isolate the pod. Option C is wrong because it allows egress to all destinations (0.0.0.0/0), which is the opposite of isolation. Option D is wrong because a policy with podSelector: {} and no rules applies to all pods in the namespace and denies all traffic, but it does not specifically target the compromised pod and would disrupt other pods.

Full explanation →

544

MCQmedium

A developer created a ClusterRoleBinding that grants cluster-admin to a service account. What is the security concern?

A.Service accounts must use RoleBindings only

B.ClusterRoleBindings are deprecated

C.Service accounts cannot use ClusterRoleBindings

D.It gives the service account full cluster-wide permissions, which is excessive

AnswerD

It gives the service account full cluster-wide permissions, which is excessive is the correct answer because cluster-admin is a built-in ClusterRole that grants unrestricted superuser access to every resource and API group in the cluster. Binding a service account to it allows that account to read all secrets, modify all namespaces, delete nodes, and even change RBAC policies. This represents a severe least-privilege violation, as most workloads only need specific operations within a limited scope.

Why this answer

Granting a service account cluster-admin via a ClusterRoleBinding provides unrestricted, cluster-wide permissions, violating the principle of least privilege. This is a significant security risk as it allows the service account to perform any action on any resource in any namespace, including modifying RBAC rules, secrets, or node configurations. In Kubernetes, service accounts should be bound only to the minimal roles required for their function, typically using RoleBindings scoped to a specific namespace.

Exam trap

CNCF often tests the misconception that service accounts are restricted to namespace-scoped bindings, leading candidates to incorrectly choose Option A or C, when in fact Kubernetes allows any subject to be bound to any ClusterRole.

How to eliminate wrong answers

Option A is wrong because service accounts can use both RoleBindings (namespace-scoped) and ClusterRoleBindings (cluster-scoped) depending on the required scope; there is no Kubernetes restriction limiting them to RoleBindings only. Option B is wrong because ClusterRoleBindings are not deprecated; they remain a core, actively supported RBAC resource for granting cluster-wide permissions. Option C is wrong because service accounts can absolutely use ClusterRoleBindings; the Kubernetes API allows binding any subject (user, group, or service account) to a ClusterRole via a ClusterRoleBinding.

Full explanation →

545

MCQmedium

A cluster administrator wants to ensure that pods cannot modify node objects. Which admission plugin should be enabled?

A.PodSecurityPolicy

B.NodeAffinity

C.PodNodeSelector

D.NodeRestriction

AnswerD

NodeRestriction is an admission controller in the kube-apiserver that enforces the Node authorizer's limits on kubelet API access. It ensures a kubelet can only modify its own Node object, and even then only specific fields like status, labels, and annotations permitted by the authorizer. This plugin directly blocks kubelet-initiated requests that attempt to modify other nodes or the node's spec in unauthorized ways. Because it specifically targets node object modification, it is the correct mechanism described in the question.

Why this answer

The NodeRestriction admission plugin limits the kubelet's ability to modify node and pod objects to only those nodes it is authorized to manage. This prevents a compromised or misconfigured kubelet from modifying arbitrary node objects, enforcing the principle of least privilege. Option D is correct because it directly addresses the requirement to restrict node object modifications.

Exam trap

The trap here is that candidates often confuse admission plugins that affect pod scheduling (like NodeAffinity or PodNodeSelector) with those that enforce node-level security restrictions, leading them to overlook NodeRestriction as the correct answer.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) controls security-sensitive aspects of pod specs (e.g., privileged containers, host namespaces) but does not restrict modifications to node objects. Option B is wrong because NodeAffinity is a scheduling constraint that influences pod placement based on node labels, not an admission plugin that enforces node object modification restrictions. Option C is wrong because PodNodeSelector is an admission plugin that enforces namespace-level node selector constraints on pods, but it does not prevent pods or kubelets from modifying node objects.

Full explanation →

546

MCQmedium

A pod runs with an immutable root filesystem (readOnlyRootFilesystem: true). The application attempts to write to /tmp. What is the expected behavior?

A.The write fails with a permission error unless a writable volume is mounted at /tmp

B.The application can write to any directory because /tmp is always writable

C.The container crashes immediately

D.The write succeeds and is silently dropped

AnswerA

The write fails because `securityContext.readOnlyRootFilesystem: true` makes the container's root filesystem read-only at the kernel level, so every path on the root filesystem—including /tmp—is immutable. The `write()` syscall returns `EROFS` (read-only file system) or `EACCES` (permission denied) unless a writable volume such as an `emptyDir` is explicitly mounted at /tmp. The error is surfaced to the application, not hidden.

Why this answer

When a pod is configured with `readOnlyRootFilesystem: true`, the container's root filesystem is mounted as read-only. The `/tmp` directory is part of the root filesystem, so any write attempt to it will fail with a permission error (EPERM) unless a writable volume (e.g., `emptyDir`, `hostPath`, or `PersistentVolumeClaim`) is explicitly mounted at `/tmp`. This is enforced by the Linux kernel's mount flags and is a common security hardening practice to prevent unauthorized writes.

Exam trap

In the CKS exam, a common pitfall is assuming that /tmp is inherently writable or that the container will crash. The correct understanding is that the kernel enforces the read-only flag at the filesystem level, and writes fail with a permission error unless a writable volume is mounted at /tmp.

How to eliminate wrong answers

Option B is wrong because `/tmp` is not always writable; its writability depends on the filesystem mount flags, and with `readOnlyRootFilesystem: true`, the entire root filesystem, including `/tmp`, is read-only. Option C is wrong because the container does not crash; the write operation simply fails with an error, and the application may handle it gracefully or log the failure, but the container continues running. Option D is wrong because writes are not silently dropped; the kernel returns an explicit error (e.g., EROFS or EACCES) to the application, and the data is not written.

Full explanation →

547

MCQmedium

A pod manifests with securityContext: { runAsNonRoot: true, runAsUser: 1001 }. However, the container image expects to run as root (UID 0). What will happen when the pod is created?

A.The container runs as root because runAsUser overrides runAsNonRoot

B.The container fails to start because it cannot run as root

C.The container runs as user 1001

D.The pod runs, but the securityContext is ignored

AnswerC

This is the correct behavior. The securityContext.runAsUser field explicitly sets the UID for the container's main process, overriding any USER directive from the image. Because the value is 1001, which is a non-root UID, it concurrently satisfies the runAsNonRoot constraint. The kubelet applies both settings during container startup: runAsUser determines the actual UID, and runAsNonRoot verifies that the resolved UID is not 0, ensuring the container runs as user 1001.

Why this answer

When `runAsNonRoot: true` is set, Kubernetes enforces that the container cannot run as root (UID 0). However, the pod also specifies `runAsUser: 1001`, which tells Kubernetes to run the container as UID 1001. Since UID 1001 is non-root, the `runAsNonRoot` constraint is satisfied.

The container image's expectation to run as root is irrelevant because Kubernetes overrides the user with the specified `runAsUser`. Therefore, the container will start and run as user 1001.

Exam trap

The trap is that candidates think `runAsNonRoot` alone blocks execution if the image expects root, but they overlook that `runAsUser` can override the image's user to a non-root UID. In this case, the container runs successfully as user 1001, not fails.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot` takes precedence over `runAsUser` when there is a conflict; it does not allow root execution. Option C is wrong because the container image expects to run as root, and the `runAsNonRoot` flag prevents the container from starting at all, so it never runs as user 1001. Option D is wrong because the securityContext is not ignored; it is enforced, and the container fails to start due to the violation.

Full explanation →

548

MCQhard

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

A.SYS_ADMIN, SYS_MODULE, SYS_PTRACE

B.CHOWN, DAC_OVERRIDE, FOWNER

C.KILL, SETPCAP, SYS_CHROOT

D.NET_RAW, NET_ADMIN, NET_BIND_SERVICE

AnswerA

These capabilities permit privileged kernel operations: SYS_ADMIN enables mount and namespace manipulation, SYS_MODULE loads kernel modules, and SYS_PTRACE inspects other processes. Dropping them removes the primitives container escapes rely on, satisfying the stem's requirement to restrict host kernel access.

Why this answer

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

Exam trap

CNCF often tests the misconception that all capabilities are equally dangerous, but the trap here is that candidates may choose networking or file capabilities (options B, C, D) because they sound security-relevant, while the actual escape vector relies on the three kernel-focused capabilities in option A.

How to eliminate wrong answers

Option B is wrong because CHOWN, DAC_OVERRIDE, and FOWNER are file permission capabilities that control ownership and access control, not kernel-level escape vectors; they are less critical for preventing container escapes. Option C is wrong because KILL, SETPCAP, and SYS_CHROOT are not primary escape enablers: KILL sends signals, SETPCAP manages capability sets, and SYS_CHROOT is a legacy syscall that is already restricted by default in modern runtimes. Option D is wrong because NET_RAW, NET_ADMIN, and NET_BIND_SERVICE are networking capabilities that affect packet crafting and interface configuration, not direct kernel access or module loading.

Full explanation →

549

MCQeasy

Which of the following is a static analysis tool for Kubernetes manifests?

A.Kubesec

B.Cosign

C.Trivy

D.Syft

AnswerA

Kubesec is a static analysis tool that directly inspects Kubernetes resource manifests (YAML/JSON) without requiring a live cluster. It applies security best-practice rules—such as disallowing privileged containers, ensuring runAsNonRoot is set, and checking for dangerous capabilities—and produces a weighted risk score from 0 to 10. This validates exactly the kind of declarative security posture that the question asks about.

Why this answer

Kubesec is a static analysis tool specifically designed to evaluate Kubernetes manifests against a set of security best practices. It parses YAML or JSON resource definitions and scores them based on pod security contexts, container privilege escalation, and other runtime hardening rules, without executing the manifests.

Exam trap

CNCF often tests the distinction between static analysis (Kubesec) and runtime scanning or signing tools (Cosign, Trivy, Syft), leading candidates to confuse Trivy's IaC scanning capability with a dedicated Kubernetes manifest static analyzer.

How to eliminate wrong answers

Option B is wrong because Cosign is a tool for signing and verifying container images and blobs, not for static analysis of Kubernetes manifests. Option C is wrong because Trivy is primarily a vulnerability scanner for container images, filesystems, and Git repositories, though it can scan IaC files, it is not a dedicated static analysis tool for Kubernetes manifests in the same focused manner as Kubesec. Option D is wrong because Syft is a software bill of materials (SBOM) generator that produces a list of packages and dependencies from container images or filesystems, not a static analysis tool for Kubernetes manifests.

Full explanation →

550

MCQhard

You are configuring ImagePolicyWebhook admission controller to reject images not signed by a trusted authority. After deploying the webhook, you notice that pods are being rejected even for images that are properly signed. Which configuration change is MOST likely to fix this?

A.Increase the memory limit of the API server

B.Change the webhook from 'MutatingAdmissionWebhook' to 'ValidatingAdmissionWebhook'

C.Set failurePolicy to Ignore in the webhook configuration

D.Grant the webhook service account cluster-admin role

AnswerC

When the webhook cannot be reached, the API server rejects the request. Setting failurePolicy: Ignore allows pods to be admitted even if the webhook is unavailable, but this is a temporary fix. The root cause might be network connectivity to the webhook service.

Why this answer

The ImagePolicyWebhook admission controller uses a webhook to validate images. When the webhook is unreachable or returns an error, the default behavior is to reject the request. Setting `failurePolicy` to `Ignore` allows the API server to admit the pod when the webhook fails, which is necessary if the webhook is temporarily unavailable or misconfigured but images are properly signed.

Exam trap

The CKS exam often tests the distinction between `failurePolicy: Fail` (default) and `failurePolicy: Ignore`, tricking candidates into thinking the issue is with webhook type or permissions rather than the failure handling behavior.

How to eliminate wrong answers

Option A is wrong because increasing the API server's memory limit does not affect webhook communication or failure handling; it addresses resource constraints, not admission control logic. Option B is wrong because ImagePolicyWebhook is inherently a validating admission webhook, not a mutating one; changing the type does not resolve failures from webhook errors. Option D is wrong because granting cluster-admin to the webhook service account would not fix image rejection due to webhook failures; it would only escalate privileges unnecessarily and does not affect the admission controller's failure policy.

Full explanation →

551

MCQmedium

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

A.Use Seccomp profiles to block write syscalls outside /tmp

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

C.Deploy Falco with a rule: 'evt.type=open and evt.dir=< and fd.name startswith / and not fd.name startswith /tmp'

D.Configure AppArmor to deny writes outside /tmp

AnswerC

Falco is a runtime security agent that consumes kernel syscall events, and the rule uses evt.type=open with evt.dir=< (the enter event) to examine every open(2) call, along with fd.name checks to match absolute paths. By filtering fd.name startswith / and not startswith /tmp, it generates an alert only when a process opens a file outside /tmp, which covers writes and reads. This rule is efficient because it relies on Falco's in-kernel driver and has minimal overhead, unlike filesystem auditing or inotify.

Why this answer

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

Exam trap

CNCF often tests the distinction between runtime monitoring (Falco) and enforcement tools (Seccomp, AppArmor, OPA Gatekeeper), and the trap here is that candidates choose blocking tools (A or D) or admission control (B) instead of the tool that specifically logs and alerts at runtime with minimal performance impact.

How to eliminate wrong answers

Option A is wrong because Seccomp profiles block syscalls at the kernel level, which would prevent the microservice from writing anywhere (including legitimate writes), and blocking syscalls has higher performance overhead than monitoring; also, Seccomp cannot selectively allow writes only to /tmp based on file path. Option B is wrong because OPA Gatekeeper is an admission controller that rejects pods at deployment time, but it cannot monitor or alert on runtime file system writes after the pod is running. Option D is wrong because AppArmor denies writes at the kernel level, which would block the writes entirely rather than logging and alerting, and it imposes a performance penalty on every write attempt.

Full explanation →

552

MCQeasy

An admin runs 'crictl ps' on a node and sees multiple containers. Which command should they use to view the logs of a specific container?

A.crictl logs <container-id>

B.crictl exec <container-id> logs

C.crictl inspect <container-id>

D.crictl ps -a <container-id>

AnswerA

crictl logs <container-id> is the correct command because it directly retrieves the container's stdout/stderr log stream from the CRI-compatible runtime (containerd, CRI-O, etc.). The runtime stores these logs separately from the container's filesystem, and crictl logs queries that store, analogous to `docker logs`. You can further tailor it with flags like `--tail` or `--timestamps`, but the base command is what fetches the log output for a given container ID.

Why this answer

`crictl logs` is the dedicated command to retrieve container logs from the container runtime interface (CRI), fetching stdout and stderr output from the specified container, which is essential for debugging and monitoring containerized workloads on a Kubernetes node.

Exam trap

The trap here is that candidates may confuse `crictl` with other container command-line tools, assuming `crictl exec` or `crictl inspect` can retrieve logs, when in fact only `crictl logs` provides that functionality, and `crictl ps -a` merely lists containers without log content.

How to eliminate wrong answers

Option B is wrong because `crictl exec` is used to run a command inside a running container (e.g., `crictl exec -it <container-id> sh`), not to view logs; there is no `logs` subcommand for `exec`. Option C is wrong because `crictl inspect` returns detailed metadata and configuration of a container (e.g., mounts, environment variables, resource limits), not its log output. Option D is wrong because `crictl ps -a` lists all containers (including stopped ones) with their status and IDs, but does not display logs; appending a container ID to `ps` is syntactically invalid.

Full explanation →

553

Multi-Selecthard

Which THREE of the following are recommended measures to reduce the attack surface of Kubernetes nodes?

Select 3 answers

A.Disable unnecessary system services on nodes

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

C.Open all ports on nodes to allow easy debugging

D.Run all containers as root user

E.Apply Pod Security Standards to enforce least privilege

AnswersA, B, E

Disabling system services that aren't required for node operation is a fundamental host-hardening step. Every running service represents a potential vector for exploitation: it may open network listeners, expose APIs, or ship with unpatched vulnerabilities. On Kubernetes nodes, the principle is to minimize the attack surface to the essentials (kubelet, container runtime, system daemons like sshd only if required), often enforced via CIS benchmarks and immutable node images. Unused services such as CUPS, NFS, or telnet should be masked, as they increase the risk of host compromise and are never needed for pod workloads.

Why this answer

Disabling unnecessary system services on Kubernetes nodes reduces the number of running processes and open ports that could be exploited by an attacker. Services like telnet, rsh, or unused SNMP daemons provide additional attack vectors. This aligns with the principle of minimalism in system hardening, as recommended by the CIS Kubernetes Benchmark.

Exam trap

The CNCF CKS exam often tests the misconception that opening all ports aids debugging, but in Kubernetes, debugging should be done via kubectl exec or ephemeral containers, not by exposing node ports. Additionally, running containers as root is a common mistake that violates Pod Security Standards and the principle of least privilege.

Full explanation →

554

MCQmedium

A security review flags that developers can create pods that mount the host's /etc directory. You need to block hostPath volumes cluster-wide without breaking existing workloads that use the CSI driver for persistent storage. Which control is appropriate?

A.Apply a PodSecurity admission label of restricted to every namespace so hostPath volumes are rejected.

B.Add a NetworkPolicy with an empty podSelector in each namespace to prevent pods from reading host filesystem paths.

C.Create a ValidatingAdmissionPolicy that denies pods whose spec.volumes contain a hostPath entry.

D.Set --allow-privileged=false on the kubelet of every node so hostPath mounts are refused at runtime.

AnswerC

A ValidatingAdmissionPolicy with a CEL expression can inspect pod volumes and reject any object containing a hostPath entry, while leaving CSI-backed volumes untouched because those use a csi volume source instead. This gives a cluster-wide, declarative deny rule that does not require a policy controller and aligns with the modern replacement for PodSecurityPolicy-style restrictions.

Why this answer

Blocking hostPath volumes requires admission-time inspection of the pod spec. ValidatingAdmissionPolicy lets you express a CEL rule that rejects any pod declaring a hostPath volume, which precisely targets the risk without imposing unrelated restrictions. CSI volumes use a different volume source, so legitimate persistent storage continues to work.

PodSecurity restricted, kubelet allow-privileged, and NetworkPolicy all act on different concerns and either over-restrict or miss the mount entirely.

Exam trap

The trap here is reaching for the restricted Pod Security Standard, which does block hostPath but also imposes many other requirements that would break the CSI workloads the scenario says must keep running.

Full explanation →

555

Multi-Selecteasy

Which TWO of the following are valid modes for an AppArmor profile?

Select 2 answers

A.unconfined

B.complain

C.enforce

D.permissive

E.audit

AnswersB, C

Complain mode is one of the two official AppArmor modes. When a profile is loaded in complain mode, AppArmor logs every operation that would be denied under enforce mode, but it does not actually block any of those operations. This mode is primarily used for testing and fine-tuning profiles before switching them to enforce mode, making it a legitimate and valid mode.

Why this answer

AppArmor profiles operate in two primary modes: 'complain' (also known as 'learning' mode) and 'enforce' (also known as 'confined' mode). In complain mode, policy violations are logged but not blocked, allowing administrators to test and refine profiles. In enforce mode, violations are both logged and blocked, actively restricting the application's behavior according to the profile.

Exam trap

CNCF often tests the distinction between AppArmor and SELinux terminology, where candidates mistakenly apply SELinux concepts (like 'permissive' or 'enforcing') to AppArmor, which uses 'complain' and 'enforce' as its only two valid modes.

Full explanation →

556

MCQeasy

A security engineer needs to ensure that all communication between nodes and the control plane is encrypted. Which component must be configured with a TLS certificate to achieve this?

A.kube-proxy

B.etcd

C.kube-scheduler

D.kube-apiserver

AnswerD

The kube-apiserver is the single frontend of the control plane and serves the Kubernetes API over HTTPS on port 6443, which is the endpoint that every node's kubelet and kube-proxy contacts to manage workloads and report status. By configuring its TLS serving certificate via --tls-cert-file and --tls-private-key-file, and enforcing appropriate TLS versions, all communication between nodes and the control plane is encrypted in transit. Securing this endpoint is therefore the direct and necessary control to satisfy the requirement.

Why this answer

The kube-apiserver is the central gateway for all cluster operations, and it must be configured with a TLS certificate to encrypt communication between nodes (kubelets) and the control plane. The kube-apiserver presents this certificate to authenticate itself and establish encrypted HTTPS connections, ensuring that all traffic from node components (e.g., kubelets, kube-proxy) and other control plane components is secured in transit.

Exam trap

CNCF often tests the misconception that etcd is the primary component for encryption because it stores sensitive data, but the question specifically asks about encrypting communication between nodes and the control plane, which is handled by the kube-apiserver's TLS certificate, not etcd's internal encryption.

How to eliminate wrong answers

Option A is wrong because kube-proxy is a network proxy that runs on each node and handles service routing, but it does not terminate TLS for node-to-control-plane communication; it relies on the kube-apiserver's TLS for secure connections. Option B is wrong because etcd stores cluster data and can be configured with its own TLS certificates for peer and client communication, but it is not the component that encrypts node-to-control-plane traffic; it is a data store accessed by the kube-apiserver. Option C is wrong because kube-scheduler is a control plane component that assigns pods to nodes, but it communicates with the kube-apiserver via TLS (using the apiserver's certificate) and does not itself present a certificate for node-to-control-plane encryption.

Full explanation →

557

Multi-Selecteasy

You are asked to secure a set of microservices running in a Kubernetes cluster. Which TWO of the following practices help minimize vulnerabilities in microservices?

Select 2 answers

A.Manually inject sidecar proxies into every pod to enforce mTLS.

B.Run containers in privileged mode to allow them to perform necessary system calls.

C.Ensure containers run with a non-root user.

D.Use a read-only root filesystem for containers.

E.Store secrets directly in container images for easy access.

AnswersC, D

By default, containers in Kubernetes may run as the root user if the image does not declare a non-root USER, and root inside a container shares the kernel and may still access host resources depending on capabilities. Setting runAsNonRoot: true and specifying an unprivileged runAsUser (or using a non-root image USER) makes the container runtime refuse to start the process as UID 0, denying an attacker a wide range of kernel-based privilege escalation and file-permission attacks once the application is compromised. Non-root execution is a fundamental least-privilege control and must be combined with dropped capabilities and a read-only filesystem to meaningfully reduce the blast radius.

Why this answer

Running containers with a non-root user (via the `securityContext.runAsNonRoot: true` field or a specific `runAsUser` directive) prevents privilege escalation and limits the blast radius of a container compromise. This aligns with the principle of least privilege, a core mitigation against container breakout attacks in Kubernetes.

Exam trap

CNCF often tests the misconception that sidecar proxies must be manually injected to enforce mTLS, but the correct approach is to use automated injection via admission controllers to avoid misconfiguration and ensure consistent policy enforcement.

Full explanation →

558

MCQmedium

A Pod must be prevented from reading or writing to its container root filesystem. The application only writes to an emptyDir mount at /tmp. Which securityContext field should be set in the Pod specification to enforce this at the container level?

A.runAsNonRoot: true

B.privileged: false

C.readOnlyRootFilesystem: true

D.allowPrivilegeEscalation: false

AnswerC

Setting readOnlyRootFilesystem to true mounts the container's root filesystem as read-only, which directly prevents any writes to the root filesystem. The emptyDir volume mounted at /tmp remains writable because it is a separate mount. This is the standard Kubernetes securityContext field for enforcing an immutable root filesystem at the container level.

Why this answer

The readOnlyRootFilesystem field in the container securityContext mounts the root filesystem as read-only, directly preventing writes. Other securityContext fields such as privileged, allowPrivilegeEscalation, and runAsNonRoot improve container isolation but do not restrict filesystem writability. Mounting a writable emptyDir at /tmp allows the application to continue writing to the required path while the rest of the root filesystem remains immutable.

Exam trap

The trap here is assuming that running as non-root or disabling privilege escalation also makes the root filesystem read-only, when only readOnlyRootFilesystem controls filesystem writability.

Full explanation →

559

MCQhard

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

A.Use etcdctl to encrypt the data directory

B.Create an EncryptionConfiguration resource with aescbc, restart API server with --encryption-provider-config

C.Set --encryption-provider=secretbox on etcd

D.Set ETCD_ENABLE_ENCRYPTION=true environment variable

AnswerB

The correct procedure is to define an EncryptionConfiguration file that specifies the aescbc provider along with a valid key, then start kube-apiserver with the --encryption-provider-config flag pointing to that file. After restarting the API server, it will encrypt matching Kubernetes resources (e.g., Secrets) before persisting them to etcd and decrypt them on reads. This is the officially supported, cluster-wide mechanism for encryption at rest in Kubernetes.

Why this answer

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

Exam trap

The trap here is that candidates often assume encryption at rest is configured directly on etcd (via flags or environment variables), when in fact it is a kube-apiserver-level feature that uses an EncryptionConfiguration resource and the --encryption-provider-config flag.

How to eliminate wrong answers

Option A is wrong because etcdctl does not have a command to encrypt the entire data directory; encryption is handled at the Kubernetes API server level, not by directly manipulating etcd. Option C is wrong because --encryption-provider is not a valid flag for etcd; etcd itself does not natively support encryption at rest via a flag, and the encryption provider configuration is applied to the kube-apiserver, not etcd. Option D is wrong because ETCD_ENABLE_ENCRYPTION is not a recognized environment variable in etcd v3.5; encryption at rest is not enabled by setting an environment variable on etcd.

Full explanation →

560

MCQmedium

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

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

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

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

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

AnswerC

This option fails to deny pods that specifically run as root (UID 0). The rule `not input.spec.containers[_].securityContext.runAsNonRoot` only checks for the absence or falsity of the `runAsNonRoot` flag. A container can still run as a non-root user (e.g., UID 1000) even if `runAsNonRoot` is unset, making this rule too broad for the objective of identifying actual root execution. It is tempting because `runAsNonRoot` relates to root prevention. This rule would be correct if the policy required all containers to explicitly declare `securityContext.runAsNonRoot: true` as a security best practise.

Why this answer

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

Exam trap

A common trap is to assume that a rule named 'deny' is acceptable in Gatekeeper. Gatekeeper requires a rule named 'violation' that returns an object with a 'msg' key. Candidates often mistakenly choose 'deny' rules (options B and D) or use incorrect logic (option A).

How to eliminate wrong answers

Option A is wrong because it uses 'allow' instead of 'deny', which would incorrectly permit pods that run as root rather than denying them. Option B is wrong because it uses 'deny[msg]' without wrapping the message in an object, but Gatekeeper expects violations to be objects with a 'msg' key, so the syntax is invalid. Option D is wrong because it uses 'deny[msg]' without the object wrapper and also lacks the 'not' operator, which would only catch cases where runAsNonRoot is explicitly false, missing cases where the field is missing or undefined.

Full explanation →

561

MCQmedium

You need to isolate a compromised pod named 'malicious-pod' in the 'default' namespace so that it cannot communicate with any other pod, but can still receive traffic from a specific monitoring pod. Which NetworkPolicy should you apply?

A.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate-pod spec: podSelector: matchLabels: app: malicious-pod ingress: - from: - podSelector: matchLabels: app: monitoring-pod policyTypes: - Ingress - Egress

B.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate-pod spec: podSelector: matchLabels: app: malicious-pod egress: - {} policyTypes: - Egress

C.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate-pod spec: podSelector: matchLabels: app: malicious-pod policyTypes: - Ingress - Egress

D.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate-pod spec: podSelector: matchLabels: app: malicious-pod ingress: - {} policyTypes: - Ingress

AnswerA

This policy correctly isolates the compromised pod by selecting it with podSelector and defining an ingress rule that only allows traffic from pods labeled app: monitoring-pod. Because policyTypes explicitly includes both Ingress and Egress, and no egress rules are present, the pod gets a default egress deny. Thus, the pod cannot reach outbound destinations and only accepts incoming traffic from the monitoring pod, achieving effective quarantine while preserving observability.

Why this answer

It selects the compromised pod, allows ingress only from the monitoring pod (using podSelector), and specifies policyTypes as both Ingress and Egress. Since no egress rules are defined, egress traffic is denied by default, isolating the pod from initiating communication. Option B incorrectly allows all egress via an empty egress rule.

Option C denies all ingress (no ingress rules) and thus blocks the monitoring pod. Option D allows all ingress and does not restrict egress, failing to isolate the pod.

Exam trap

A common mistake is thinking that an empty `ingress` or `egress` array denies all traffic, but in NetworkPolicy, if the policy type is specified and no rules are provided, all traffic of that direction is denied. However, if the policy type is not specified, traffic is allowed.

Full explanation →

562

MCQeasy

Which kubectl command would you use to create a ValidatingWebhookConfiguration from a YAML file?

A.kubectl run webhook --image=webhook --restart=Never

B.kubectl apply -f webhook.yaml

C.kubectl create -f webhook.yaml

D.kubectl expose deployment webhook --port=443

AnswerB

kubectl apply is the standard declarative approach: it sends the entire ValidatingWebhookConfiguration manifest to the API server, which then stores the resource and records the last-applied-configuration so future applies produce a precise three-way merge patch. This idempotent behavior lets you use the same command to both create and update the webhook, which is why it is the recommended method for managing admission webhook resources.

Why this answer

`kubectl apply -f webhook.yaml` is the standard command to create or update Kubernetes resources from a YAML file, including a ValidatingWebhookConfiguration. This command uses declarative management, applying the configuration defined in the file to the cluster, which is the recommended approach for creating admission webhooks.

Exam trap

In the CKS exam, candidates often confuse `kubectl create` and `kubectl apply`. While `kubectl create -f` creates a resource, `kubectl apply -f` is the preferred declarative approach for managing resources like ValidatingWebhookConfiguration because it supports idempotent updates and better handles changes over time.

How to eliminate wrong answers

Option A is wrong because `kubectl run` creates a Pod (or Deployment) from an image, not a ValidatingWebhookConfiguration; it cannot parse a YAML file for custom resource types. Option C is wrong because `kubectl create -f webhook.yaml` would attempt to create resources from the file, but it uses imperative management and may fail if the resource already exists or if the YAML contains complex configurations that require `apply` semantics; more importantly, `kubectl create` is not the typical command for ValidatingWebhookConfiguration as it does not handle updates gracefully. Option D is wrong because `kubectl expose` creates a Service to expose a deployment, not a ValidatingWebhookConfiguration; it has no relation to webhook configuration resources.

Full explanation →

563

MCQeasy

Which kubectl command would you use to create a Secret from a file named 'db-password.txt'?

A.kubectl apply -f db-password.txt

B.kubectl create configmap db-password --from-file=db-password.txt

C.kubectl create secret tls db-password --cert=db-password.txt

D.kubectl create secret generic db-password --from-file=db-password.txt

AnswerD

Correct. `kubectl create secret generic` with `--from-file` creates a generic Secret where the content of the file is stored as a key-value pair. The key defaults to the filename, and the value is the file content.

Why this answer

`kubectl create secret generic` is the command to create a generic (opaque) Secret from a file using the `--from-file` flag. This reads the content of `db-password.txt` and stores it as a key-value pair in the Secret, where the key defaults to the filename. This is the standard method for creating a Secret from a plaintext file in Kubernetes.

Exam trap

The trap here is that candidates confuse `kubectl create secret generic` with `kubectl create configmap` (Option B) or misuse `kubectl apply -f` (Option A) for non-manifest files, failing to recognize that Secrets require explicit creation commands and are distinct from ConfigMaps in purpose and handling.

How to eliminate wrong answers

Option A is wrong because `kubectl apply -f` expects a Kubernetes manifest file (YAML/JSON), not a plain text file like `db-password.txt`; it would fail to parse the content. Option B is wrong because it uses `kubectl create configmap` to create a ConfigMap, not a Secret; ConfigMaps store non-sensitive data, while Secrets are designed for sensitive data like passwords. Option C is wrong because `kubectl create secret tls` is specifically for TLS certificates and requires `--cert` and `--key` flags pointing to PEM-encoded certificate and key files, not a plain password file.

Full explanation →

564

MCQeasy

Which kubelet flag should be set to ensure the kubelet does not allow anonymous requests?

A.--authentication-token-webhook=true

B.--read-only-port=0

C.--anonymous-auth=false

D.--protect-kernel-defaults=true

AnswerC

This is the correct flag because it explicitly disables anonymous authentication in the kubelet's authentication layer. When set to false, any request that does not present valid client certificates, bearer tokens, or other configured credentials is rejected with 401 Unauthorized before reaching kubelet handlers. This directly prevents unauthenticated access to the kubelet's API and is a required hardening step in the CIS Kubernetes Benchmark.

Why this answer

Setting `--anonymous-auth=false` explicitly disables anonymous requests to the kubelet. By default, anonymous authentication is enabled, which allows unauthenticated users to access the kubelet API. Disabling this flag ensures that only authenticated requests are processed, aligning with the principle of least privilege and hardening the cluster.

Exam trap

The trap here is that candidates often confuse `--anonymous-auth=false` with `--authentication-token-webhook=true`, thinking token webhook alone blocks anonymous requests, but anonymous auth must be explicitly disabled as a separate step.

How to eliminate wrong answers

Option A is wrong because `--authentication-token-webhook=true` enables webhook-based token authentication (e.g., for service accounts), but it does not affect anonymous requests; anonymous auth is controlled by a separate flag. Option B is wrong because `--read-only-port=0` disables the read-only port (10255), which reduces exposure but does not prevent anonymous requests on the secure port (10250). Option D is wrong because `--protect-kernel-defaults=true` ensures kernel-level security settings (e.g., sysctl parameters) are enforced, but it has no impact on kubelet authentication or anonymous request handling.

Full explanation →

565

MCQhard

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

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

B.kubectl cordon control-plane

C.Edit the pod YAML to add tolerations for node-role.kubernetes.io/control-plane

D.kubectl delete pod --all

AnswerC

Control-plane nodes in kubeadm clusters carry the taint `node-role.kubernetes.io/control-plane:NoSchedule`, so a pod must include a matching toleration such as `tolerations: - key: node-role.kubernetes.io/control-plane, operator: Exists, effect: NoSchedule` before the scheduler will consider that node. Adding this toleration to the pod's YAML makes it explicitly accept the taint, allowing the pod to be placed on the control-plane node. This is the targeted, least-invasive solution because it only affects the workload that needs to run there, without altering node-level security settings.

Why this answer

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

Exam trap

The trap here is that candidates often choose to remove the taint (Option A) because it seems like a quick fix, but the CKS exam emphasizes security best practices—taints are a security mechanism to isolate control-plane components, and removing them globally is insecure and unnecessary when a toleration can be added to the specific pod.

How to eliminate wrong answers

Option A is wrong because `kubectl taint nodes control-plane node-role.kubernetes.io/control-plane-` removes the taint from the control-plane node, which would allow all pods to schedule there, but this is a cluster-wide change that violates security best practices (control-plane nodes should remain tainted to isolate critical components). Option B is wrong because `kubectl cordon control-plane` marks the node as unschedulable, which would prevent any new pods from being scheduled on it, making the problem worse. Option D is wrong because `kubectl delete pod --all` deletes all pods in the current namespace, which does not address the scheduling issue caused by the taint and may disrupt running workloads.

Full explanation →

566

Multi-Selectmedium

Which TWO of the following are valid Pod Security Standards levels?

Select 2 answers

A.secure

B.default

C.privileged

D.baseline

E.strict

AnswersC, D

Privileged is the first and most permissive Pod Security Standard level. It intentionally imposes no restrictions on the pod security context, allowing privileged containers, host namespaces, and arbitrary capabilities. This level is commonly used for system-level pods such as cluster add-ons that require direct host access. It is a valid level according to the Pod Security Standards.

Why this answer

The Pod Security Standards (PSS) define three levels: privileged, baseline, and restricted. 'Privileged' is the most permissive level, allowing all known privilege escalations and is intended for system-level workloads that require unrestricted access to host resources.

Exam trap

The CKS exam often tests the exact naming of the three Pod Security Standards levels, and candidates mistakenly invent plausible-sounding names like 'secure', 'default', or 'strict' instead of the official terms 'privileged', 'baseline', and 'restricted'.

Full explanation →

567

MCQeasy

To reduce the attack surface, a security best practice is to drop all capabilities from a container and add only those required. Which securityContext field is used to drop all capabilities?

A.capabilities.disable: ["ALL"]

B.capabilities.remove: ["ALL"]

C.capabilities.drop: ["ALL"]

D.privileged: false

AnswerC

Setting `capabilities.drop: ["ALL"]` explicitly removes every Linux capability from the container's effective, permitted, and inheritable sets, so even a root UID cannot perform privileged operations such as raw socket creation, binding to ports below 1024 (if governed by capability), or mounting filesystems. This is the correct least-privilege baseline; if a workload genuinely needs a specific capability, it can be added back selectively via `capabilities.add`. It directly reduces the kernel attack surface by denying access to privileged kernel operations.

Why this answer

In Kubernetes, the `capabilities.drop` field in the securityContext is used to explicitly remove Linux capabilities from a container. Setting `capabilities.drop: ["ALL"]` drops all capabilities, effectively reducing the attack surface by ensuring the container starts with no privileges, and then specific capabilities can be added back via `capabilities.add` if needed.

Exam trap

CNCF often tests the exact Kubernetes API field name `capabilities.drop` versus common but incorrect synonyms like `disable` or `remove`, and candidates may confuse dropping all capabilities with simply disabling privileged mode.

How to eliminate wrong answers

Option A is wrong because `capabilities.disable` is not a valid field in the Kubernetes securityContext; the correct field is `capabilities.drop`. Option B is wrong because `capabilities.remove` is not a recognized field in the Kubernetes API; the field is specifically named `drop`. Option D is wrong because `privileged: false` only disables privileged mode, but the container still retains its default set of capabilities; it does not drop all capabilities.

Full explanation →

568

MCQmedium

You want to ensure that the Kubernetes Dashboard is accessed only by authenticated users with specific permissions. What is the BEST approach?

A.Expose Dashboard via NodePort and rely on network firewalls

B.Create a ClusterRoleBinding granting cluster-admin to all service accounts

C.Set Dashboard to use HTTP instead of HTTPS

D.Use an ingress with authentication, and create RBAC roles for Dashboard users

AnswerD

This approach secures the dashboard at multiple layers: an ingress controller terminates TLS and can enforce authentication (e.g., OIDC, mTLS, or basic auth) before traffic reaches the dashboard, preventing unauthorised access and protecting credentials in transit. Beyond that, creating dedicated RBAC roles for Dashboard users restricts each user to only the namespace verbs and resources they need, limiting blast radius if their token is stolen. Combining ingress-level auth with fine-grained RBAC follows the principle of least privilege and gives you a centrally managed, auditable access path.

Why this answer

The Kubernetes Dashboard should be secured using an Ingress controller with authentication (e.g., OIDC, basic auth, or client certificate) combined with fine-grained RBAC roles to restrict what each authenticated user can do. This ensures that only authorized users with specific permissions can access the Dashboard, following the principle of least privilege and cluster hardening best practices.

Exam trap

The trap here is that candidates often think network-level controls (NodePort + firewall) are sufficient for securing the Dashboard, but the CKS exam emphasizes that Kubernetes security requires authentication and authorization at the API level, not just network segmentation.

How to eliminate wrong answers

Option A is wrong because exposing the Dashboard via NodePort bypasses authentication and authorization, relying solely on network firewalls which do not provide user-level access control or audit logging. Option B is wrong because granting cluster-admin to all service accounts would give every service account full administrative privileges, violating the principle of least privilege and creating a massive security risk. Option C is wrong because setting the Dashboard to use HTTP instead of HTTPS exposes all traffic in plaintext, allowing man-in-the-middle attacks and credential theft, and does not address authentication or authorization.

Full explanation →

569

MCQmedium

A Kubernetes cluster has Kyverno installed. A policy requires that all images come from a trusted registry 'trusted.example.com'. A Deployment uses the image 'nginx:latest'. When the Deployment is created, it is blocked. What Kyverno policy action is being used?

A.validate with failureAction: enforce

B.audit

C.mutate

D.generate

AnswerA

A validate policy with failureAction: enforce configures Kyverno to actively reject any resource that does not match the required pattern. When the validation rule fails, the admission webhook returns a denial to the API server, preventing the resource from being created or updated. This is the correct way to make a 'require' policy block non-compliant resources.

Why this answer

Kyverno's `validate` policy with `failureAction: enforce` is the mechanism that blocks resource creation when validation rules are violated. In this scenario, the policy checks that the image comes from `trusted.example.com`, and since `nginx:latest` does not match, the policy actively denies the Deployment, which is the behavior of `enforce` mode.

Exam trap

The trap here is that candidates confuse `audit` mode (which reports violations but allows creation) with `enforce` mode (which blocks creation), or they mistakenly think `mutate` can block resources when it only modifies them after admission.

How to eliminate wrong answers

Option B is wrong because `audit` mode only generates a policy violation report without blocking the resource; the Deployment would be created but flagged. Option C is wrong because `mutate` policies modify resources to meet policy requirements (e.g., prepending a registry prefix) rather than blocking them; they do not deny creation. Option D is wrong because `generate` policies create additional resources (e.g., NetworkPolicies) based on triggers, not block or validate existing resources.

Full explanation →

570

MCQmedium

A DevOps engineer runs 'trivy image myapp:latest' and finds a critical CVE in the base image. Which Dockerfile change would BEST address this?

A.Use an Alpine base image with the latest tag

B.Set USER root in the Dockerfile

C.Switch to a distroless base image with a SHA digest

D.Add a non-root user in the Dockerfile

AnswerC

Switching to a distroless base image (e.g., gcr.io/distroless) removes package managers, shells, and unused utilities, leaving only the minimal OS libraries required to run the application, which dramatically reduces the number of installable components where CVEs can live. Pinning the image by SHA-256 digest instead of a mutable tag ensures that the exact same immutable image is used every time, preventing a future 'latest' tag update from silently introducing known vulnerabilities or malicious code.

Why this answer

Switching to a distroless base image with a SHA digest (e.g., gcr.io/distroless/base@sha256:...) eliminates the vulnerable packages present in the original base image because distroless images contain only the minimal runtime dependencies (e.g., glibc, libssl) and no package manager or shell, drastically reducing the attack surface. Pinning the image by SHA digest ensures immutability and prevents the base image from being silently updated to a version that reintroduces the same or different vulnerabilities, which is critical for supply chain security.

Exam trap

The CKS exam often tests the misconception that simply using a smaller base image (like Alpine) or adding a non-root user is sufficient to fix a CVE, when in reality the vulnerability must be removed from the image entirely, and distroless with a SHA digest achieves that by eliminating the vulnerable components and pinning the image hash.

How to eliminate wrong answers

Option A is wrong because using an Alpine base image with the latest tag does not guarantee the CVE is fixed; the latest tag is mutable and can point to a vulnerable version, and Alpine itself may still contain the vulnerable package or a different CVE. Option B is wrong because setting USER root in the Dockerfile increases the attack surface by running the container with root privileges, which exacerbates security risks rather than addressing the vulnerable base image. Option D is wrong because adding a non-root user does not remediate the CVE in the base image; it only reduces the blast radius of a compromise but leaves the vulnerable packages intact.

Full explanation →

571

MCQhard

A Kyverno policy is written to require all images to use SHA256 digests instead of tags. The policy uses a 'validate' rule with 'pattern' on 'spec.containers[*].image'. Which pattern would match an image reference like 'registry.example.com/myapp@sha256:abc123...'?

A.*@sha256*

B."*@*"

C."*@sha256:*"

D."*:*"

AnswerC

Correct: In Kyverno's wildcard matching, this pattern requires an image reference that has '@sha256:' followed by any sequence of characters. That means the immutable part of the reference is a SHA256 digest with the standard 'algorithm:digest' format; the leading '*' accounts for the registry/repository/name, and the trailing '*' consumes the 64-character hex digest. This precisely ensures images are pinned to a SHA256 digest and not to a mutable tag.

Why this answer

Option C ('*@sha256:*') correctly matches image references using SHA256 digest. It ensures the digest algorithm is exactly 'sha256' followed by a colon and digest. Option A ('*@sha256*') is too permissive as it matches any image reference containing 'sha256' as a substring, potentially allowing other algorithms like 'sha256-extra'.

Option B ('*@*') matches any digest algorithm, not specifically SHA256. Option D ('*:*') matches tags, not digests. Therefore, only C meets the requirement.

Exam trap

Candidates may mistakenly choose option A, noticing that both A and C contain 'sha256', but A is not strict enough and would match non-SHA256 digests. The difference between a wildcard match and a colon is subtle but crucial.

How to eliminate wrong answers

Option A is wrong because '*@sha256:*' is identical to Option C, but the question lists it as a duplicate with the same text, and only one is marked as correct; the correct answer is the one explicitly labeled [CORRECT]. Option B is wrong because '*@*' would match any image reference containing an '@' symbol, including those with non-SHA256 digests (e.g., 'registry.example.com/myapp@sha512:...' or even 'user@host' patterns), which does not enforce the SHA256 requirement. Option D is wrong because '*:*' matches image references using tags (e.g., 'registry.example.com/myapp:latest'), not digests, and would allow non-compliant tag-based references.

Full explanation →

572

MCQeasy

In a CI/CD pipeline, which step is MOST effective for detecting known vulnerabilities in a container image before deployment?

A.Run a vulnerability scan on the container image

B.Check the image size

C.Run unit tests on the application code

D.Lint the Dockerfile

AnswerA

Scanning the built image against known vulnerability databases detects outdated packages and CVEs before the image reaches a registry or runtime. This catches known flaws at the earliest pipeline stage, whereas signing, linting or runtime monitoring do not identify known vulnerabilities in image contents.

Why this answer

Running a vulnerability scan on the container image (Option A) is the most effective step because it directly checks the image layers and installed packages against known Common Vulnerabilities and Exposures (CVEs) databases, such as the National Vulnerability Database (NVD). This identifies security flaws in base images and dependencies before deployment, which is a core requirement of supply chain security in Kubernetes.

Exam trap

The CKS exam often tests the distinction between static analysis of build files (like Dockerfile linting) and runtime or image-level security scanning, leading candidates to mistakenly choose linting as a vulnerability detection method.

How to eliminate wrong answers

Option B is wrong because checking the image size only helps with storage and performance optimization, not with detecting known vulnerabilities. Option C is wrong because unit tests validate application logic and functionality, not the security posture of the container image or its dependencies. Option D is wrong because linting the Dockerfile checks for syntax errors and best practices in the build instructions, but it does not scan the resulting image for known CVEs.

Full explanation →

573

MCQeasy

Which command scans a Docker image for CVEs using Trivy?

A.trivy cve myapp:latest

B.trivy check myapp:latest

C.trivy image myapp:latest

D.trivy scan myapp:latest

AnswerC

The trivy image subcommand targets a container image reference directly, pulling and scanning its layers against vulnerability databases to report CVEs. Other Trivy subcommands scan filesystems, repositories, or configuration files, so only this form satisfies the image-scanning requirement.

Why this answer

`trivy image` is the specific Trivy subcommand used to scan a container image for vulnerabilities (CVEs). Trivy does not have a `cve`, `check`, or `scan` subcommand; the correct syntax is `trivy image <image-name>`.

Exam trap

The CNCF exam often tests the exact subcommand syntax of security tools like Trivy, expecting candidates to know that `trivy image` is the correct command, not generic verbs like `scan` or `check`.

How to eliminate wrong answers

Option A is wrong because `trivy cve` is not a valid Trivy subcommand; Trivy uses `trivy image` to scan images for CVEs. Option B is wrong because `trivy check` does not exist; Trivy's subcommand for image scanning is `image`, not `check`. Option D is wrong because `trivy scan` is not a valid subcommand; the correct subcommand is `image`.

Full explanation →

574

MCQeasy

Which of the following is the correct way to drop all capabilities in a container's security context?

A.securityContext: capabilities: drop: ['ALL']

B.securityContext: capabilities: remove: ['ALL']

C.securityContext: capabilities: []

D.securityContext: capabilities: add: []

AnswerA

Setting securityContext.capabilities.drop to ['ALL'] is the correct Kubernetes syntax for revoking every Linux capability from the container's effective/permitted/bounding sets. This ensures the process starts with no capabilities, and you can selectively re-add specific capabilities using the add field. It is the recognized approach for least privilege and is required by restricted Pod Security Standards.

Why this answer

In Kubernetes, the `securityContext.capabilities.drop` field is used to explicitly remove Linux capabilities from a container. Setting `drop: ['ALL']` removes all capabilities, ensuring the container runs with the least privilege. This is the standard and recommended way to harden container security.

Exam trap

The CKS exam often tests the distinction between `drop` and `add` fields, and candidates may mistakenly think that setting `add: []` or an empty `capabilities` list achieves the same effect as dropping all capabilities.

How to eliminate wrong answers

Option B is wrong because `remove` is not a valid field in the Kubernetes security context; the correct field is `drop`. Option C is wrong because setting `capabilities: []` is invalid syntax—the `capabilities` field must be an object with `add` and/or `drop` arrays, not an empty list. Option D is wrong because `add: []` adds no capabilities but does not drop any existing ones, so the container retains its default capabilities, failing to drop all.

Full explanation →

575

Multi-Selectmedium

Which TWO of the following are valid methods to verify the integrity of a container image in a Kubernetes supply chain? (Select 2)

Select 2 answers

A.Signing the image with Cosign and verifying the signature before deployment

B.Running the container in a separate namespace

C.Using a SHA256 digest instead of a tag in the image reference

D.Scanning the image for vulnerabilities using Trivy

E.Using a base image with the latest tag

AnswersA, C

Cosign image signing, backed by Sigstore, creates a cryptographic signature bound to the image digest and the signer's identity (such as an OIDC email). Verifying that signature before deployment confirms both that the image content is unmodified and that it came from an approved publisher, making it a true provenance and tamper-evidence check. Without this step, an attacker who compromises a registry can swap a signed-looking tag for a malicious image and the cluster would have no way to detect the substitution.

Why this answer

Cosign is a tool for signing container images using cryptographic keys, and verifying the signature before deployment ensures that the image has not been tampered with since it was signed. This provides integrity and authenticity in the software supply chain, as the signature can be validated against a trusted public key or a keyless identity (e.g., via Fulcio).

Exam trap

The CNCF CKS exam often tests the distinction between integrity verification (e.g., signatures, digests) and other security practices like vulnerability scanning or namespace isolation, leading candidates to mistakenly select scanning or isolation as valid integrity checks.

Full explanation →

576

MCQeasy

Which kubectl command can be used to execute a shell inside a running container for forensic analysis?

A.kubectl delete pod <pod>

B.kubectl logs <pod>

C.kubectl describe pod <pod>

D.kubectl exec -it <pod> -- /bin/sh

AnswerD

kubectl exec -it <pod> -- /bin/sh is correct because -i keeps stdin open for the session, -t allocates a pseudo-TTY, and the -- separates the command to run inside the container. This combination starts an interactive shell as long as /bin/sh is present in the container's filesystem; if it is not, a similar command with /bin/bash or an ephemeral debug container would be needed.

Why this answer

The `kubectl exec -it <pod> -- /bin/sh` command opens an interactive TTY (`-it`) into a running container and launches a shell (`/bin/sh`), which is exactly what's needed for live forensic analysis inside a compromised or suspect container. It does not restart or alter the pod, preserving volatile evidence like running processes, open file descriptors, and in-memory artifacts. This is the standard CKS-recommended approach for container-level incident response.

Exam trap

CKS often tests whether candidates confuse read-only inspection commands (`logs`, `describe`) with interactive execution — the trap is picking `logs` because it 'shows what's happening' when the question actually requires shell access.

How to eliminate wrong answers

Option A is wrong because `kubectl delete pod` destroys the pod and all its ephemeral evidence, which is the opposite of forensic preservation. Option B is wrong because `kubectl logs` only retrieves stdout/stderr from the container — it cannot run commands, inspect the filesystem, or examine running processes. Option C is wrong because `kubectl describe pod` only shows metadata, events, and status from the API server, not the live container runtime state.

Full explanation →

577

MCQmedium

A security engineer is configuring a Kubernetes cluster to meet CIS benchmark recommendations. The cluster uses kubeadm for bootstrapping. Which action should be taken to ensure the kube-apiserver is hardened against unauthorized access?

A.Set --insecure-port=8080 on the kube-apiserver

B.Disable the NodeRestriction admission plugin

C.Enable encryption at rest for secrets in etcd

D.Set --anonymous-auth=false on the kube-apiserver

AnswerD

Setting --anonymous-auth=false is the precise corrective action: it tells the kube-apiserver to reject any request that lacks valid credentials, instead of letting it proceed with the system:anonymous user. This directly neutralizes the unauthorized access vector described in the scenario, forcing every API interaction to authenticate through a recognized mechanism such as client certificates, bearer tokens, or OIDC. It is the officially recommended hardening default for production clusters, though note that kubelet health-check probes may need an explicit authenticated path if they previously relied on anonymous read access.

Why this answer

Setting `--anonymous-auth=false` on the kube-apiserver disables anonymous requests, ensuring that all API requests must be authenticated. This directly addresses CIS benchmark recommendations for hardening the API server against unauthorized access by preventing unauthenticated users from reaching the API.

Exam trap

CNCF often tests the distinction between authentication hardening (anonymous-auth) and authorization or encryption controls, leading candidates to confuse enabling encryption at rest (Option C) with preventing unauthorized API access.

How to eliminate wrong answers

Option A is wrong because setting `--insecure-port=8080` enables an unencrypted, non-authenticated HTTP port, which is a severe security risk and explicitly deprecated in Kubernetes; the CIS benchmark recommends disabling the insecure port entirely. Option B is wrong because disabling the NodeRestriction admission plugin would allow compromised nodes to modify their own Node and Pod objects, reducing security; the CIS benchmark recommends enabling it to enforce node authorization. Option C is wrong because enabling encryption at rest for secrets in etcd protects data confidentiality at the storage layer but does not prevent unauthorized access to the kube-apiserver itself; it addresses a different control (data protection) rather than authentication hardening.

Full explanation →

578

MCQhard

A cluster has a PodSecurityPolicy that requires 'RunAsAny' for the user. An administrator wants to enforce that all pods in namespace 'production' must run with a specific seccomp profile. Which approach is recommended given PSP is deprecated?

A.Enable PodSecurity admission with 'restricted' policy in enforce mode

B.Create a new PSP with seccomp profile and assign it to the namespace

C.Set seccomp profile in the kubelet configuration

D.Use a mutating admission webhook to add seccomp profile

AnswerA

PodSecurity admission is the built-in replacement for PSPs; the `restricted` policy in enforce mode validates every pod against a standard set of constraints, and it specifically requires a seccomp profile of `RuntimeDefault` or `localhost`. Because it runs in the admission phase, the API server rejects any pod that does not declare the profile, making it a true enforcement control at the namespace level. This is the recommended way to guarantee seccomp coverage across all workloads.

Why this answer

PodSecurity admission (the replacement for PSP) allows enforcing a 'restricted' policy that mandates a seccomp profile (e.g., RuntimeDefault) at the namespace level. This directly meets the requirement without relying on deprecated PSPs, and the 'enforce' mode ensures pods violating the policy are rejected.

Exam trap

CNCF often tests the deprecation of PSP and the shift to PodSecurity admission; the trap here is that candidates may still choose a PSP-based option (B) or overcomplicate with webhooks (D), missing the built-in, recommended replacement.

How to eliminate wrong answers

Option B is wrong because PSP is deprecated and will be removed in Kubernetes 1.25+, so creating a new PSP is not a recommended long-term solution; also, PSPs are cluster-scoped and cannot be directly assigned to a namespace without additional RBAC. Option C is wrong because kubelet configuration sets a default seccomp profile for all pods on the node, not per-namespace enforcement, and it cannot selectively target the 'production' namespace. Option D is wrong because while a mutating admission webhook could add the seccomp profile, it is more complex and less standard than using the built-in PodSecurity admission controller, which is the recommended approach per Kubernetes documentation.

Full explanation →

579

Multi-Selecthard

Which THREE of the following are valid methods to secure etcd?

Select 3 answers

A.Use HTTP instead of HTTPS to reduce overhead

B.Encrypt secrets at rest using EncryptionConfiguration

C.Enable RBAC authorization on etcd

D.Open etcd port 2379 to all network interfaces

E.Enable TLS client certificates for authentication

AnswersB, C, E

EncryptionConfiguration, passed via the apiserver's --encryption-provider-config flag, defines a set of key providers (aescbc, aesgcm, or secretbox) that encrypt specific resources — typically Secrets — before they are written to etcd and decrypt them on reads. This protects data at rest, meaning if an attacker steals an etcd snapshot or physically accesses the storage files, they only see ciphertext. Without this, any read of etcd returns plaintext secrets.

Why this answer

Kubernetes supports encrypting secrets at rest in etcd via an EncryptionConfiguration object. This configuration specifies which resources (e.g., secrets) should be encrypted and which encryption provider (e.g., AES-CBC, secretbox) to use, ensuring that data stored on disk is protected against unauthorized access to the etcd data directory.

Exam trap

The trap here is that candidates may think HTTP reduces overhead and is acceptable for internal cluster traffic, but the CKS exam strictly requires TLS encryption for all etcd communication, and exposing ports to all interfaces is a clear security violation.

Full explanation →

580

MCQhard

An administrator wants to ensure that containers in a pod cannot run with any Linux capabilities except the minimal required for the container runtime. The pod is subject to the 'restricted' Pod Security Standard. Which capability configuration should be set in the pod's security context?

A.capabilities: drop: ["ALL"]

B.capabilities: drop: ["NET_RAW", "CHOWN"]

C.capabilities: add: ["NET_BIND_SERVICE"]

D.capabilities: add: ["ALL"]

AnswerA

Dropping ALL is mandatory under the restricted Pod Security Standard. This entry clears every Linux capability from the container's bounding set, so processes start with zero capabilities beyond the default set (which is effectively none). The policy explicitly requires `drop: ["ALL"]` and forbids any `add` entries; this is the only option that fully satisfies that control and is therefore valid.

Why this answer

The 'restricted' Pod Security Standard (PSS) requires that all Linux capabilities be dropped except those essential for the container runtime (e.g., CAP_NET_BIND_SERVICE is allowed by default in some runtimes, but the standard explicitly mandates dropping all capabilities). Option A correctly uses `drop: ["ALL"]` to remove every capability, ensuring the container runs with the minimal set required by the runtime, which aligns with the PSS 'restricted' profile. This approach enforces the principle of least privilege by preventing the container from gaining any unnecessary kernel privileges.

Exam trap

CNCF often tests the misconception that dropping only specific dangerous capabilities (like `NET_RAW` and `CHOWN`) is sufficient for the 'restricted' PSS, when in fact the standard requires dropping all capabilities to achieve the minimal privilege level.

How to eliminate wrong answers

Option B is wrong because dropping only `NET_RAW` and `CHOWN` does not satisfy the 'restricted' PSS requirement to drop all capabilities; it leaves other potentially dangerous capabilities (e.g., `SYS_ADMIN`, `NET_ADMIN`) intact, violating the standard. Option C is wrong because adding `NET_BIND_SERVICE` is unnecessary and contradicts the 'restricted' PSS, which expects no capabilities to be added; the runtime already provides minimal capabilities, and explicit adds can introduce privileges beyond the allowed set. Option D is wrong because adding `ALL` capabilities grants every Linux capability to the container, which directly violates the 'restricted' PSS and defeats the purpose of capability dropping, creating a severe security risk.

Full explanation →

581

Multi-Selecthard

Which THREE of the following are valid ways to manage secrets in a Kubernetes environment? (Select THREE)

Select 3 answers

A.Use an external secret manager like HashiCorp Vault and inject secrets via sidecar or CSI driver.

B.Store secrets in environment variables directly in the Deployment YAML.

C.Use Kubernetes Secret objects mounted as volumes in pods.

D.Encrypt Secret objects at rest using EncryptionConfiguration.

E.Store secrets in ConfigMaps and reference them in pods.

AnswersA, C, D

Leveraging an external secret manager such as HashiCorp Vault with a sidecar or CSI driver abstracts sensitive data entirely out of etcd. This approach enables dynamic secret rotation, centralized auditing, and fine-grained access policies, while injecting secrets into the pod only at runtime. It also avoids storing even base64-encoded secrets in Kubernetes API objects, significantly reducing the attack surface compared to native Secret objects.

Why this answer

External secret managers like HashiCorp Vault can inject secrets into pods via a sidecar container (e.g., Vault Agent) or a CSI driver (e.g., Secrets Store CSI Driver). This approach avoids storing raw secrets in the cluster, reduces the attack surface, and enables dynamic secret rotation without pod restarts.

Exam trap

A common misconception is that Kubernetes Secrets are inherently secure because they are base64-encoded, but the trap is that base64 is not encryption, and Secrets are stored in plaintext in etcd unless explicitly encrypted with EncryptionConfiguration.

Full explanation →

582

MCQmedium

A security team wants to ensure that all containers in a pod run with only the minimum required Linux capabilities. Which of the following approaches is BEST?

A.Set securityContext.capabilities.drop: ['ALL'] with no add

B.Leave capabilities unset to use the default set

C.Add only the necessary capabilities without dropping

D.Set securityContext.capabilities.drop: ['ALL'] and add only necessary capabilities

AnswerD

Setting securityContext.capabilities.drop to ALL and then adding only the required capabilities is the correct hardening approach because it starts with zero capabilities, eliminating every default privilege that could be exploited. By explicitly adding back only the specific capabilities needed for the application to function—such as NET_BIND_SERVICE or SYS_TIME—the container runs with the absolute minimum privilege necessary. This reduces the potential impact of a container breakout and adheres to the security principle of least privilege.

Why this answer

It implements the principle of least privilege by first dropping all capabilities with `drop: ['ALL']` and then explicitly adding back only those capabilities that are strictly necessary for the container to function. This ensures that the container runs with the absolute minimum set of Linux capabilities, reducing the attack surface and adhering to Kubernetes security best practices for system hardening.

Exam trap

CNCF often tests the misconception that simply dropping all capabilities is sufficient, but the trap here is that dropping all without adding necessary ones can break the application, while adding capabilities without dropping all leaves unnecessary capabilities enabled, both of which fail the 'minimum required' requirement.

How to eliminate wrong answers

Option A is wrong because dropping all capabilities without adding any back may cause the container to fail if it requires any capabilities to operate (e.g., `NET_BIND_SERVICE` for binding to privileged ports), leading to runtime errors. Option B is wrong because leaving capabilities unset uses the default set, which includes many capabilities (e.g., `CHOWN`, `DAC_OVERRIDE`, `FOWNER`, `FSETID`, `KILL`, `SETGID`, `SETUID`, `SETPCAP`, `NET_BIND_SERVICE`, `NET_RAW`, `SYS_CHROOT`, `MKNOD`, `AUDIT_WRITE`, `SETFCAP`) that are often unnecessary and increase the risk of privilege escalation. Option C is wrong because adding only necessary capabilities without first dropping all capabilities leaves the default capabilities intact, which still includes potentially dangerous capabilities that are not required, violating the principle of least privilege.

Full explanation →

583

MCQeasy

Which of the following is a recommended CIS Benchmark control for etcd?

A.Use HTTP for client communication

B.Enable TLS for etcd peer and client communication

C.Disable audit logging

D.Enable anonymous authentication

AnswerB

etcd stores all cluster state, including Secrets, so peer and client traffic must be encrypted. Enabling TLS for both interfaces prevents eavesdropping and tampering on the wire, satisfying the CIS control requiring encrypted etcd communication rather than unauthenticated plaintext transport.

Why this answer

The CIS Benchmark for etcd recommends enabling TLS for both peer and client communication to ensure data in transit is encrypted and authenticated. This prevents man-in-the-middle attacks and unauthorized access to the etcd datastore, which is critical for Kubernetes cluster state integrity.

Exam trap

CNCF often tests the misconception that HTTP is acceptable for internal cluster communication, but the CIS Benchmark explicitly mandates TLS for etcd to protect against network-level attacks, even within a trusted network.

How to eliminate wrong answers

Option A is wrong because using HTTP for client communication transmits data in plaintext, violating the CIS Benchmark's requirement for encrypted communication and exposing sensitive cluster data to interception. Option C is wrong because disabling audit logging removes the ability to track and review access to etcd, which is a key security control for detecting unauthorized changes or breaches. Option D is wrong because enabling anonymous authentication allows unauthenticated requests to access etcd, bypassing identity verification and undermining access control as per CIS recommendations.

Full explanation →

584

MCQmedium

An administrator runs 'kubectl get clusterrolebindings' and notices a ClusterRoleBinding named 'admin-binding' that binds the 'cluster-admin' ClusterRole to a service account in the 'default' namespace. What security concern does this raise?

A.The service account can now perform any action across all namespaces, which violates least-privilege.

B.The service account can only access resources in the 'default' namespace.

C.No concern; service accounts are allowed to have cluster-admin.

D.The ClusterRoleBinding should be replaced with a RoleBinding.

AnswerA

The cluster-admin ClusterRole grants the service account the ability to perform any operation on any resource type in every API group, across all namespaces and cluster-scoped resources. This goes far beyond what a typical workload requires, directly violating the principle of least-privilege and exposing the cluster to significant risk if the SA's token is compromised.

Why this answer

A ClusterRoleBinding grants cluster-wide permissions, and the 'cluster-admin' ClusterRole provides superuser access to perform any action on any resource across all namespaces. Binding this to a service account violates the principle of least privilege because the service account gains unrestricted access to the entire cluster, including sensitive system resources, rather than being limited to only the permissions necessary for its function.

Exam trap

The trap here is that candidates may think a service account bound to a ClusterRole is limited to its namespace, or that 'cluster-admin' is acceptable for any service account, when the CKS exam specifically tests the principle of least privilege and the distinction between RoleBindings (namespace-scoped) and ClusterRoleBindings (cluster-scoped).

How to eliminate wrong answers

Option B is wrong because a ClusterRoleBinding applies cluster-wide, not just to the 'default' namespace; the service account can access resources in all namespaces. Option C is wrong because while service accounts can be bound to cluster-admin, doing so without justification is a significant security concern that violates least-privilege and should be avoided unless absolutely necessary. Option D is wrong because replacing the ClusterRoleBinding with a RoleBinding would limit the binding to a single namespace, but the core issue is the excessive privilege of the 'cluster-admin' ClusterRole, not the binding type; a RoleBinding with 'cluster-admin' is not possible (RoleBindings can only reference ClusterRoles for resources in the same namespace, but 'cluster-admin' still grants cluster-wide scope via a RoleBinding).

Full explanation →

585

Matchingmedium

Match each Kubernetes network security concept to its definition.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Outbound network traffic from a pod to external endpoints

Inbound network traffic to a pod from external sources

Specification of how groups of pods are allowed to communicate

Container Network Interface plugin that implements networking for pods

Infrastructure layer for handling service-to-service communication, often with mTLS

Why these pairings

Correct matches: NetworkPolicy defines ingress/egress rules; Calico network policy extends with advanced features; Ingress rule controls inbound traffic; Egress rule controls outbound traffic; Default deny blocks all unless allowed. Common confusions include swapping ingress and egress definitions and mistaking non-native policies as native.

Full explanation →

586

MCQeasy

What is the purpose of the --audit-policy-file flag on the kube-apiserver?

A.To specify the location of the audit log file

B.To enable audit logging

C.To specify the audit policy configuration

D.To configure the retention of audit logs

AnswerC

Audit logging requires a policy defining which requests to record and at what level. The --audit-policy-file flag supplies that YAML ruleset to the kube-apiserver, enabling it to evaluate each request against the configured rules and write matching events to the audit log.

Why this answer

The `--audit-policy-file` flag on the kube-apiserver specifies the path to a YAML or JSON file that defines the audit policy configuration. This policy determines which events (e.g., requests to the API server) should be logged and at what level (e.g., Metadata, Request, RequestResponse). It does not directly enable audit logging or set the log file location; it only provides the rules for filtering and structuring audit events.

Exam trap

Candidates often confuse the purpose of --audit-policy-file, thinking it enables audit logging or sets the log file location, but it only defines the filtering rules. Audit logging is actually enabled by specifying --audit-log-path (or other audit log flags); without such a flag, audit logging is off by default.

How to eliminate wrong answers

Option A is wrong because the location of the audit log file is specified by the `--audit-log-path` flag, not `--audit-policy-file`. Option B is wrong because audit logging is enabled by default when the kube-apiserver starts; the `--audit-policy-file` flag controls what gets logged, not whether logging is active. Option D is wrong because retention of audit logs (e.g., rotation and max age) is configured via flags like `--audit-log-maxage`, `--audit-log-maxbackup`, and `--audit-log-maxsize`, not the policy file.

Full explanation →

587

Multi-Selectmedium

Which TWO of the following are valid methods to apply a custom seccomp profile to a pod in Kubernetes?

Select 2 answers

A.Setting the annotation 'seccomp.security.alpha.kubernetes.io/pod' on the pod

B.Using 'securityContext.seccompProfile.type: RuntimeDefault' with 'localhostProfile' set

C.Configuring the kubelet with --seccomp-default-profile flag

D.Using 'securityContext.seccompProfile.type: Localhost' with 'localhostProfile' set

E.Adding a seccomp profile to the container image and referencing it in the pod spec

AnswersA, D

This is a valid, though deprecated, method for applying a seccomp profile at the pod level. The annotation's value can be 'localhost/<profile-name>' to reference a profile stored on the node, or 'runtime/default' for the runtime's default. Although superseded by the securityContext.seccompProfile field, this annotation is still honored by the kubelet, making it a legitimate (if legacy) way to configure a custom profile.

Why this answer

The annotation 'seccomp.security.alpha.kubernetes.io/pod' was the original method to apply a seccomp profile to a pod in Kubernetes versions prior to 1.19. This annotation is still valid in older clusters or when using the alpha API, and it directly specifies the seccomp profile path or type for the pod.

Exam trap

CNCF often tests the distinction between the deprecated annotation method and the current 'securityContext.seccompProfile' field, and the trap here is that candidates may think 'localhostProfile' can be combined with 'RuntimeDefault' or that profiles can be embedded in container images, which is incorrect.

Full explanation →

588

Multi-Selectmedium

Which TWO of the following are best practices for minimizing microservice vulnerabilities in a Kubernetes cluster?

Select 2 answers

A.Enable mutual TLS (mTLS) for service-to-service communication using a service mesh.

B.Run containers as root to avoid permission issues.

C.Allow all egress traffic from pods to simplify network management.

D.Set resource limits (CPU/memory) on containers to prevent resource exhaustion attacks.

E.Use hostNetwork: true for pods to improve network performance.

AnswersA, D

Mutual TLS (mTLS) in a service mesh cryptographically verifies both the client and server identities before any payload bytes are exchanged, and it encrypts all in-transit data. This eliminates entire classes of attacks such as on-path eavesdropping, request replay, and service impersonation. Mesh-provided identity (e.g., SPIFFE certificates) also gives you per-service authentication that can drive fine-grained authorization policies, making mTLS a foundational zero-trust control.

Why this answer

Mutual TLS (mTLS) encrypts and authenticates all service-to-service traffic within the cluster, preventing eavesdropping, man-in-the-middle attacks, and unauthorized access. A service mesh like Istio or Linkerd transparently enforces mTLS without requiring application code changes, ensuring that only verified services can communicate. This directly minimizes the attack surface for microservice vulnerabilities by enforcing zero-trust network principles.

Exam trap

CNCF often tests the misconception that 'simplifying network management' (e.g., allowing all egress traffic) is a security best practice, when in fact it removes critical network segmentation controls required for microservice isolation.

Full explanation →

589

Multi-Selectmedium

Which TWO of the following are best practices for securing secrets in Kubernetes?

Select 2 answers

A.Storing secrets as environment variables

B.Using the default secret type (Opaque) for all secrets

C.Enabling encryption at rest for secrets

D.Limiting the number of secrets in the cluster

E.Using an external secrets management system like HashiCorp Vault

AnswersC, E

Enabling encryption at rest for secrets is a core hardening measure because by default secrets are stored in etcd in base64-encoded plaintext, and an attacker who compromises etcd can read every secret in the cluster. Configure the kube-apiserver with an encryption provider such as AES-CBC, KMS, or AWS/GCP KMS, ensuring that the encryption keys are managed outside of etcd. This adds a layer of protection so that even if etcd backups or volumes are exposed, the secrets remain unreadable without the decryption keys.

Why this answer

Kubernetes stores secrets in etcd by default without encryption. Enabling encryption at rest (via the EncryptionConfiguration resource with a provider like AES-CBC or KMS) ensures that secret data is encrypted before being written to etcd, protecting it from unauthorized access to the underlying storage. This is a fundamental security control required for compliance and defense-in-depth.

Exam trap

The CKS exam often tests the misconception that storing secrets as environment variables is acceptable because it is 'convenient' or 'standard practice,' but the CKS exam strictly penalizes this as insecure due to exposure in process listings and logs.

Full explanation →

590

MCQmedium

Which of the following is NOT a recommended method to reduce the attack surface on Kubernetes nodes?

A.Using read-only root filesystems

B.Running containers as non-root

C.Running containers with privileged: true

D.Disabling unnecessary system services on nodes

AnswerC

Setting privileged: true in a Kubernetes pod security context is explicitly not recommended because it disables almost all container isolation features: it grants every Linux capability, removes seccomp restrictions, and allows the container to access host devices, the host kernel, and perform operations like loading kernel modules or altering network settings. The privilegeEscalation flag is implicitly forced to true, meaning the container process gains all capabilities of the root user and can use raw sockets, mount filesystems, and read/write to /dev. This effectively turns the container into a process running with host-level root privileges, making a single compromised process equivalent to a full host compromise. Such a configuration dramatically increases the attack surface and should never be used in a security-conscious cluster, making it the correct answer.

Why this answer

Setting `privileged: true` in a container's security context grants it elevated capabilities equivalent to running as root on the host, including access to all kernel namespaces and devices. This directly increases the attack surface by allowing the container to perform host-level operations, such as loading kernel modules or modifying network settings, which violates the principle of least privilege. The CKS exam emphasizes that privileged containers should be avoided unless absolutely necessary, and they are never a recommended method for reducing the attack surface.

Exam trap

The trap here is that candidates may confuse 'privileged containers' with 'containers running as root' and incorrectly think that running as non-root is the only requirement, when in fact privileged mode grants far more dangerous host-level access regardless of the user ID.

How to eliminate wrong answers

Option A is wrong because using read-only root filesystems prevents containers from writing to their own filesystem, which limits the impact of a compromise by making it harder for an attacker to persist or modify binaries. Option B is wrong because running containers as non-root (e.g., with `runAsUser: 1000`) reduces the risk of privilege escalation by ensuring the container process does not have root UID 0 inside the container, which is a fundamental security best practice. Option D is wrong because disabling unnecessary system services on nodes (e.g., stopping unused daemons like `cups` or `rpcbind`) reduces the number of potential entry points for an attacker, directly shrinking the node's attack surface.

Full explanation →

591

Multi-Selecteasy

You are auditing a cluster for runtime security best practices. Which TWO of the following actions are recommended to improve container runtime security?

Select 2 answers

A.Deploy Falco to monitor system calls and detect anomalous behavior.

B.Disable the container runtime's security engine to reduce overhead.

C.Run containers in privileged mode for better performance.

D.Enable seccomp profiles to restrict available system calls.

E.Set AppArmor to unconfined for all pods to avoid profile conflicts.

AnswersA, D

Falco uses eBPF or kernel modules to intercept every system call, evaluating it against a rich set of rules that flag suspicious behavior such as an unexpected shell in a container, attempts to read sensitive host files, or privilege escalation. It streams real-time alerts, making it the standard runtime security monitoring tool for detecting container-specific threats like cryptominers, reverse shells, and anomalous network activity. Falco's value lies in observing actual behavior after the seccomp/AppArmor filters are applied, providing a critical audit and detection layer.

Why this answer

Falco is a CNCF-graduated runtime security tool that uses eBPF or kernel modules to monitor system calls in real time, detecting anomalous behavior such as unexpected process execution or file writes. Deploying Falco is a recommended best practice for runtime security because it provides deep visibility into container activity without requiring application changes, and it can trigger alerts or actions based on customizable rules.

Exam trap

CNCF often tests the misconception that disabling security features (like seccomp or AppArmor) improves performance without understanding the severe security trade-offs, or that privileged mode is an acceptable performance tuning technique.

Full explanation →

592

Multi-Selectmedium

Which TWO resources can be used to implement RBAC in Kubernetes?

Select 2 answers

A.ClusterRole

B.NetworkPolicy

C.PodSecurityPolicy

D.ServiceAccount

E.Role

AnswersA, E

ClusterRole is a Kubernetes RBAC object that defines permissions, such as verbs (get, list, create) on resources (pods, deployments), but unlike Role it is cluster-scoped. It can grant cluster-wide access when bound via a ClusterRoleBinding, or it can be reused in a single namespace by binding it with a RoleBinding, whose effective permissions are scoped to that namespace. ClusterRole is the correct answer because it is one of the two primary RBAC rule resources, alongside Role.

Why this answer

A is correct because ClusterRole is a Kubernetes RBAC resource that defines a set of permissions (rules) that are not namespaced, allowing cluster-wide access. RBAC in Kubernetes uses Role and ClusterRole objects to specify allowed verbs (e.g., get, list, create) on resources (e.g., pods, secrets), and they are bound to subjects via RoleBinding or ClusterRoleBinding.

Exam trap

CNCF often tests the distinction between RBAC authorization resources (Role/ClusterRole) and other Kubernetes objects that deal with security but serve different purposes, such as NetworkPolicy (network segmentation) or PodSecurityPolicy (pod security constraints), leading candidates to confuse authorization with other security controls.

Full explanation →

593

Multi-Selectmedium

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

Select 2 answers

A.PodSecurityPolicy

B.MutatingAdmissionWebhook

C.ImagePolicyWebhook

D.AdmissionReview

E.OPA

AnswersB, C

MutatingAdmissionWebhook is a built-in admission controller that intercepts API requests after authentication and authorisation, invoking external webhooks to modify objects before persistence. It satisfies the stem's requirement for a valid admission controller, operating in the mutating phase alongside validating webhooks. Kubernetes enables it by default in the recommended admission plugin set.

Why this answer

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

Exam trap

The CKS exam often tests the distinction between deprecated/removed features (like PodSecurityPolicy) and still-valid controllers, and the trap here is that candidates may confuse OPA as a built-in admission controller when it is actually an external policy engine integrated via webhooks.

Full explanation →

594

MCQhard

Refer to the exhibit. A cluster has the ClusterImagePolicy shown. A developer creates a pod with an image from registry.example.com/myapp:v1, which was built and signed by a GitHub Actions workflow that is NOT defined in the policy (different workflow). Which behavior will occur when the pod is created?

A.The pod is admitted because keyless signing does not enforce identity matching.

B.The pod is admitted because the policy only applies to images with a tag 'v*'.

C.The pod is admitted because the image is from the allowed registry.

D.The pod is denied because the image's signer identity does not match the policy.

AnswerD

Cosigned's admission webhook evaluates both the image reference and the signature's identity. Because the keyless certificate presented for this image has an issuer or subject that does not appear in the policy's `identities` array, the admission request is denied. This is the expected behavior when identity matching is enforced, so the pod cannot be admitted.

Why this answer

The ClusterImagePolicy enforces that images must be signed by a specific identity (the GitHub Actions workflow defined in the policy). The image from registry.example.com/myapp:v1 was signed by a different workflow, so the signer identity does not match the policy's required identity. Sigstore keyless signing verifies the OIDC identity embedded in the signature, and if the identity does not match the policy's `issuer` and `subject` patterns, the admission controller denies the pod.

Exam trap

CNCF often tests the misconception that keyless signing only verifies the signature's cryptographic validity, not the identity of the signer, but in reality the policy enforces identity matching via OIDC claims.

How to eliminate wrong answers

Option A is wrong because keyless signing does enforce identity matching via OIDC tokens; the policy specifies allowed identities, and mismatches cause denial. Option B is wrong because the policy uses a regex `v*` which matches any tag starting with 'v', and 'v1' matches that pattern, so the policy applies. Option C is wrong because the policy restricts based on signer identity, not just registry; the image is from an allowed registry but the signer identity does not match, so admission is denied.

Full explanation →

595

Drag & Dropmedium

Arrange the steps to enable and configure audit logging in Kubernetes.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Audit logging requires a policy file, mounting it, adding flags, restarting, and verifying logs.

Full explanation →

596

MCQmedium

You need to preserve evidence (container logs) from a compromised pod before deleting it. Which command should you run first?

A.kubectl exec <pod> -- cat /var/log/*

B.kubectl cp <pod>:/var/log ./pod-logs

C.kubectl logs <pod> --tail=-1 > pod.log

D.kubectl delete pod <pod>

AnswerC

Capturing the full log stream before deletion preserves volatile evidence that vanishes with the pod. The --tail=-1 flag retrieves every retained line rather than the default last ten, satisfying the requirement to secure container logs prior to removing the compromised workload.

Why this answer

`kubectl logs --tail=-1` retrieves the complete log history (all lines) from the container's stdout/stderr stream, which is the primary source of container logs in Kubernetes. Redirecting this output to a file preserves the evidence before the pod is deleted, ensuring the logs are not lost when the pod is removed.

Exam trap

The CKS exam often tests the misconception that `kubectl cp` or `kubectl exec` can reliably retrieve container logs, but in Kubernetes, stdout/stderr logs are not stored as regular files inside the container's filesystem, so only `kubectl logs` can capture them before pod deletion.

How to eliminate wrong answers

Option A is wrong because `kubectl exec` runs a command inside the container, which may alter the container's state or trigger additional logging, and `/var/log/*` may not contain container stdout/stderr logs (which are typically written to a log file managed by the container runtime, not directly accessible via exec). Option B is wrong because `kubectl cp` copies files from the pod's filesystem, but container logs from stdout/stderr are not stored as regular files in the pod; they are streamed to the container runtime and may not be available for copying, especially if the pod is in a crash loop or the log file is rotated. Option D is wrong because deleting the pod first destroys all evidence, including logs, before any preservation can occur.

Full explanation →

597

Multi-Selectmedium

Which TWO of the following are recommended practices for etcd security?

Select 2 answers

A.Use anonymous authentication for etcd

B.Disable TLS for performance

C.Restrict etcd access to only the API server and kubelets using firewall rules

D.Expose etcd on a public IP for monitoring

E.Enable TLS client certificate authentication

AnswersC, E

Restricting etcd access to only the API server and kubelets using firewall rules is a foundational defense-in-depth measure because etcd stores the entire cluster state, including secrets and RBAC policies. Firewall rules, such as security groups or host-based iptables, should permit only the API server on the etcd client port (2379) and block all other hosts, reducing the attack surface even if a worker node is compromised. This complements mTLS by controlling which hosts can initiate connections, ensuring that only trusted components can interact with the data store.

Why this answer

Option C is correct because etcd stores all cluster state and secrets, so network access should be tightly restricted with firewall rules to only the components that legitimately need it—typically the API server (and kubelets in some topologies)—rather than being reachable by arbitrary hosts. Option E is correct because enabling TLS client certificate authentication ensures that only clients presenting a valid, trusted certificate can connect to etcd, providing mutual authentication and preventing unauthorized reads or writes to the datastore. The unmarked options do not belong: A is wrong because anonymous authentication would allow unauthenticated access to the cluster's most sensitive data, B is wrong because disabling TLS exposes etcd traffic to eavesdropping and tampering (and TLS overhead is not a valid reason to remove it), and D is wrong because exposing etcd on a public IP dramatically increases the attack surface and is never a recommended monitoring practice.

Exam trap

CNCF often tests the misconception that disabling TLS or exposing etcd is acceptable for monitoring or performance, when in reality etcd must always be isolated and encrypted to protect the cluster's root of trust.

Full explanation →

598

MCQmedium

You run 'kubectl auth can-i create pods --as=system:serviceaccount:default:sa1 -n default' and get 'no'. What does this mean?

A.The command is invalid because 'system:serviceaccount' is not a valid user

B.The service account 'sa1' does not exist

C.The service account 'sa1' does not have permission to create pods in the default namespace

D.The service account 'sa1' is not allowed to perform any actions

AnswerC

The 'no' from kubectl auth can-i is the API server's direct RBAC decision for the exact tuple (verb=create, resource=pods, namespace=default) when impersonating system:serviceaccount:default:sa1. This means no RoleBinding or ClusterRoleBinding grants that service account the create permission on pods in that namespace. It is a precise, scoped denial for that action alone.

Why this answer

The command 'kubectl auth can-i create pods --as=system:serviceaccount:default:sa1 -n default' impersonates the service account 'sa1' to check if it has RBAC permissions to create pods in the 'default' namespace. A response of 'no' means that the current RBAC bindings (Role/ClusterRole and RoleBinding/ClusterRoleBinding) do not grant the 'create' verb on 'pods' resources to that service account. This is a direct authorization check against the Kubernetes RBAC system, not an indication of the service account's existence or general capability.

Exam trap

Candidates may mistake the 'no' response as meaning the service account is missing or invalid, but 'kubectl auth can-i' does not verify existence; it only tests RBAC authorization rules.

How to eliminate wrong answers

Option A is wrong because 'system:serviceaccount:default:sa1' is a valid Kubernetes user identifier for a service account, and the 'kubectl auth can-i' command correctly supports impersonation of service accounts via the --as flag. Option B is wrong because the command does not verify the existence of the service account; it performs an RBAC authorization check based on the provided identity, and a 'no' response does not imply the service account is missing. Option D is wrong because the 'no' response only indicates lack of permission for the specific action (create pods in the default namespace), not that the service account is denied all actions; it may have other permissions.

Full explanation →

599

MCQmedium

During a CI/CD pipeline, you run 'trivy image myapp:latest' and get a high number of vulnerabilities. What is the BEST action to reduce the vulnerability count?

A.Increase CPU and memory limits for the container

B.Switch to a distroless base image

C.Sign the image with Cosign

D.Remove all environment variables from the Dockerfile

AnswerB

Switching to a distroless base image removes unnecessary components like shells, package managers, and other utilities, leaving only the runtime dependencies required to run the application. This significantly reduces the number of installed packages that could contain known vulnerabilities, directly shrinking the attack surface and the scanner's vulnerability count. Distroless images are an established best practice for minimizing software footprint, making this the correct remediation.

Why this answer

Distroless base images contain only the essential runtime dependencies (e.g., glibc, libssl) and exclude package managers, shells, and other utilities that are common sources of CVEs. By switching to a distroless image, you drastically reduce the attack surface and the number of packages that Trivy scans, directly lowering the vulnerability count without changing application code.

Exam trap

CKS often tests the misconception that operational changes (like resource limits or environment variable removal) can fix supply chain vulnerabilities, when the correct answer always involves reducing the software footprint or patching dependencies at the image build level.

How to eliminate wrong answers

Option A is wrong because increasing CPU and memory limits does not affect the software packages or libraries present in the container image; resource limits only control runtime behavior, not the vulnerability surface. Option C is wrong because signing an image with Cosign provides integrity and provenance verification but does not remove or patch any vulnerabilities within the image. Option D is wrong because removing environment variables from the Dockerfile reduces the risk of secret leakage but has no impact on the vulnerability count reported by Trivy, which scans filesystem packages and libraries.

Full explanation →

600

MCQhard

An administrator wants to enable Kubernetes audit logging with the following requirements: log all requests at the Metadata level, but log all responses at the Request level. Which audit policy configuration achieves this?

A.Set default level to Metadata and use a dynamic level based on request size

B.Use the --audit-log-maxbackup flag to adjust levels

C.Set default level to Metadata and use a rule with level: Request for specific resources

D.Use separate rules with 'stages: ["RequestReceived"]' level Metadata, and 'stages: ["ResponseComplete"]' level Request

AnswerD

Using stages explicitly lets you tailor logging per phase: placing level: Metadata for stages: ["RequestReceived"] captures lightweight metadata early, and level: Request for stages: ["ResponseComplete"] captures the full request body after processing. Since the first matching rule in the policy file wins, order these rules appropriately to avoid the default rule catching the RequestReceived stage. This is the correct way to achieve stage-specific audit levels.

Why this answer

Audit policies allow setting different levels for different stages. To meet the requirement of logging requests at Metadata level and responses at Request level, you need separate rules for each stage. Option D does this by using two rules: one with stages: ['RequestReceived'] and level: Metadata, and another with stages: ['ResponseComplete'] and level: Request.

This ensures that request events are logged at Metadata level and response events at Request level.

Full explanation →

Certified Kubernetes Security Specialist CKS (CKS) — Questions 526–600