Certified Kubernetes Security Specialist CKS CKS Questions 301–375 | Page 5/12

301

MCQmedium

What is the purpose of an SBOM (Software Bill of Materials) in the context of supply chain security?

A.To sign container images

B.To scan images for vulnerabilities

C.To provide a list of all software components and dependencies in an artifact

D.To enforce runtime security policies

AnswerC

An SBOM (Software Bill of Materials) is a formal, structured record that enumerates every software component, library, package, and dependency included in an artifact, along with metadata such as version numbers and often licenses. It provides a complete supply-chain inventory, making it possible to trace exactly which code is present and why it was included. This transparency is foundational for license compliance, security analysis, and incident response.

Why this answer

An SBOM is a formal, machine-readable inventory of all software components, libraries, and dependencies that make up an artifact such as a container image. Its purpose is to provide transparency into the supply chain so that when a new vulnerability is disclosed, you can quickly determine whether your artifact contains the affected component. It does not itself perform signing, scanning, or runtime enforcement.

Exam trap

The trap here is confusing the purpose of an SBOM with that of a vulnerability scanner or a signing tool; candidates often pick 'scan images for vulnerabilities' because SBOMs are used in vulnerability management, but the SBOM itself is only the inventory.

How to eliminate wrong answers

Option A is wrong because signing container images is done by tools like cosign or Notary, not by an SBOM; an SBOM is a list, not a signature. Option B is wrong because scanning images for vulnerabilities is performed by scanners like Trivy or Clair, which may consume an SBOM but the SBOM itself is not a scanner. Option D is wrong because runtime security policies are enforced by tools like Falco, AppArmor, or seccomp, not by an SBOM.

Full explanation →

302

MCQeasy

Which command loads an AppArmor profile from a file into the kernel?

A.apparmor_parser -r /path/to/profile

B.aa-enforce /path/to/profile

C.aa-status

D.modprobe apparmor

AnswerA

apparmor_parser is the userspace utility specifically designed to compile and load AppArmor profiles into the kernel's AppArmor LSM. The -r flag stands for 'replace', which is essential when re-loading an already loaded profile (e.g., after editing the policy file) because it overwrites the prior version atomically. Without -r, the command would fail with 'profile already loaded' if a profile with the same name exists. Thus, this is the only option that actually performs the load from a file.

Why this answer

The `apparmor_parser` command loads AppArmor profiles into the kernel. The `-r` flag replaces an existing profile with the one from the specified file, ensuring the kernel enforces the updated rules. This is the standard method to load or reload AppArmor profiles from a profile file.

Exam trap

CNCF often tests the distinction between loading a profile (`apparmor_parser`) and changing its mode (`aa-enforce` or `aa-complain`), causing candidates to confuse the command that loads the profile with the one that sets its enforcement state.

How to eliminate wrong answers

Option B is wrong because `aa-enforce` sets an already-loaded profile to enforce mode, but does not load a profile from a file into the kernel. Option C is wrong because `aa-status` only displays the current status of loaded AppArmor profiles and does not load any profiles. Option D is wrong because `modprobe apparmor` loads the AppArmor kernel module, not a specific profile; the module must already be loaded for profiles to be used.

Full explanation →

303

MCQeasy

You need to enable audit logging for the Kubernetes API server to capture all requests at the RequestResponse level. Which flag should you add to the kube-apiserver configuration?

A.--audit-webhook-config-file=/etc/kubernetes/audit-webhook.yaml

B.--audit-policy-file=/etc/kubernetes/audit-policy.yaml

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

D.--authorization-mode=RBAC

AnswerB

This is the correct flag because it supplies the audit policy YAML that filters and selects which user requests, stages, and response levels are logged by the kube-apiserver. The policy file contains rules with verbs, resources, and audit levels, and it is the mandatory component to enable any audit logging. All other flags, such as log or webhook backends, are secondary and depend on this policy being present.

Why this answer

The --audit-policy-file flag points the kube-apiserver to the YAML file that defines audit levels (None, Metadata, Request, RequestResponse) and rules for which requests to log. To capture requests at the RequestResponse level, you must define that level in the audit policy file and pass it via this flag. Without this flag, the API server has no audit policy and will not produce audit events.

Exam trap

CKS often tests the distinction between the audit policy file (which defines what and at what level to log) and the audit backend flags (which define where logs go), so candidates who confuse --audit-policy-file with --audit-log-path or --audit-webhook-config-file pick the wrong answer.

How to eliminate wrong answers

Option A is wrong because --audit-webhook-config-file only configures the webhook backend that receives audit events; it does not define what to log or at what level. Option C is wrong because --audit-log-path only sets the destination file for the log backend; it does not specify the audit level or rules. Option D is wrong because --authorization-mode controls RBAC/ABAC/Node authorization, not audit logging at all.

Full explanation →

304

MCQmedium

A developer is deploying a pod that needs to access a sensitive database. The security team requires that the database credentials be stored in a Kubernetes Secret and mounted as a file, not exposed as environment variables. The credentials must be rotated without restarting the pod. Which volume type should be used?

A.A secret volume mounted as a file.

B.A projected volume combining the Secret with a downward API volume.

C.A hostPath volume pointing to a file on the node that contains the credentials.

D.An emptyDir volume populated by an init container that reads the Secret.

AnswerA

A secret volume mounts the Secret as files in the container. Kubernetes automatically updates the mounted files when the Secret is updated, without requiring a pod restart. This satisfies both requirements: credentials are not exposed as environment variables, and rotation is handled dynamically. The application can watch the file for changes and reload credentials.

Why this answer

A secret volume mounts Secret data as files and is automatically updated when the Secret is modified, allowing credential rotation without pod restarts. Environment variables are static and require a restart to update. Other volume types either do not provide automatic updates or introduce security risks.

Exam trap

The trap here is assuming that a projected volume is needed for automatic updates, when a plain secret volume already provides that behavior.

Full explanation →

305

MCQeasy

You want to run crictl to list all running containers on a node. Which command should you execute?

A.crictl ps

B.crictl stats

C.crictl images

D.crictl pods

AnswerA

crictl ps is the correct CRI-compatible command to list running containers on a node. By default it shows only currently running containers, mirroring docker ps, and with -a it includes exited ones. It retrieves the container list from the CRI runtime socket (e.g., containerd, CRI-O) and displays fields such as container ID, image, created time, and status.

Why this answer

The crictl ps command lists running containers on a node by querying the CRI-compatible container runtime (containerd or CRI-O). It is the direct equivalent of 'docker ps' in the CRI world and is the correct command to enumerate running containers.

Exam trap

CKS often tests the confusion between crictl subcommands — candidates who pick crictl pods or crictl images forget that ps is the container-listing command, while pods lists sandboxes and images lists image layers.

How to eliminate wrong answers

Option B is wrong because crictl stats reports resource usage (CPU, memory) for containers, not a list of running containers. Option C is wrong because crictl images lists container images present on the node, not running containers. Option D is wrong because crictl pods lists pods (sandboxes) rather than the individual containers inside them — it answers a different question.

Full explanation →

306

MCQmedium

You are investigating a compromised pod. You suspect the attacker used 'kubectl exec' to gain shell access. Which command can you use to check the audit logs for exec events?

A.kubectl exec -it pod-name -- cat /var/log/audit/audit.log

B.kubectl get events

C.kubectl logs --audit

D.kubectl describe pod pod-name

AnswerB

Incorrect: kubectl get events shows Kubernetes Event objects, not API server audit logs, and does not display exec audit entries.

Why this answer

None of the listed commands can be used to check Kubernetes audit logs for exec events. Kubernetes audit logs are stored on control plane nodes, commonly at /var/log/kubernetes/audit/audit.log or in the configured audit backend, and are not exposed via 'kubectl get events', 'kubectl logs --audit', or 'kubectl describe pod'. 'kubectl exec' runs inside a container and cannot read control-plane audit files unless a hostPath mount is explicitly configured. To inspect exec audit events, access the control plane and use host-level tools such as 'grep exec /var/log/kubernetes/audit/audit.log' according to your audit log configuration.

Full explanation →

307

Multi-Selecthard

Which THREE of the following are recommended actions to secure the Kubernetes Dashboard? (Choose three.)

Select 3 answers

A.Use RBAC to create a dedicated service account with minimal permissions

B.Expose the Dashboard via an Ingress with a public domain

C.Enable HTTPS for Dashboard communications

D.Do not bind the Dashboard's service account to the cluster-admin role

E.Avoid exposing the Dashboard via a public LoadBalancer

AnswersA, D, E

Creating a dedicated service account for the Dashboard, rather than relying on the default account, lets you bind only the specific RBAC permissions the Dashboard actually needs, such as read-only access to certain namespaces. This implements least privilege, so even if the Dashboard or its token is compromised, the attacker cannot escalate to broader cluster resources. It also avoids the risk of the default service account carrying excessive or unintended permissions.

Why this answer

The Kubernetes Dashboard should be accessed using a dedicated service account with minimal permissions via RBAC. This follows the principle of least privilege, ensuring the dashboard only has the permissions necessary for its function, reducing the attack surface. By default, the dashboard's service account has minimal permissions, but binding it to a role with excessive privileges (like cluster-admin) would be a security risk.

Exam trap

CNCF often tests the distinction between actions that are recommended (like using RBAC with minimal permissions) versus actions that are explicitly discouraged (like binding to cluster-admin or exposing via public endpoints), and candidates may mistakenly think enabling HTTPS is a 'recommended action' in this context, but it is not listed among the three correct options here because the question focuses on access control and exposure, not encryption.

Full explanation →

308

MCQeasy

Which stage of the Kubernetes API request processing should be audited to capture the final response sent to the client?

A.ResponseStarted

B.Panic

C.ResponseComplete

D.RequestReceived

AnswerC

ResponseComplete is emitted only after the entire HTTP response has been sent to the client, meaning the audit event now carries the final status code, response size, and all processing results. This is the stage at which every phase of request handling—authentication, authorization, admission, and execution—has finished, making it the correct stage for auditing the complete outcome of a request. Without waiting for this stage, an audit log could miss failures or side effects that occur after the initial response begins.

Why this answer

The `ResponseComplete` stage in Kubernetes audit logging captures the moment when the complete HTTP response has been sent to the client. This stage includes the final response body, headers, and status code, providing a full record of what the client actually received. Auditing at this stage is essential for compliance and forensic analysis, as it logs the definitive outcome of the API request.

Exam trap

The CKS exam often tests the distinction between `ResponseStarted` and `ResponseComplete`, where candidates mistakenly choose `ResponseStarted` thinking it captures the response, but it only captures the start of the response transmission, not the final payload.

How to eliminate wrong answers

Option A is wrong because `ResponseStarted` captures the point when the response headers are sent but before the response body is fully transmitted, so it does not include the final response payload. Option B is wrong because `Panic` is a stage that logs when a panic occurs during request processing, not the normal completion of a response. Option D is wrong because `RequestReceived` logs the event when the request is first received by the API server, before any processing or response generation occurs.

Full explanation →

309

MCQmedium

A pod spec includes 'hostPID: true' and 'hostNetwork: true'. What security concern does this raise?

A.The container can use the host's GPU and other devices

B.The container can see all host processes and access the host network namespace, increasing the risk of privilege escalation

C.The container can read and write to the host filesystem

D.The container cannot use a securityContext

AnswerB

When hostPID is true, the container shares the host's PID namespace, allowing it to list and signal every process on the node; with hostNetwork true, it attaches to the host network namespace, so it can bind to host ports and observe host network traffic. This combination weakens isolation substantially: a compromised container could use ptrace (if permitted) or sniff network packets, increasing the chance of privilege escalation to the host. It also bypasses typical container network policies and process-level sandboxing.

Why this answer

Setting `hostPID: true` allows the container to see all processes running on the host, which can leak sensitive information and enable process injection. Setting `hostNetwork: true` gives the container direct access to the host's network namespace, bypassing network policies and potentially allowing the container to bind to privileged ports or sniff traffic. Together, these settings significantly increase the attack surface and risk of privilege escalation or host compromise.

Exam trap

CNCF often tests the distinction between namespace sharing (`hostPID`, `hostNetwork`, `hostIPC`) and volume mounts or device access; the trap here is that candidates confuse `hostNetwork` with host filesystem access or assume `hostPID` implies device access.

How to eliminate wrong answers

Option A is wrong because GPU and device access is controlled by `hostDevice` or resource limits, not by `hostPID` or `hostNetwork`. Option C is wrong because read/write access to the host filesystem requires a `hostPath` volume mount or `hostFilesystem` capability, not `hostPID` or `hostNetwork`. Option D is wrong because a pod with `hostPID: true` and `hostNetwork: true` can still use a `securityContext`; these settings are independent of the `securityContext` field.

Full explanation →

310

MCQmedium

A security policy requires that all container images must be signed using Cosign. Which admission controller enforces signature verification at pod creation time?

A.ImagePolicyWebhook

B.MutatingAdmissionWebhook

C.ValidatingAdmissionWebhook

D.ResourceQuota

AnswerA

ImagePolicyWebhook is the dedicated Kubernetes admission controller that evaluates container image policies at pod creation time. It is enabled via --enable-admission-plugins and reads an external webhook configuration file; for every Pod that references images, the API server sends an ImageReview request containing the image names, and the webhook returns an allowed/denied verdict with a reason. This integrates with external image verification services such as Sigstore/cosign or Notary to enforce signature checks, making it the built-in, purpose-specific mechanism for this requirement.

Why this answer

The ImagePolicyWebhook admission controller is the correct choice because it is specifically designed to enforce image signature verification at pod creation time. It intercepts pod creation requests and queries an external webhook (e.g., a Cosign-based policy engine) to validate that the container image has a valid cryptographic signature before allowing the pod to be admitted. This directly meets the requirement for Cosign-based signature enforcement.

Exam trap

The CKS exam often tests the distinction between generic webhooks (MutatingAdmissionWebhook, ValidatingAdmissionWebhook) and purpose-built admission controllers like ImagePolicyWebhook, leading candidates to incorrectly choose ValidatingAdmissionWebhook because they assume any validation can be done there, missing that ImagePolicyWebhook is the specific controller for image signature enforcement.

How to eliminate wrong answers

Option B is wrong because MutatingAdmissionWebhook modifies objects (e.g., injecting sidecars) but does not enforce image signature verification; it operates before validation but lacks the specific image policy checking logic. Option C is wrong because ValidatingAdmissionWebhook can validate arbitrary policies but is not purpose-built for image signature verification; it would require custom logic to replicate ImagePolicyWebhook's built-in image policy enforcement. Option D is wrong because ResourceQuota is a built-in admission controller that enforces resource limits (CPU, memory) and object counts, not image signature verification.

Full explanation →

311

MCQeasy

A Pod is being deployed with a securityContext that sets runAsUser: 1000 and runAsGroup: 3000. The container image's files are owned by root:root with permissions 755. The application needs to write to a directory /data that is mounted as an emptyDir volume. What will happen when the container attempts to write to /data?

A.The write will fail because emptyDir volumes are read-only by default.

B.The write will fail with a permission denied error because the emptyDir volume is owned by root and the container runs as user 1000.

C.The write will succeed because runAsUser and runAsGroup automatically change the ownership of mounted volumes.

D.The write will succeed because emptyDir volumes are always writable by any user.

AnswerB

By default, an emptyDir volume is created with ownership root:root and permissions 0755. Since the container process runs as user 1000 and group 3000, it lacks write permission on the volume root. Without a fsGroup setting to change ownership or permissions, the write will fail with a permission denied error.

Why this answer

An emptyDir volume is created with root:root ownership and 0755 permissions by default. The container runs as user 1000 and group 3000, which are not the owner and do not have write permission on the volume root. Unless a fsGroup is specified to change the group ownership and permissions, the write will fail with a permission denied error.

The other options incorrectly assume automatic writability or misattribute the cause.

Exam trap

The trap here is assuming that setting runAsUser and runAsGroup automatically adjusts volume permissions, when actually fsGroup is needed to change volume ownership.

Full explanation →

312

MCQmedium

A DevOps team deploys a microservice that needs to access a third-party API using credentials stored in a Kubernetes Secret. The team wants to minimize the risk of credential exposure. Which approach best achieves this goal while following security best practices?

A.Store the credentials in a Secret and mount it as a volume with default permissions.

B.Store the credentials in a Secret, mount it as a read-only volume, and use a dedicated service account with RBAC limiting access to that secret.

C.Use a sidecar container that reads the secret from a file and exposes it via a Unix socket, running the container as root.

D.Store the credentials in a ConfigMap and inject them as environment variables.

AnswerB

This approach is correct because it combines confidentiality, integrity, and least privilege: mounting the Secret as a read-only volume prevents containers from modifying the credentials at runtime, while a dedicated ServiceAccount paired with a Role and RoleBinding strictly limits which pods can get or list the Secret through the Kubernetes API. The RBAC policy ensures that only the microservice's own service account can access the Secret, reducing the risk of unauthorized retrieval by other workloads in the cluster.

Why this answer

Mounting the Secret as a read-only volume prevents runtime modification, and using a dedicated service account with RBAC ensures only the specific microservice can access the Secret. This follows the principle of least privilege and minimizes exposure, as the credentials are never injected as environment variables (which can be leaked via /proc or logs) and are only available to the intended pod.

Exam trap

CNCF often tests the misconception that environment variables are safe for secrets, but the trap here is that environment variables can be exposed via `/proc/self/environ`, logs, or debug endpoints, making volume mounts with strict permissions and RBAC the more secure choice.

How to eliminate wrong answers

Option A is wrong because mounting a Secret with default permissions (typically 0644) allows other processes on the node to read the secret files, increasing exposure risk. Option C is wrong because running the sidecar container as root violates the principle of least privilege and could allow privilege escalation; a Unix socket approach adds complexity without addressing the core credential exposure issue. Option D is wrong because ConfigMaps are not designed for sensitive data—they lack encryption at rest and are often stored in plaintext in etcd, making credentials vulnerable to exposure.

Full explanation →

313

MCQmedium

You need to sign a container image using cosign with a key stored in an environment variable. Which command should you use?

A.cosign sign myimage:latest --key cosign.pub

B.cosign sign --key env://COSIGN_PRIVATE_KEY myimage:latest

C.cosign sign --key $COSIGN_PRIVATE_KEY myimage:latest

D.cosign sign --key file://cosign.key myimage:latest

AnswerB

cosign sign --key env://COSIGN_PRIVATE_KEY myimage:latest is the correct syntax for supplying a private key from an environment variable. The env:// URI scheme tells cosign to interpret COSIGN_PRIVATE_KEY as the name of an environment variable whose value contains the actual key material, rather than as a file system path. This approach keeps the private key out of the filesystem and out of the visible command line, which is the intended method for in-memory key handling with cosign.

Why this answer

`cosign sign --key env://COSIGN_PRIVATE_KEY` instructs Cosign to read the private key from the environment variable named `COSIGN_PRIVATE_KEY` using the `env://` URI scheme. This is the standard way to reference a key stored in an environment variable, avoiding exposure on the command line or in files.

Exam trap

The CKS exam often tests the distinction between shell variable expansion (`$VAR`) and Cosign's native `env://` URI scheme, tricking candidates into thinking that simply passing the variable value as an argument is sufficient, when in fact the `env://` prefix is required for secure key retrieval.

How to eliminate wrong answers

Option A is wrong because `cosign.pub` is a public key file, but signing requires a private key, not a public key. Option C is wrong because `$COSIGN_PRIVATE_KEY` would expand the variable value directly on the command line, potentially exposing the key material in process listings or logs, and Cosign expects a URI scheme like `env://` to read from an environment variable. Option D is wrong because `file://cosign.key` uses a file URI scheme, but the question explicitly states the key is stored in an environment variable, not a file.

Full explanation →

314

MCQeasy

Which flag disables anonymous authentication on the API server?

A.--enable-admission-plugins=NodeRestriction

B.--authorization-mode=RBAC

C.--anonymous-auth=false

D.--client-ca-file=<path>

AnswerC

Setting --anonymous-auth=false on the kube-apiserver disables the default behavior that treats unauthenticated requests as belonging to the system:anonymous user and the system:unauthenticated group. With anonymous-auth disabled, any request that does not present a valid client certificate or other supported credentials is rejected with a 401 Unauthorized error before authorization is attempted. This is the direct flag designed for the exact purpose of preventing anonymous access to the API.

Why this answer

The `--anonymous-auth=false` flag explicitly disables anonymous authentication on the Kubernetes API server. When set to false, the API server will reject requests from unauthenticated users (those not presenting valid credentials), enforcing that all requests must be authenticated. This is a critical security hardening step to prevent anonymous access to the cluster's control plane.

Exam trap

The trap here is that candidates often confuse authentication with authorization, mistakenly selecting `--authorization-mode=RBAC` (Option B) thinking it controls who can access the API, when in fact RBAC only controls what authenticated users can do, not whether anonymous users are allowed.

How to eliminate wrong answers

Option A is wrong because `--enable-admission-plugins=NodeRestriction` enables the NodeRestriction admission controller, which limits the permissions of kubelet nodes but does not control anonymous authentication. Option B is wrong because `--authorization-mode=RBAC` sets the authorization mode to Role-Based Access Control, which governs what authenticated users can do, not whether unauthenticated users can connect. Option D is wrong because `--client-ca-file=<path>` specifies the CA certificate used to validate client certificates for TLS-based authentication, but it does not disable anonymous authentication; anonymous requests are still allowed unless explicitly denied.

Full explanation →

315

Multi-Selectmedium

Which TWO of the following are valid Pod Security Context settings to harden a container? (Select 2)

Select 2 answers

A.privileged: true

B.runAsUser: 0

C.runAsNonRoot: true

D.readOnlyRootFilesystem: true

E.allowPrivilegeEscalation: true

AnswersC, D

Setting `runAsNonRoot: true` enforces that the container process runs as a non-root user by rejecting the image's default user if it is root. This prevents the container from gaining root privileges inside the container, reducing the attack surface. It is a valuable security context setting recommended in Pod Security Standards.

Why this answer

Setting `runAsNonRoot: true` in the Pod Security Context forces the container to run with a user ID (UID) other than 0 (root). This is a fundamental hardening measure that prevents an attacker who gains code execution inside the container from having root privileges, thereby limiting the blast radius of a compromise. It is a recommended practice in the CIS Benchmark for Kubernetes and directly addresses the principle of least privilege.

Exam trap

A common misconception is that setting `runAsUser: 0` is a hardening measure because it 'specifies a user,' when in fact it sets the container to run as root, the most dangerous user.

Full explanation →

316

Multi-Selecthard

Which THREE of the following are valid approaches to enforce that all pods in a cluster run with a read-only root filesystem? (Select THREE)

Select 3 answers

A.Deploy a ValidatingWebhookConfiguration that checks for readOnlyRootFilesystem: true

B.Use a Gatekeeper policy to drop all capabilities

C.Enable Pod Security Admission (PSA) with the 'restricted' profile

D.Deploy a MutatingWebhookConfiguration that adds readOnlyRootFilesystem: true to all pods

E.Apply a NetworkPolicy that denies egress

AnswersA, C, D

A ValidatingWebhookConfiguration intercepts Pod create and update requests and can reject any pod that does not explicitly set readOnlyRootFilesystem: true in its container securityContext. This is a valid enforcement approach because the webhook runs as part of the admission chain and denies non-compliant resources before they are persisted in etcd, ensuring workloads never run with a writable root filesystem.

Why this answer

Option A is correct because a ValidatingWebhookConfiguration can intercept pod CREATE/UPDATE admission requests and reject any pod whose containers do not set securityContext.readOnlyRootFilesystem: true, thereby enforcing the requirement cluster-wide. Option C is correct because the Pod Security Admission 'restricted' profile mandates that every container sets securityContext.readOnlyRootFilesystem to true (among other hardening controls), so labeling namespaces with pod-security.kubernetes.io/enforce=restricted blocks non-compliant pods. Option D is correct because a MutatingWebhookConfiguration can patch incoming pod specs to inject readOnlyRootFilesystem: true into each container's securityContext, ensuring all admitted pods run with a read-only root filesystem.

Option B is not correct because a Gatekeeper policy that drops all capabilities addresses Linux capabilities, not the read-only root filesystem setting. Option E is not correct because a NetworkPolicy only controls pod ingress/egress traffic and has no effect on container filesystem mutability.

Exam trap

Candidates often confuse dropping capabilities with making the root filesystem read-only. Dropping capabilities limits kernel privileges but does not prevent writes to the filesystem; they are separate security contexts.

Full explanation →

317

MCQhard

A security team suspects a compromised pod is making unexpected outbound connections to an external IP. Which of the following is the BEST first step to investigate the network traffic from that pod?

A.Deploy Falco with a rule to detect outbound connections

B.Create a NetworkPolicy to deny all egress traffic

C.Run 'kubectl exec <pod> -- tcpdump -i eth0' to capture packets

D.Check the pod's logs using 'kubectl logs <pod>'

AnswerC

Running 'kubectl exec <pod> -- tcpdump -i eth0' is the correct immediate investigation step because it captures raw network packets directly from the pod's network interface, revealing destination IPs, ports, protocols, and payloads of ongoing communication. This live capture provides the forensic evidence needed to understand the attacker's command-and-control traffic or data exfiltration in real time. However, tcpdump must be installed in the container image and the container must have the necessary privileges, such as CAP_NET_RAW or root access, which may require using an ephemeral container if the tools are missing.

Why this answer

The best first step to investigate unexpected outbound connections from a pod is to capture live network traffic from within the pod using tcpdump. This provides immediate visibility into the actual packets being sent, including destination IPs, ports, and payloads, which is essential for confirming the compromise and identifying the external endpoint. Other options are either reactive (blocking) or less direct.

Exam trap

CKS often tests the difference between detection, mitigation, and investigation; candidates may choose Falco or NetworkPolicy as a first step, but the question asks for the best first step to investigate, which is traffic capture.

How to eliminate wrong answers

Option A is wrong because deploying Falco with a rule is a detection mechanism that may take time to set up and may not capture existing traffic; it is not the immediate first step for investigation. Option B is wrong because creating a NetworkPolicy to deny all egress traffic is a mitigation step that would stop the traffic but also destroy evidence and potentially disrupt the investigation; it is not an investigative first step. Option D is wrong because checking pod logs may not show network-level details and the compromised process may not log its outbound connections; logs are application-specific and may be insufficient.

Full explanation →

318

MCQmedium

You need to enable encryption at rest for secrets in the cluster. Which resource should you create to configure encryption providers?

A.EncryptionConfiguration

B.EncryptionProviderConfig

C.EncryptionPolicy

D.SecretEncryptionConfig

AnswerA

EncryptionConfiguration is the correct Kubernetes API resource (apiserver.config.k8s.io/v1) used to define encryption providers for etcd data at rest. It is passed to the kube-apiserver via the --encryption-provider-config flag, and its structure allows specifying providers such as aescbc, secretbox, or KMS-backed implementations, along with keys and ordering. This resource is the only recognized way to enable encryption at rest for Secrets, making it the valid choice.

Why this answer

To enable encryption at rest for Kubernetes secrets, you must create an EncryptionConfiguration resource. This object defines which encryption providers (e.g., aesgcm, aescbc, secretbox, or identity) should be used to encrypt secrets stored in etcd. The API server reads this configuration from a file specified via the --encryption-provider-config flag, allowing you to control encryption at the provider level.

Exam trap

CNCF often tests the exact name of the Kubernetes resource, and candidates confuse EncryptionConfiguration with similar-sounding but nonexistent names like EncryptionProviderConfig or EncryptionPolicy, which are not part of the Kubernetes API.

How to eliminate wrong answers

Option B is wrong because EncryptionProviderConfig is not a valid Kubernetes resource; the correct resource name is EncryptionConfiguration. Option C is wrong because EncryptionPolicy is a generic term and not a specific Kubernetes API object used for configuring encryption providers. Option D is wrong because SecretEncryptionConfig does not exist as a Kubernetes resource; the configuration applies to all secrets cluster-wide via EncryptionConfiguration.

Full explanation →

319

MCQeasy

What does SBOM stand for in the context of supply chain security?

A.Software Bill of Materials

B.Systematic Bug and Oversight Manager

C.Secure Build Orchestration Manager

D.Source Binary Object Model

AnswerA

SBOM stands for Software Bill of Materials, a formal, machine-readable inventory of all components, libraries, and dependencies in a software artifact. It enables organizations to track vulnerabilities, license compliance, and supply chain risk by knowing exactly what is inside their code. Standards like SPDX and CycloneDX define its format, and it is essential for responding to incidents like Log4Shell quickly.

Why this answer

SBOM stands for Software Bill of Materials. It is a formal, machine-readable inventory of all components, libraries, and dependencies used to build a software artifact. In supply chain security, an SBOM enables organizations to quickly identify and remediate vulnerabilities (e.g., Log4Shell) by tracking which versions of open-source or third-party components are included in a release.

Exam trap

The CKS exam often tests the exact acronym expansion to catch candidates who confuse SBOM with unrelated security terms like 'SBOM' being mistaken for a management tool or a model, rather than a simple inventory list.

How to eliminate wrong answers

Option B is wrong because 'Systematic Bug and Oversight Manager' is a fabricated term; there is no such standard concept in supply chain security or Kubernetes. Option C is wrong because 'Secure Build Orchestration Manager' is not a recognized acronym; while build orchestration tools exist (e.g., Tekton), they are not referred to as SBOM. Option D is wrong because 'Source Binary Object Model' is a misnomer; SBOM specifically refers to a bill of materials for software, not a model for source or binary objects.

Full explanation →

320

Multi-Selectmedium

Which TWO of the following are recommended practices for securing the Kubernetes Dashboard? (Select TWO)

Select 2 answers

A.Use HTTP instead of HTTPS for Dashboard traffic

B.Disable authentication for the Dashboard

C.Restrict Dashboard access using RBAC with minimal privileges

D.Use the default cluster-admin ServiceAccount for Dashboard access

E.Avoid exposing the Dashboard on a public IP address

AnswersC, E

Rather than giving the Dashboard blanket cluster-admin powers, you should create a dedicated service account or user with only the permissions needed to perform the intended monitoring or management tasks. Kubernetes RBAC allows you to bind roles to an identity with specific verbs (get, list, watch) and resources, so you can limit the blast radius if the Dashboard is compromised. For example, you can restrict a user to read-only access in a single namespace by binding a Role to a ServiceAccount and using that token for Dashboard login. This follows the principle of least privilege, ensuring that a leaked token cannot be used to modify cluster-wide state.

Why this answer

The Kubernetes Dashboard should be secured using Role-Based Access Control (RBAC) with minimal privileges. This follows the principle of least privilege, ensuring that users or service accounts accessing the Dashboard have only the permissions necessary for their tasks, reducing the attack surface and potential blast radius in case of compromise.

Exam trap

CNCF often tests the misconception that disabling authentication or using HTTP simplifies setup, but the trap here is that these practices completely bypass security controls, while candidates may overlook that RBAC with minimal privileges is the correct hardening step.

Full explanation →

321

MCQhard

You are writing a Falco rule to detect when a container tries to read the file `/etc/shadow`. Which condition in the Falco rule correctly matches this event?

A.container.name=shadow and evt.type=open

B.evt.type=read and fd.name=/etc/shadow

C.proc.name=cat and fd.name=/etc/shadow

D.evt.type=open and fd.name=/etc/shadow

AnswerD

The `open` syscall is the initial operation that must occur before any file content can be read or modified; when a process calls `open` on `/etc/shadow`, Falco's `fd.name` is populated directly from the path argument, making this condition both reliable and comprehensive. This rule detects any attempt to open the shadow file, regardless of the intended operation (read, write, or execute) and regardless of the process name or container name. It is the precise, minimal condition that catches unauthorized access to sensitive credential files, and it is the standard cornerstone for such Falco rules.

Why this answer

Falco rules use conditions that match system calls (evt.type) and file descriptors (fd.name). The event type 'open' is the syscall used to open a file for reading, and fd.name='/etc/shadow' specifies the target file. This combination correctly detects when a container attempts to open /etc/shadow, which is the typical first step before reading it.

Exam trap

The CKS exam often tests the misconception that 'evt.type=read' is the correct syscall for detecting file reads, but the trap is that 'read' operates on an already-opened file descriptor, while 'open' is the syscall that reveals the file path being accessed.

How to eliminate wrong answers

Option A is wrong because 'container.name=shadow' is not a valid field; Falco uses 'container.name' but the value 'shadow' is not a container name, and 'evt.type=open' alone is insufficient without specifying the file. Option B is wrong because 'evt.type=read' is the syscall for reading from an already-open file descriptor, but the initial detection of file access should target the 'open' syscall, and 'fd.name' is not directly available in a read event without prior open context. Option C is wrong because 'proc.name=cat' is too specific to the 'cat' command; the rule should detect any process attempting to read /etc/shadow, not just 'cat'.

Full explanation →

322

MCQmedium

An administrator wants to ensure that a Deployment uses a specific image digest (SHA256) instead of a tag. Which field in the Deployment YAML should be modified?

A.spec.replicas

B.spec.template.spec.containers[].imagePullPolicy

C.spec.template.spec.containers[].image

D.spec.template.metadata.annotations

AnswerC

The spec.template.spec.containers[].image field accepts a full image reference, and using a digest (e.g., 'image@sha256:...') makes the reference immutable and content-addressed. Unlike tags, a digest uniquely identifies the exact image manifest, ensuring every Pod from this Deployment runs the exact same container build. This is the correct way to constrain a Deployment to a specific image, overriding any mutable tag in the registry. It also prevents accidental or malicious tag overwrites from affecting the running workload.

Why this answer

The `image` field under `spec.template.spec.containers[]` is where you specify the container image, and to enforce immutable deployment, you replace the tag with the SHA256 digest (e.g., `nginx@sha256:abc123...`). This ensures the exact image content is used, preventing tag mutation or accidental updates.

Exam trap

Kubernetes often tests the distinction between image reference (`image` field) and image pull behavior (`imagePullPolicy`), trapping candidates who confuse 'how to pull' with 'what to pull'.

How to eliminate wrong answers

Option A is wrong because `spec.replicas` controls the number of pod replicas, not the image reference. Option B is wrong because `imagePullPolicy` determines when to pull the image (e.g., Always, IfNotPresent, Never) but does not specify the image digest. Option D is wrong because `spec.template.metadata.annotations` are arbitrary key-value metadata for pods, not used for image identification.

Full explanation →

323

MCQhard

An organization wants to implement supply chain security by signing all container images and verifying them before deployment. Which combination of tools is appropriate?

A.Snyk and OPA

B.Cosign and Kyverno

C.Trivy and Syft

D.Clair and Notary

AnswerB

Cosign signs and verifies container image signatures using keyless or key-based attestations, while Kyverno's admission policies enforce that only signed images deploy. Together they satisfy the requirement to sign all images and verify them before deployment, blocking unsigned workloads at admission time.

Why this answer

Cosign is the tool for signing container images and storing signatures in an OCI-compliant registry, while Kyverno is a Kubernetes admission controller that can enforce policies to verify those signatures before allowing pod deployment. Together, they implement the full supply chain security workflow: signing images at build time and verifying them at deploy time via Kyverno's `verifyImages` rule.

Exam trap

The exam often tests the distinction between vulnerability scanning tools (Snyk, Trivy, Clair) and supply chain signing/verification tools (Cosign, Notary), leading candidates to confuse scanning for vulnerabilities with cryptographic signing and policy enforcement.

How to eliminate wrong answers

Option A is wrong because Snyk is a vulnerability scanner for dependencies and container images, not a signing tool, and OPA (Open Policy Agent) is a general-purpose policy engine that lacks native support for image signature verification without custom Rego rules. Option C is wrong because Trivy is a vulnerability scanner and Syft is a software bill of materials (SBOM) generator; neither tool provides image signing or signature verification capabilities. Option D is wrong because Clair is a vulnerability scanner for container images, and Notary is a tool for signing and verifying content trust in Docker images but is deprecated in favor of Cosign and is not integrated with Kubernetes admission controllers like Kyverno.

Full explanation →

324

MCQmedium

An administrator wants to secure etcd communication. Which of the following is required to enable TLS for client-to-etcd communication?

A.Set ETCD_TLS_ENABLE=true environment variable

B.--cert-file=<cert-file> and --key-file=<key-file>

C.--client-cert-auth=true and --trusted-ca-file=<CA-file>

D.--tls-cert-file and --tls-key-file

AnswerB

--cert-file and --key-file are the core etcd flags that enable TLS for incoming client connections by providing the server's certificate and private key. When these are set, etcd serves HTTPS on its client endpoint, protecting secrets stored in the cluster from eavesdropping. Note that these flags alone do not require client certificates; that is handled separately with --client-cert-auth and --trusted-ca-file.

Why this answer

To enable TLS for client-to-etcd communication, the etcd server must present a certificate to clients. The `--cert-file` and `--key-file` flags specify the server's TLS certificate and private key, which are required for the TLS handshake. Without these, etcd cannot serve HTTPS to clients.

Exam trap

The trap here is that candidates confuse the flags for enabling TLS (`--cert-file`/`--key-file`) with the flags for enabling client certificate authentication (`--client-cert-auth`/`--trusted-ca-file`), or they misremember the exact flag names as `--tls-cert-file`/`--tls-key-file` which do not exist in etcd.

How to eliminate wrong answers

Option A is wrong because `ETCD_TLS_ENABLE` is not a valid environment variable; etcd uses command-line flags, not environment variables, for TLS configuration. Option C is wrong because `--client-cert-auth=true` and `--trusted-ca-file` enable mutual TLS (client certificate authentication), which is optional and not required for basic TLS encryption. Option D is wrong because the correct flag names are `--cert-file` and `--key-file`, not `--tls-cert-file` and `--tls-key-file`; the latter are not recognized by etcd.

Full explanation →

325

MCQmedium

Which static analysis tool is specifically designed to evaluate Kubernetes manifests against security best practices?

A.cosign

B.syft

C.kubesec

D.clair

AnswerC

Kubesec analyses Kubernetes manifests directly, scoring workloads against security controls such as privileged containers, host namespaces, and capability escalation. It satisfies the stem's constraint of evaluating manifests against best practices, unlike runtime tools or general linters. Its risk-scoring output pinpoints misconfigurations before deployment.

Why this answer

kubesec is a static analysis tool specifically designed to scan Kubernetes manifests and identify security risks, such as running containers as root, missing resource limits, or privileged mode. It evaluates YAML files against a set of security best practices and assigns a risk score. This makes it the correct tool for evaluating Kubernetes manifests against security best practices.

Exam trap

CKS often tests the distinction between tools that scan images (clair, trivy, syft) and tools that scan manifests (kubesec, kube-score, checkov), so candidates must match the tool to the artifact being analyzed.

How to eliminate wrong answers

Option A is wrong because cosign is a tool for signing and verifying container images, not for analyzing Kubernetes manifests. Option B is wrong because syft is a Software Bill of Materials (SBOM) generation tool that inventories container images and filesystems, not a manifest security analyzer. Option D is wrong because clair is a vulnerability scanner for container images, focusing on known CVEs in packages, not on Kubernetes manifest security configurations.

Full explanation →

326

Multi-Selectmedium

Which TWO of the following are valid Rego keywords used in OPA policies for Gatekeeper? (Select TWO)

Select 2 answers

A.violation

B.allow

C.input

D.data

E.deny

AnswersC, D

`input` is a reserved Rego symbol that refers to the complete input document passed to the query, e.g., an admission review request in Kubernetes. It is the root for all input data, accessed like `input.request.userInfo`. Because it is defined by the language as the root of the query input, it cannot be used as a regular rule name. That makes it a valid Rego keyword, parallel to `data`.

Why this answer

In Rego, `input` and `data` are reserved keywords. `input` refers to the incoming document (e.g., the admission review request in Gatekeeper), and `data` refers to the global data document containing external data. `deny` is not a keyword but a common rule name used to trigger denial; `violation` and `allow` are also custom rule names. Therefore, the correct answer is options C and D.

Exam trap

Gatekeeper often tests the distinction between Rego language keywords (like `input` and `data`) and common rule names (like `violation`, `allow`, `deny`) that are not part of the language specification. Candidates mistakenly treat custom rule names as keywords.

Full explanation →

327

MCQmedium

You run kube-bench on a node and it reports a failure for 'Ensure that the --anonymous-auth argument is set to false' for the kubelet service. Which file must you modify to fix this?

A./etc/kubernetes/manifests/kube-apiserver.yaml

B./etc/kubernetes/pki/ca.crt

C./etc/kubernetes/kubelet.conf

D./var/lib/kubelet/config.yaml

AnswerD

This is the kubelet's primary configuration file, where API server client settings, TLS options, and authentication policies are defined under well-known keys. To fix the kube-bench failure, the setting 'authentication.anonymous.enabled' must be set to 'false' in this YAML file, which disables anonymous access to the kubelet's web endpoints. This file is loaded via the kubelet's --config flag and is the standard, sources-of-truth location for kubelet behavior in modern Kubernetes distributions.

Why this answer

Kube-bench checks the kubelet configuration for the `--anonymous-auth` flag, which is set in the kubelet's configuration file. By default, the kubelet reads its configuration from `/var/lib/kubelet/config.yaml` (or a path specified by `--config` in the kubelet service). Setting `anonymous-auth: false` in this file disables anonymous requests to the kubelet API, enforcing authentication.

Exam trap

The trap here is that candidates confuse the kubelet's configuration file with the kubelet's kubeconfig file (`kubelet.conf`) or the API server manifest, because all three are involved in authentication but serve different roles.

How to eliminate wrong answers

Option A is wrong because `/etc/kubernetes/manifests/kube-apiserver.yaml` is the static pod manifest for the API server, not the kubelet; the `--anonymous-auth` flag for the kubelet is not configured there. Option B is wrong because `/etc/kubernetes/pki/ca.crt` is the CA certificate file used for TLS verification, not a configuration file for kubelet authentication settings. Option C is wrong because `/etc/kubernetes/kubelet.conf` is a kubeconfig file used by the kubelet to authenticate to the API server, not the file where kubelet server-side authentication options like `--anonymous-auth` are set.

Full explanation →

328

MCQhard

A security auditor recommends enabling audit logging for the Kubernetes API server with a policy that logs all requests at the Metadata level. Which configuration ensures this requirement?

A.Enable the 'Audit' admission plugin

B.Set --audit-log-level=Metadata

C.Use --audit-log-maxage=30 to retain logs

D.Create an audit policy file with 'level: Metadata' for all resources and pass it via --audit-policy-file

AnswerD

Enabling audit logging requires creating an audit policy file that defines rules and levels — for example, setting 'level: Metadata' for all resources — and passing that file to the kube-apiserver via the --audit-policy-file flag. The Metadata level logs the request metadata (user, resource, verb, source IP) without bodies, which matches the auditor's intent while minimizing volume. This is the standard, supported way to turn on audit logging in Kubernetes.

Why this answer

Kubernetes audit logging requires an audit policy file that defines the log level for different request stages and resources. The requirement to log all requests at the Metadata level is achieved by creating a policy file with `level: Metadata` for all resources (or a catch-all rule) and passing it to the API server via the `--audit-policy-file` flag. The audit policy file is the only mechanism to specify the log level (None, Metadata, Request, RequestResponse) per resource or stage.

Exam trap

The trap here is that candidates confuse the audit policy file's `level` field with a command-line flag like `--audit-log-level`, which does not exist, leading them to select option B instead of understanding that the level is defined in the policy file.

How to eliminate wrong answers

Option A is wrong because the 'Audit' admission plugin does not exist; Kubernetes uses an audit backend (e.g., log backend) configured via flags, not an admission plugin. Option B is wrong because `--audit-log-level` is not a valid flag; the log level is defined inside the audit policy file, not as a command-line argument. Option C is wrong because `--audit-log-maxage` controls log rotation (days to retain old log files) but does not enable or configure the audit logging level or policy.

Full explanation →

329

MCQhard

You want to run a container with gVisor for sandboxing. After installing gVisor and creating a RuntimeClass named 'gvisor', which Pod configuration enables it?

A.Set spec.runtimeClassName: gvisor

B.Set spec.nodeSelector with 'gvisor: true'

C.Define an environment variable RUNTIME=gvisor in the container

D.Add an annotation 'container.runtime: gvisor' to the Pod

AnswerA

The Pod spec includes a runtimeClassName field that references a cluster-scoped RuntimeClass resource, which declares the handler (for gVisor, typically runsc) and may also include scheduling and overhead settings. When this field is set, the kubelet uses that handler to create the sandbox and containers, making it the only native, supported mechanism for per-Pod runtime selection. Without it, the default runtime such as runc is used, even if gVisor is installed on the node.

Why this answer

The `spec.runtimeClassName` field in a Pod spec is the standard Kubernetes mechanism to select a specific container runtime for that Pod. When a RuntimeClass named 'gvisor' is created, setting `spec.runtimeClassName: gvisor` instructs the kubelet to use the gVisor runtime (runsc) to run the Pod's containers, providing an additional sandboxing layer for security.

Exam trap

The trap is that candidates may mistakenly think that nodeSelector, environment variables, or annotations can select a runtime, but only spec.runtimeClassName directly references a RuntimeClass object. For gVisor, a CNCF sandbox project, the RuntimeClass must be created separately, and the Pod simply references it by name.

How to eliminate wrong answers

Option B is wrong because `spec.nodeSelector` is used to constrain which nodes a Pod can be scheduled on based on node labels, not to select a container runtime. Option C is wrong because environment variables have no effect on container runtime selection; they are passed to the container's process but do not influence the runtime used by the kubelet. Option D is wrong because annotations are metadata key-value pairs that do not affect runtime behavior; Kubernetes does not interpret an annotation like 'container.runtime: gvisor' to select a runtime.

Full explanation →

330

MCQhard

A cluster has been compromised due to a container running with privileged escalation. The team wants to prevent any container from gaining new privileges. Which configuration should be applied?

A.Set securityContext.runAsUser: 1000

B.Set securityContext.readOnlyRootFilesystem: true

C.Drop all capabilities with securityContext.capabilities.drop: ["ALL"]

D.Set securityContext.allowPrivilegeEscalation: false

AnswerD

Setting allowPrivilegeEscalation: false directly applies the Linux 'no_new_privs' flag to the container process, which prevents the process and its children from ever gaining more privileges than their original execution context, even if a later exec of a setuid-root or capability-enabled binary occurs. This is a kernel-level mechanism that blocks the common privilege-escalation vectors such as SUID binaries, file capabilities, and certain ioctl-based operations. It is the most direct security control among the options because it explicitly targets the privilege-escalation mechanism itself, rather than only constraining the user ID, filesystem, or capabilities. For this compromised container, this setting is necessary to contain the breach and prevent further elevation.

Why this answer

Setting `securityContext.allowPrivilegeEscalation: false` directly prevents a container from gaining new privileges beyond those it was initially granted, such as through setuid binaries or the `NO_NEW_PRIVS` flag. This is the exact control needed to block privilege escalation attacks, as it forces the kernel to deny any request for elevated privileges, even if the binary has the setuid bit set.

Exam trap

CNCF often tests the misconception that dropping all capabilities is sufficient to prevent privilege escalation, but the trap is that capabilities and privilege escalation are separate controls—`allowPrivilegeEscalation: false` is the specific setting to block setuid-based escalation.

How to eliminate wrong answers

Option A is wrong because setting `runAsUser: 1000` only specifies the user ID under which the container runs, but it does not prevent the container from escalating privileges (e.g., via a setuid binary owned by root). Option B is wrong because `readOnlyRootFilesystem: true` only makes the container's root filesystem read-only, which protects against writes but has no effect on privilege escalation mechanisms. Option C is wrong because dropping all capabilities with `capabilities.drop: ["ALL"]` removes Linux capabilities but does not disable the ability to gain new privileges through setuid binaries or other mechanisms; `allowPrivilegeEscalation: false` is required to block that path.

Full explanation →

331

MCQmedium

An administrator runs 'falco --list' and sees many default rules. What is the correct way to load a custom Falco rules file?

A.falco --load /path/to/rules.yaml

B.falco --rules /path/to/rules.yaml

C.falco -r /path/to/rules.yaml

D.falco --config /path/to/rules.yaml

AnswerC

This is the correct and dedicated Falco CLI flag for specifying one or more rules files (`-r /path/to/rules.yaml`). It tells Falco to load the provided YAML rule file in addition to or instead of the default rules, depending on how it is used. Running the command with `-r` will make Falco read the custom rules and apply them to the event stream.

Why this answer

The `-r` flag (short for `--rules`) is the standard Falco command-line option to specify a custom rules file. When you run `falco -r /path/to/rules.yaml`, Falco loads the rules from that YAML file instead of or in addition to the default rules. The `--list` flag shows all loaded rules, so using `-r` ensures your custom rules are included in that list.

Exam trap

The trap here is that candidates confuse `--rules` (which is not a valid flag) with `-r` (the correct short form), or they mistakenly think `--load` or `--config` are valid ways to load rules, when in fact `--config` is for the main Falco configuration file and `--load` does not exist.

How to eliminate wrong answers

Option A is wrong because `--load` is not a valid Falco flag; Falco does not support a `--load` option for rules files. Option B is wrong because `--rules` is the long form of `-r`, but the syntax `--rules /path/to/rules.yaml` is incorrect—the correct long form is `--rules-file /path/to/rules.yaml` (though `-r` is the standard short form). Option D is wrong because `--config` is used to specify the Falco configuration file (e.g., `falco.yaml`), not a rules file; rules and configuration are separate concerns.

Full explanation →

332

Multi-Selecthard

A security engineer is hardening a cluster and wants to reduce the attack surface of Pods by restricting their access to host resources. The engineer is reviewing a Pod specification and plans to remove or disable settings that grant host-level access. Which two settings should the engineer remove or set to false to reduce the attack surface? (Choose two.)

Select 2 answers

A.allowPrivilegeEscalation: true

B.readOnlyRootFilesystem: false

C.hostPID: true

D.hostNetwork: true

E.privileged: false

AnswersC, D

Setting hostPID to true places the Pod in the host's PID namespace, allowing it to see and potentially signal all processes on the node. Removing this setting or setting it to false isolates the Pod's process namespace, preventing it from viewing or interacting with host processes. This significantly reduces the attack surface.

Why this answer

The hostNetwork and hostPID fields, when set to true, place the Pod in the host's network and PID namespaces respectively, giving it direct access to host resources and significantly increasing the attack surface. Removing or setting these to false isolates the Pod. The other options either represent secure settings that are already in place or address different security concerns not directly related to host resource access.

Exam trap

The trap here is focusing on privilege escalation or filesystem writability instead of the host namespace flags that actually grant host resource access.

Full explanation →

333

MCQeasy

Which static analysis tool can be used to check Kubernetes manifests for security misconfigurations?

A.kubesec

B.kubectl apply

C.trivy image

D.helm template

AnswerA

Kubesec statically scans Kubernetes manifests and returns a security score, flagging misconfigurations such as privileged containers, host namespaces and missing security contexts before deployment. It satisfies the stem's requirement for a static analysis tool by evaluating YAML definitions directly, without needing a running cluster or admission controller.

Why this answer

Kubesec is a static analysis tool specifically designed to evaluate Kubernetes YAML manifests against a set of security best practices, such as ensuring containers run as non-root, enforcing read-only root filesystems, and dropping unnecessary Linux capabilities. It outputs a risk score and highlights misconfigurations without requiring a running cluster, making it ideal for early detection in CI/CD pipelines.

Exam trap

The trap here is that candidates often confuse static analysis of manifests (Kubesec) with image vulnerability scanning (Trivy image) or deployment commands (kubectl apply), because all three are security-related but operate at different stages of the supply chain.

How to eliminate wrong answers

Option B is wrong because 'kubectl apply' is a command to deploy manifests to a cluster, not a static analysis tool; it will apply misconfigurations without any security validation. Option C is wrong because 'trivy image' scans container images for vulnerabilities in OS packages and libraries, not Kubernetes manifest misconfigurations. Option D is wrong because 'helm template' renders Helm charts into Kubernetes manifests locally but performs no security scanning; it is a templating tool, not a static analyzer.

Full explanation →

334

MCQhard

An organization uses a GitOps workflow with Argo CD to deploy applications to Kubernetes. The security team wants to ensure that container images are immutable and signed. They currently use a private container registry (Harbor) with vulnerability scanning and Cosign for signing. Which combination of controls best enforces that only signed and scanned images are deployed?

A.Configure Argo CD to verify Cosign signatures before syncing the application.

B.Use imagePullSecrets in Kubernetes to ensure only Harbor images are used.

C.Add a Cosign verification step in the CI pipeline before pushing images to Harbor, and rely on that guarantee.

D.Enable Harbor's content trust feature to reject unsigned images, and use a Kyverno admission rule to verify Cosign signatures at deploy time.

AnswerD

Enabling Harbor's content trust feature causes the registry to reject pushes of unsigned images, meaning only images that carry the required signature can be stored and later pulled. A Kyverno admission rule with a `verifyImages` check validates the Cosign signature again at the moment Kubernetes attempts to create a Pod, so even if an image is replaced or a signed tag is moved to a different digest, the admission controller blocks it. Together these enforce signature integrity at both the registry boundary and the cluster boundary, providing defense-in-depth that a single control cannot achieve.

Why this answer

It enforces a two-layer defense: Harbor's content trust rejects unsigned images at the registry level, and a Kyverno admission rule verifies Cosign signatures at deploy time. This ensures that even if an unsigned image bypasses the registry, it will be blocked by Kubernetes admission control, providing defense in depth for supply chain security.

Exam trap

CNCF often tests the concept that imagePullSecrets only handle authentication, not integrity or signing, leading candidates to mistakenly choose Option B as a security control.

How to eliminate wrong answers

Option A is wrong because Argo CD does not natively verify Cosign signatures before syncing; it relies on external admission controllers or pre-sync hooks for such checks. Option B is wrong because imagePullSecrets only control authentication to pull images from a registry, not image integrity or signature verification. Option C is wrong because relying solely on CI pipeline verification is insufficient; an attacker could bypass the pipeline or push unsigned images directly to the registry, and there is no runtime enforcement.

Full explanation →

335

MCQeasy

A security engineer needs to ensure that all containers in a cluster run as non-root users. Which Pod Security Context field should be set to enforce this requirement?

A.runAsNonRoot: true

B.runAsUser: 1000

C.privileged: false

D.allowPrivilegeEscalation: false

AnswerA

The `runAsNonRoot: true` Pod security context setting forces Kubernetes to validate that the container image specifies a non-root user (e.g., via USER in the Dockerfile) or that a `runAsUser` value is explicitly set to a non-zero UID; if the image would run as UID 0, the Pod API request is rejected during admission, preventing the container from ever starting as root. This is the only option that directly enforces non-root execution at the container level, independent of the image's default behavior. It is the correct choice for the requirement to ensure all containers run as non-root.

Why this answer

Setting `runAsNonRoot: true` in the Pod Security Context explicitly instructs the container runtime to verify that the container's user ID is non-zero (i.e., not root). If the container image is configured to run as root (UID 0), the Pod will fail to start, enforcing the requirement that all containers run as non-root users.

Exam trap

The CKS exam often tests the distinction between setting a specific user ID (`runAsUser`) and enforcing a non-root check (`runAsNonRoot`), where candidates mistakenly think that specifying a non-zero UID alone guarantees the container is not running as root, ignoring that the image might still run as root if the UID is not set in the image.

How to eliminate wrong answers

Option B is wrong because `runAsUser: 1000` only sets the user ID to 1000 but does not prevent the container from running as root if the image is configured to run as root; the runtime will still run as UID 1000, but the check against root is not enforced. Option C is wrong because `privileged: false` only disables privileged mode (e.g., access to host devices) but does not enforce a non-root user; a container can still run as root without privileged mode. Option D is wrong because `allowPrivilegeEscalation: false` prevents processes from gaining more privileges than their parent (e.g., via setuid binaries) but does not require the container to start as a non-root user; it can still start as root and simply not escalate further.

Full explanation →

336

Multi-Selectmedium

Which TWO of the following are CIS Benchmark recommendations for securing the API server?

Select 2 answers

A.Enable the insecure port (--insecure-port)

B.Disable anonymous authentication

C.Enable audit logging

D.Use ABAC mode for authorization

E.Disable TLS

AnswersB, C

CIS controls for the API server and kubelet require --anonymous-auth=false so every request must be authenticated. Leaving anonymous access enabled allows unauthenticated users to query or mutate cluster state if RBAC is misconfigured. Disabling anonymous authentication is a core hardening step and is directly recommended by the benchmark.

Why this answer

The CIS Benchmark for Kubernetes recommends disabling anonymous authentication to ensure that all requests to the API server are authenticated. By setting the `--anonymous-auth=false` flag on the kube-apiserver, unauthenticated requests are rejected, which prevents anonymous users from accessing the cluster. This is a fundamental security hardening step to enforce identity verification for every API call.

Exam trap

CNCF often tests the distinction between deprecated/insecure features (like the insecure port or disabling TLS) and the actual CIS-recommended secure defaults, tempting candidates to select options that sound like hardening but are actually anti-patterns.

Full explanation →

337

MCQmedium

You are investigating a pod that may have been compromised. Which kubectl command allows you to run a shell inside the running container without overwriting the container's filesystem?

A.kubectl exec -it pod-name -- /bin/bash

B.kubectl debug pod-name --image=busybox

C.kubectl run -it --image=busybox sh

D.kubectl attach pod-name

AnswerA

kubectl exec -it pod-name -- /bin/bash starts a new process inside the already-running container, sharing its mount namespace, PID namespace, and network stack. This gives you direct access to the live filesystem, running processes, and environment variables exactly as they exist in the compromised pod, enabling immediate forensic evidence collection. This is the standard method for interactive shell access to an existing container and is the correct approach for investigating a compromise.

Why this answer

`kubectl exec -it pod-name -- /bin/bash` attaches an interactive shell to the running container without modifying its filesystem. This command uses the container runtime's exec facility to spawn a new process inside the existing container, leaving the container's root filesystem unchanged. It is the standard method for runtime investigation without altering the container's state.

Exam trap

The CKS exam often tests the distinction between `exec` (which runs inside the existing container) and `debug` (which creates a separate container), so the trap here is that candidates may choose `kubectl debug` thinking it provides a shell in the same container, but it actually creates a new container with its own filesystem, potentially overwriting evidence.

How to eliminate wrong answers

Option B is wrong because `kubectl debug pod-name --image=busybox` creates a new ephemeral container or debug pod that shares the target pod's namespaces, but it does not run a shell inside the original container; it runs a separate container with its own filesystem, which could overwrite or mask the original container's filesystem. Option C is wrong because `kubectl run -it --image=busybox sh` creates a completely new pod, not interacting with the existing pod's container, and thus does not allow investigation of the potentially compromised pod. Option D is wrong because `kubectl attach pod-name` attaches to the main process's stdin/stdout/stderr of the container, but it does not spawn a new shell; it only connects to the already-running process, which may not be a shell and cannot provide interactive investigation.

Full explanation →

338

MCQhard

A cluster has EncryptionConfiguration with aescbc provider. After rotating the encryption key, what must be done to re-encrypt existing Secrets with the new key?

A.Delete and recreate all Secrets

B.Restart the API server

C.Run 'kubectl encrypt secrets --key new-key'

D.Use 'kubectl get secrets --all-namespaces -o yaml | kubectl replace -f -'

AnswerD

This command retrieves every Secret in all namespaces as YAML and pipes it to 'kubectl replace —f -', which submits an update request for each Secret. Because replace triggers a write, the API server reads the existing ciphertext from etcd, decrypts it with the old key, and re-encrypts it using the currently active encryption key (the first key in the aescbc provider's key list). This effectively migrates all existing Secrets to the new key without deleting them or losing data, making it the correct procedure for encrypting existing data with the new key.

Why this answer

After rotating the encryption key in the EncryptionConfiguration, existing Secrets are still encrypted with the old key. To re-encrypt them with the new key, you must read all Secrets and write them back using 'kubectl get secrets --all-namespaces -o yaml | kubectl replace -f -'. This triggers the API server to encrypt the data with the new key (the first provider in the list) during the write operation.

Exam trap

CNCF often tests the misconception that restarting the API server or deleting/recreating Secrets is sufficient for re-encryption, when in fact the only way to re-encrypt existing data is to read and write it back through the API server.

How to eliminate wrong answers

Option A is wrong because deleting and recreating Secrets would cause data loss and downtime; the correct approach is to re-encrypt in place without deletion. Option B is wrong because restarting the API server only loads the new EncryptionConfiguration but does not re-encrypt existing Secrets; they remain encrypted with the old key until rewritten. Option C is wrong because 'kubectl encrypt secrets --key new-key' is not a valid kubectl command; Kubernetes does not provide a built-in command to manually trigger re-encryption of individual resources.

Full explanation →

339

MCQeasy

What is the primary purpose of an SBOM in supply chain security?

A.To list all open source and third-party components in an image

B.To scan images for secrets

C.To sign container images

D.To enforce network policies

AnswerA

An SBOM (Software Bill of Materials) is a formal, machine-readable inventory that enumerates all open source and third-party components, their exact versions, and dependency relationships inside a container image. Its primary purpose is to provide transparency and traceability for software supply chain security, enabling vulnerability correlation, license compliance, and provenance verification. Without an SBOM, you cannot systematically identify which component is affected by a newly disclosed CVE or audit what third-party code actually ships in production.

Why this answer

An SBOM (Software Bill of Materials) is a formal, machine-readable inventory of all components—including open source and third-party libraries—used to build a software artifact. In supply chain security, its primary purpose is to provide transparency and enable vulnerability tracking by listing every dependency, so that when a new CVE is disclosed, teams can quickly determine if their images are affected. This aligns directly with option A.

Exam trap

The CKS exam often tests the distinction between an SBOM (a list of components) and image signing (a cryptographic verification), causing candidates to confuse the two because both are part of supply chain security but serve different purposes.

How to eliminate wrong answers

Option B is wrong because scanning images for secrets is the job of tools like Trivy or secret scanners, not an SBOM, which is a metadata document. Option C is wrong because signing container images is done with tools like Cosign or Notary to ensure integrity and provenance, while an SBOM is a separate artifact that lists components. Option D is wrong because enforcing network policies is a runtime security control managed by Kubernetes NetworkPolicy resources or service meshes, unrelated to the composition of software artifacts.

Full explanation →

340

MCQhard

Given the exhibit, what will happen when a user creates a pod with an image from an untrusted registry?

A.The pod is rejected by NodeRestriction admission

B.The pod is rejected by PodSecurity admission

C.The pod is created and the image is pulled

D.The pod is created but the image is not pulled because it's untrusted

AnswerC

The AlwaysPullImages admission controller mutates each new pod's containers, setting imagePullPolicy to Always, which forces the kubelet to pull the image from the registry at every pod start rather than using local cache. This mutation is a validation-type operation that does not reject the pod; the pod is admitted and scheduled. The kubelet then performs an image pull from the specified registry, and since no admission controller or runtime configuration in the default chain blocks untrusted registries, the pull succeeds and the pod runs.

Why this answer

By default, Kubernetes does not enforce any restrictions on image registries. The kubelet will attempt to pull the image from any registry, including untrusted ones, unless an admission controller like ImagePolicyWebhook or a runtime-specific policy (e.g., containerd's `untrusted_workload` mode) is explicitly configured. In this scenario, no such policy is mentioned, so the pod is created and the image is pulled.

Exam trap

CNCF often tests the misconception that Kubernetes has a built-in 'untrusted registry' blocker, when in reality it requires explicit admission control or runtime configuration to enforce such policies.

How to eliminate wrong answers

Option A is wrong because NodeRestriction admission only limits the Node API access (e.g., prevents nodes from modifying pods bound to other nodes), not image registry validation. Option B is wrong because PodSecurity admission (formerly PSP) enforces security contexts and capabilities, not registry trustworthiness. Option D is wrong because Kubernetes does not have a built-in mechanism to block image pulls based on registry trust; the image will be pulled unless a custom admission webhook or runtime policy is configured.

Full explanation →

341

MCQeasy

Which command is used to check whether AppArmor is enabled and which profiles are loaded on a Linux node?

A.kubectl get seccomp

B.kubectl get apparmor

C.aa-status

D.systemctl status apparmor

AnswerC

aa-status is a command from the AppArmor userspace tools that reads /sys/kernel/security/apparmor and displays whether AppArmor is enabled, lists loaded profiles, and shows processes confined by each profile. It is the standard way to inspect AppArmor's state on a node. This is why it correctly answers the question.

Why this answer

AppArmor is a Linux Security Module (LSM) enforced at the node level, not a Kubernetes resource. Kubernetes does not expose AppArmor status via kubectl. To check whether AppArmor is enabled and which profiles are loaded, you must execute `aa-status` directly on the node (e.g., via SSH).

This command queries the AppArmor kernel module and lists all loaded profiles.

Exam trap

The trap here is that candidates assume AppArmor can be managed like a Kubernetes resource using kubectl, but it is a node-level security module that must be checked with Linux-native commands, not Kubernetes API objects.

How to eliminate wrong answers

Option A is wrong because `kubectl get seccomp` is not a valid kubectl command; seccomp profiles are managed via pod security contexts or runtime classes, not through a dedicated kubectl subcommand. Option B is wrong because `kubectl get apparmor` is also invalid; AppArmor profiles are not Kubernetes API resources and cannot be retrieved with kubectl. Option D is wrong because `systemctl status apparmor` only checks the systemd service status, not whether AppArmor is enabled in the kernel or which profiles are loaded; the service may be running but AppArmor could be in complain mode or have no profiles loaded.

Full explanation →

342

Multi-Selectmedium

Which TWO of the following are valid ways to verify a container image signature using cosign?

Select 2 answers

A.cosign validate myimage:latest

B.cosign verify-attestation --key cosign.pub myimage:latest

C.cosign check myimage:latest

D.cosign attest --key cosign.key myimage:latest

E.cosign verify --key cosign.pub myimage:latest

AnswersB, E

This command is correct because `cosign verify-attestation` checks the integrity and authenticity of an in-toto attestation attached to the image, using the provided public key (`cosign.pub`). It verifies that the attestation (e.g., SLSA provenance) was signed by the holder of the corresponding private key and has not been tampered with. This is a valid way to verify claims about an image beyond just its signature.

Why this answer

`cosign verify-attestation --key cosign.pub myimage:latest` validates an in-toto attestation attached to a container image using a public key, which is a valid method to verify the image's provenance and integrity. Option E is correct because `cosign verify --key cosign.pub myimage:latest` directly verifies the container image's signature against the provided public key, confirming the image was signed by the holder of the corresponding private key.

Exam trap

The CKS exam often tests the distinction between signing (`cosign sign`, `cosign attest`) and verifying (`cosign verify`, `cosign verify-attestation`) commands, and candidates may confuse `attest` (which creates a signature) with `verify-attestation` (which checks one).

Full explanation →

343

MCQhard

A cluster has been hardened by setting --anonymous-auth=false and enabling RBAC. However, kube-bench still reports a failure for the kubelet check 'Ensure that the --anonymous-auth argument is set to false'. What could be the reason?

A.The kubelet configuration file does not set --anonymous-auth=false

B.The API server is running with --authorization-mode=AlwaysAllow

C.The kubelet is using a self-signed certificate

D.The NodeRestriction admission plugin is not enabled

AnswerA

The kubelet has its own HTTP server on port 10250 with independent authentication settings, and its configuration file (e.g., /var/lib/kubelet/config.yaml) must explicitly disable anonymous access via the authentication.anonymous.enabled field or the --anonymous-auth=false flag. Kube-bench checks this setting separately from the API server, because simply setting anonymous-auth=false on the API server does not propagate to the kubelet. When the kubelet configuration lacks this explicit disabling, anonymous requests can still reach kubelet endpoints such as /pods, making this the correct root cause for the reported finding.

Why this answer

The kubelet can have its authentication settings configured either via command-line arguments or via a KubeletConfiguration file. If the kubelet configuration file does not explicitly set `authentication.anonymous.enabled` to `false`, the kubelet may still allow anonymous access even if the `--anonymous-auth=false` argument is passed on the command line, because the configuration file takes precedence over command-line flags. kube-bench checks the effective configuration, so if the file overrides the flag, the check fails.

Exam trap

The trap here is that candidates assume command-line flags always override the kubelet configuration file, but in reality the configuration file takes precedence for kubelet settings, so both must be set consistently.

How to eliminate wrong answers

Option B is wrong because the API server's `--authorization-mode=AlwaysAllow` affects authorization for API server requests, not the kubelet's anonymous authentication setting; kube-bench's kubelet check is specific to the kubelet's own `--anonymous-auth` flag. Option C is wrong because using a self-signed certificate relates to TLS certificate validation and does not impact the anonymous authentication setting; kube-bench has separate checks for certificate validation. Option D is wrong because the NodeRestriction admission plugin controls what node identities can do via the API server, not the kubelet's own anonymous authentication configuration.

Full explanation →

344

Multi-Selectmedium

Which TWO of the following are valid ways to enable mTLS between services in a service mesh (e.g., Istio)?

Select 2 answers

A.Creating a DestinationRule with a trafficPolicy that sets tls mode to ISTIO_MUTUAL

B.Creating a ServiceEntry for the destination service

C.Creating a NetworkPolicy that allows ingress on port 443

D.Creating a PeerAuthentication resource with mTLS mode set to STRICT

E.Creating an AuthorizationPolicy with DENY action

AnswersA, D

A DestinationRule applies client-side traffic policy, and when its trafficPolicy sets tls.mode to ISTIO_MUTUAL, the sending sidecar will present a client certificate and validate the server's certificate using the mesh CA. This explicitly enables mutual TLS for connections to the designated service, and it can also override a mesh-wide or namespace-wide mTLS mode for that specific host.

Why this answer

A DestinationRule with `trafficPolicy.tls.mode: ISTIO_MUTUAL` explicitly configures the client-side proxy (Envoy) to use mutual TLS when sending requests to the destination service. This is the standard Istio mechanism to enforce mTLS at the service-to-service communication level, ensuring both client and server certificates are exchanged and verified.

Exam trap

The trap here is that candidates often confuse AuthorizationPolicy or NetworkPolicy with mTLS configuration, but neither of those resources handles TLS encryption or certificate exchange — they only control authorization or network access at different layers.

Full explanation →

345

Multi-Selectmedium

Which TWO are benefits of using a distroless base image over a full OS image like Ubuntu? (Select two.)

Select 2 answers

A.Faster image build times

B.Smaller image size

C.Better compatibility with Kubernetes security contexts

D.Smaller attack surface

E.Easier debugging

AnswersB, D

Distroless images strip away shells, package managers, and non-essential OS utilities, retaining only the runtime environment (e.g., JVM, Python runtime) and necessary libraries. This reduces compressed image size from hundreds of MB to tens of MB, directly accelerating image pull times and lowering storage and bandwidth costs on Kubernetes clusters. For large deployments, the cumulative effect of smaller images can significantly improve pod startup latency and cluster resource consumption.

Why this answer

Distroless images contain only the application and its runtime dependencies, omitting package managers, shells, and other OS utilities. This results in a significantly smaller image size compared to full OS images like Ubuntu, which include a complete userland and filesystem. Smaller images reduce storage costs, network transfer times, and container startup latency.

Exam trap

A common trap is confusing image size with build performance: while distroless images are smaller, build times are dominated by layer caching and dependency installation, not the final image size.

Full explanation →

346

MCQeasy

Which kubectl command can be used to exec into a running container for forensic analysis during an incident response?

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

B.kubectl run --stdin --tty --image=busybox

C.kubectl logs <pod>

D.kubectl attach <pod>

AnswerA

kubectl exec -it <pod> -- /bin/sh launches a new /bin/sh process inside the container's namespaces via the kubelet and container runtime. The -i flag keeps STDIN open, -t allocates a pseudo-TTY, and the command after -- is executed directly as a new process in the container. This is the canonical way to get an interactive shell in a running pod's primary container for debugging.

Why this answer

`kubectl exec -it <pod> -- /bin/sh` allows you to start an interactive shell session inside a running container, which is essential for live forensic analysis during incident response. This command uses the Kubernetes API to execute a process (e.g., /bin/sh) in the container's namespaces, enabling you to inspect running processes, file systems, network connections, and memory artifacts without stopping the container.

Exam trap

The trap here is that candidates confuse `kubectl exec` with `kubectl attach` or `kubectl run`, mistakenly thinking attach provides a shell or that run can target an existing container, when in fact only exec gives interactive command execution inside a running container for forensic purposes.

How to eliminate wrong answers

Option B is wrong because `kubectl run --stdin --tty --image=busybox` creates a new pod from the busybox image, not exec into an existing running container; this is used for ad-hoc debugging or testing, not for forensic analysis of a specific container under investigation. Option C is wrong because `kubectl logs <pod>` only retrieves the container's stdout/stderr logs, which may be useful for initial triage but does not provide interactive access to the container's runtime state, processes, or filesystem for deep forensic analysis. Option D is wrong because `kubectl attach <pod>` attaches to the container's main process (PID 1) and its stdio streams, but it does not allow you to execute arbitrary commands or spawn a shell; it is designed for interacting with the container's primary application, not for forensic investigation.

Full explanation →

347

MCQmedium

Which flag is used to restrict the kubelet's ability to modify node status and pods?

A.--authorization-mode=Webhook

B.--read-only-port=0

C.--protect-kernel-defaults=true

D.--authentication-token-webhook=true

AnswerA

The --authorization-mode=Webhook flag on the kubelet enables external authorization for kubelet requests. While it can limit what actions are authorized, it does not specifically restrict the kubelet's ability to modify node status and pods. The dedicated mechanism is the NodeRestriction admission plugin on the API server.

Why this answer

None of the listed kubelet flags restricts the kubelet's ability to modify node status and pods. The restriction is implemented by the NodeRestriction admission controller on the Kubernetes API server, not by a kubelet flag. The kubelet flag --authorization-mode=Webhook only enables external webhook authorization for requests to the kubelet's own API; it does not enforce NodeRestriction-like limits on node or pod modifications.

Exam trap

Candidates often confuse admission controllers (like NodeRestriction) with kubelet flags. NodeRestriction is an API server admission controller, not a kubelet flag. The kubelet flag --authorization-mode=Webhook only enables an external authorization check for the kubelet's own API endpoints; it does not restrict which node or pod objects the kubelet can modify.

How to eliminate wrong answers

Option B is wrong because `--read-only-port=0` disables the kubelet's read-only port (10255), which prevents unauthenticated read access to metrics and stats, but does not restrict the kubelet's ability to modify node status or pods. Option C is wrong because `--protect-kernel-defaults=true` ensures the kubelet checks and enforces kernel parameter settings (e.g., sysctl) for security, but it does not control authorization for node or pod modifications. Option D is wrong because `--authentication-token-webhook=true` enables token-based authentication via a webhook, verifying the identity of API requesters, but it does not restrict the kubelet's own ability to modify resources—that requires authorization, not authentication.

Full explanation →

348

MCQmedium

What is the purpose of the `allowPrivilegeEscalation: false` setting in a container's security context?

A.It prevents the container from running as root.

B.It prevents processes from gaining additional privileges (e.g., via setuid).

C.It prevents the container from using host networking.

D.It prevents the container from accessing host devices.

AnswerB

When set to false, Kubernetes instructs the container runtime to apply the Linux no_new_privs attribute to all processes in the container. This prevents a process from gaining additional privileges through setuid/setgid binaries, file capabilities, or other mechanisms that would elevate its effective UID or grant new capabilities beyond those initially assigned. It is a cornerstone security control that contains a compromised process, ensuring it cannot escalate to a more privileged state within the container.

Why this answer

The `allowPrivilegeEscalation: false` setting in a container's security context directly controls whether processes within the container can gain more privileges than their parent process. This is achieved by dropping the `CAP_SETUID`, `CAP_SETGID`, and `CAP_SETPCAP` capabilities and, crucially, by setting the `no_new_privs` flag on the container's process, which prevents the use of setuid/setgid binaries and other privilege-escalation mechanisms. This is a core security control to mitigate container breakout via privilege escalation.

Exam trap

CNCF often tests the distinction between 'running as root' and 'privilege escalation' — candidates confuse `allowPrivilegeEscalation: false` with `runAsNonRoot: true`, but the former blocks the ability to gain new privileges regardless of the current user, while the latter only restricts the initial user ID.

How to eliminate wrong answers

Option A is wrong because preventing the container from running as root is achieved by setting `runAsUser: 1000` or `runAsNonRoot: true`, not by `allowPrivilegeEscalation: false`. Option C is wrong because preventing the container from using host networking is controlled by the `hostNetwork: false` setting in the Pod spec, not by the security context's privilege escalation flag. Option D is wrong because preventing access to host devices is done via `privileged: false` and not adding host device mounts, not by the `allowPrivilegeEscalation` setting.

Full explanation →

349

MCQhard

You need to encrypt Secrets at rest in an existing Kubernetes cluster. You create an EncryptionConfiguration file specifying aescbc as the provider. After updating the API server kube-apiserver.yaml with the new configuration, you create a new Secret. Which of the following statements is true?

A.Only newly created secrets will be encrypted; existing secrets remain unencrypted.

B.The encryption key is automatically rotated every 30 days.

C.The aescbc provider can be changed to identity without any impact on existing secrets.

D.All existing secrets in the cluster are automatically encrypted after the API server restart.

AnswerA

Enabling the aescbc provider encrypts data written after the API server restarts with the new configuration. Secrets created beforehand remain stored in plaintext until they are rewritten, so existing secrets must be recreated or updated to gain encryption.

Why this answer

The EncryptionConfiguration only applies to data written to etcd after the API server is restarted with the new configuration. Existing Secrets that were stored in etcd before the restart remain in their original unencrypted form unless they are explicitly rewritten (e.g., by deleting and recreating them or using a tool like `kubectl get secret ... -o yaml | kubectl replace -f -`). The `aescbc` provider encrypts new data at rest, but does not retroactively encrypt existing data.

Exam trap

A common misconception is that restarting the API server with an EncryptionConfiguration retroactively encrypts existing data, but actually only new writes are encrypted.

How to eliminate wrong answers

Option B is wrong because key rotation is not automatic; the EncryptionConfiguration must be manually updated with a new key and the API server restarted to rotate keys, and there is no built-in 30-day rotation mechanism. Option C is wrong because changing the provider from `aescbc` to `identity` would cause the API server to read existing encrypted secrets as raw ciphertext (since `identity` does not decrypt), leading to data corruption or loss unless all secrets are first decrypted and rewritten using the old provider. Option D is wrong because existing secrets are not automatically encrypted; only newly created or updated secrets after the API server restart are encrypted.

Full explanation →

350

MCQeasy

Which of the following flags should be set on the kube-apiserver to disable anonymous authentication?

A.--disable-anonymous-auth

B.--enable-anonymous-auth=false

C.--anonymous-auth=false

D.--anonymous-auth=off

AnswerC

--anonymous-auth=false is the correct flag and value to disable anonymous authentication in the kube-apiserver. When set to false, requests that do not present valid credentials are rejected before any authorization checks are performed. This is a critical security hardening step because anonymous requests would otherwise be authenticated as the 'system:anonymous' user and could be granted RBAC permissions if such bindings exist.

Why this answer

The kube-apiserver uses the `--anonymous-auth` flag to control anonymous requests. Setting `--anonymous-auth=false` explicitly disables anonymous authentication, meaning unauthenticated requests (those without a valid bearer token or client certificate) will be rejected with a 401 Unauthorized response. This is a critical hardening step to prevent unauthorized access to the Kubernetes API server.

Exam trap

The trap here is that candidates confuse the flag name with a 'disable' or 'enable' prefix pattern common in other tools, or assume a non-boolean value like 'off' or 'false' string works, when Kubernetes strictly requires the exact `--anonymous-auth=false` syntax.

How to eliminate wrong answers

Option A is wrong because `--disable-anonymous-auth` is not a valid kube-apiserver flag; the correct flag name is `--anonymous-auth`. Option B is wrong because `--enable-anonymous-auth=false` is not a recognized flag; Kubernetes does not use an `enable-` prefix for this setting, and the flag must be `--anonymous-auth` with a boolean value. Option D is wrong because `--anonymous-auth=off` uses a string value 'off' instead of the required boolean `false`; the kube-apiserver expects a boolean (true/false), and 'off' will be interpreted as true (since it is a non-empty string), leaving anonymous auth enabled.

Full explanation →

351

MCQmedium

You are auditing RBAC and find a ClusterRoleBinding named 'admin-binding' that binds the 'cluster-admin' ClusterRole to a service account in the 'default' namespace. What is the security concern?

A.The binding should be a RoleBinding instead of ClusterRoleBinding

B.It grants too broad permissions to the service account

C.The service account name must be changed

D.The binding is fine as long as the service account is used in the default namespace

AnswerB

The cluster-admin ClusterRole carries wildcard verbs and resources across every namespace. Binding it to a default-namespace service account means any pod using that account can read secrets, escalate privileges and modify workloads cluster-wide, far exceeding what the workload requires.

Why this answer

The 'cluster-admin' ClusterRole grants super-user permissions across the entire cluster, including access to all namespaces and all resources. Binding this role to a service account via a ClusterRoleBinding gives that service account unrestricted cluster-wide privileges, which violates the principle of least privilege. This is a significant security concern because if the service account is compromised, an attacker gains full control over the cluster.

Exam trap

The trap here is that candidates may focus on the binding type (ClusterRoleBinding vs RoleBinding) or namespace usage, rather than recognizing that the core issue is the excessive privileges of the 'cluster-admin' role itself, regardless of how it is bound.

How to eliminate wrong answers

Option A is wrong because a ClusterRoleBinding is necessary to bind a ClusterRole; a RoleBinding can only bind a ClusterRole to subjects within a specific namespace, but the security issue here is the excessive permissions of the 'cluster-admin' role itself, not the binding type. Option C is wrong because the service account name is irrelevant to the security concern; the problem is the permissions granted, not the identity. Option D is wrong because the binding is not fine; even if the service account is used only in the default namespace, the ClusterRoleBinding grants cluster-wide permissions, allowing the service account to access resources in any namespace, which is a severe security risk.

Full explanation →

352

MCQhard

You are deploying a ValidatingWebhookConfiguration. The webhook server is running in the 'webhook' namespace, service name 'svc', port 443. Which clientConfig should you specify?

A.clientConfig: service: namespace: webhook name: svc path: /validate

B.clientConfig: url: https://webhook.svc.cluster.local:443/validate

C.clientConfig: service: namespace: webhook name: webhook path: /validate

D.clientConfig: service: namespace: default name: svc path: /validate

AnswerA

This is the correct configuration because the clientConfig.service block directly references the Service named `svc` in the `webhook` namespace, which is exactly where the webhook server is deployed. The API server will resolve this Service reference to a stable DNS name (`svc.webhook.svc.cluster.local`) and forward admission requests to the `path` `/validate` on that Service's HTTPS endpoint. Using the Service reference rather than a raw URL is the recommended Kubernetes pattern because it lets the API server automatically account for the Service's ClusterIP and the configured CA bundle.

Why this answer

A ValidatingWebhookConfiguration's clientConfig must reference the Kubernetes service that fronts the webhook server, specifying the service's namespace, name, and the path to the validation endpoint. Since the webhook server runs in the 'webhook' namespace with service name 'svc' on port 443, the service reference must use namespace: webhook and name: svc, with path: /validate. Kubernetes automatically resolves the service to its cluster-internal DNS name and uses the service's HTTPS port (443) when a service reference is provided.

Exam trap

Common mistake: candidates may specify the wrong service name, using the webhook server's deployment name or pod name instead of the actual service name, or they may omit the 'path' field. Also, the namespace must match the service's namespace, not the default namespace.

How to eliminate wrong answers

Option B is wrong because while a raw URL can be used, it is not the recommended or typical approach for in-cluster webhooks; the service reference is preferred for automatic DNS resolution and port handling, and the URL format shown does not match the standard cluster DNS pattern (which would be svc.webhook.svc.cluster.local). Option C is wrong because it incorrectly specifies the service name as 'webhook' instead of 'svc', which would cause the API server to fail to reach the webhook server. Option D is wrong because it sets the namespace to 'default' instead of 'webhook', so the API server would look for the service in the wrong namespace and fail to connect.

Full explanation →

353

MCQeasy

Which tool is used to load AppArmor profiles on a node?

A.apparmor_parser

B.aa-enforce

C.aa-status

D.kubectl apply

AnswerA

apparmor_parser is the standard userspace tool that reads AppArmor policy text files, compiles them into the kernel's binary policy format, and sends them to the AppArmor LSM via the securityfs interface (typically mounted at /sys/kernel/security/apparmor). Flags such as -r (replace) and -a (add) control whether an existing profile is overwritten or a new one is inserted, making this the definitive tool for loading or updating profiles on a node. Without a successful apparmor_parser invocation, no AppArmor profile is active in the kernel, regardless of any other tools.

Why this answer

The `apparmor_parser` tool is the standard utility for loading AppArmor profiles into the kernel's security module. It reads profile definitions from text files, compiles them into binary form, and loads them into the kernel's LSM (Linux Security Module) subsystem. Without this tool, AppArmor profiles cannot be activated on a node.

Exam trap

Candidates may confuse `aa-enforce` (which changes the mode of an already-loaded profile) with the actual profile loading tool, or mistakenly think `kubectl apply` can load kernel-level security profiles. In the CKS exam, understanding the correct tool for loading AppArmor profiles is important for node hardening.

How to eliminate wrong answers

Option B is wrong because `aa-enforce` is used to switch an already-loaded AppArmor profile from complain mode to enforce mode, not to load a profile from scratch. Option C is wrong because `aa-status` only displays the current status of loaded AppArmor profiles and does not perform any loading operations. Option D is wrong because `kubectl apply` is a Kubernetes command for managing cluster resources (e.g., pods, deployments) and has no capability to interact with the node-level AppArmor subsystem.

Full explanation →

354

MCQmedium

You suspect a container has been compromised. You want to preserve the container's filesystem for forensic analysis before terminating the pod. Which approach should you use?

A.Exec into the container and delete suspicious files

B.Restart the kubelet on the node

C.Use kubectl cp to copy files from the container to a safe location

D.Immediately delete the pod to stop the attack

AnswerC

Using kubectl cp is correct because it reads the container's filesystem through the container runtime and produces a tar archive in a safe location without modifying the source files; the command uses tar and writes to stdout, so the container's storage layer is left untouched for subsequent analysis. This preserves evidence such as dropped payloads, shell history, modified binaries, and configuration files, and it can be performed quickly even while the container remains running. Be aware that kubectl cp does not capture memory or /proc, but for filesystem artifacts it is the advisable first step before any destructive containment.

Why this answer

Using kubectl cp to copy files from the container to a safe location preserves the container's filesystem for forensic analysis without altering the running container. This method allows you to extract files for offline analysis while keeping the container intact for further investigation.

Exam trap

CKS often tests the misconception that deleting the pod or restarting the kubelet is a quick fix, but it destroys evidence needed for forensic analysis.

How to eliminate wrong answers

Option A is wrong because deleting suspicious files destroys evidence and may alert the attacker. Option B is wrong because restarting the kubelet does not preserve the container's filesystem and may cause the container to restart, losing volatile data. Option D is wrong because deleting the pod immediately destroys the container and its filesystem, losing critical forensic evidence.

Full explanation →

355

MCQmedium

An administrator wants to drop all capabilities for a container and then add back only NET_BIND_SERVICE. Which securityContext configuration is correct?

A.capabilities: add: ["NET_BIND_SERVICE"]

B.capabilities: drop: ["ALL"]

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

D.capabilities: drop: ["NET_BIND_SERVICE"] add: ["ALL"]

AnswerC

Dropping "ALL" first strips every Linux capability, including defaults, then adding NET_BIND_SERVICE back grants only the ability to bind ports below 1024. This satisfies the stem's constraint of a single re-added capability, since Kubernetes applies drops before adds within the same securityContext.

Why this answer

It first drops all capabilities using `drop: ["ALL"]`, which removes every Linux capability from the container, and then explicitly adds back only `NET_BIND_SERVICE`. This follows the principle of least privilege: start with no capabilities and grant only what is needed. The `securityContext` in Kubernetes applies these settings at the container level, ensuring the container can bind to privileged ports (below 1024) without any other elevated permissions.

Exam trap

Kubernetes often tests the order of operations in capability management — candidates mistakenly think that adding a capability after dropping all is unnecessary or that dropping all alone is sufficient, but the correct sequence must explicitly include both `drop: ["ALL"]` and `add: ["NET_BIND_SERVICE"]` to achieve the intended least-privilege state.

How to eliminate wrong answers

Option A is wrong because it only adds `NET_BIND_SERVICE` without dropping any existing capabilities, leaving the container with its default set of capabilities (which may include many unnecessary and potentially dangerous ones). Option B is wrong because it drops all capabilities but never adds back `NET_BIND_SERVICE`, so the container would lack the ability to bind to privileged ports, causing failures for services that need to listen on ports like 80 or 443. Option D is wrong because it drops `NET_BIND_SERVICE` and adds `ALL`, which is the opposite of the desired configuration — it removes the needed capability and grants all capabilities, violating the principle of least privilege.

Full explanation →

356

MCQmedium

A security policy requires that all container images use SHA-based digests instead of tags. Which approach ensures this in a Deployment YAML?

A.Use the 'image' field with a tag and also set 'digest' field

B.Set imagePullPolicy: Always and use tags

C.Use the image field with a digest, e.g., 'image: nginx@sha256:abc123'

D.Set imagePullPolicy: IfNotPresent and use tags

AnswerC

Referencing the image by its sha256 digest pins the exact immutable manifest, so Kubernetes pulls precisely that content. Tags are mutable and can be repointed, so the digest form is the only field syntax that satisfies the SHA-based digest policy.

Why this answer

Kubernetes supports using a SHA-based digest in the `image` field, which ensures the exact image content is pulled regardless of tag changes. By specifying the image as `nginx@sha256:abc123`, the container runtime fetches the image by its immutable digest, guaranteeing supply chain integrity and compliance with the security policy.

Exam trap

The CKS exam often tests the misconception that a separate `digest` field exists in the Kubernetes API, when in reality the digest must be appended to the image name using the `@sha256:` syntax.

How to eliminate wrong answers

Option A is wrong because there is no separate `digest` field in a Deployment YAML; the digest must be appended to the image name in the `image` field. Option B is wrong because setting `imagePullPolicy: Always` with tags still allows the tag to be updated to a different image, violating the requirement for immutable digest-based references. Option D is wrong because `imagePullPolicy: IfNotPresent` with tags does not enforce digest usage; the tag can still point to a different image over time, breaking the security policy.

Full explanation →

357

MCQmedium

Which crictl command is used to view the logs of a specific container in a node?

A.crictl logs <container-id>

B.crictl exec -it <container-id> sh

C.crictl pods

D.crictl ps -a

AnswerA

crictl logs <container-id> is the correct command because it directly retrieves the container's stdout/stderr streams through the CRI (Container Runtime Interface). It functions analogously to 'docker logs', letting you inspect application output for debugging or monitoring, and it reads from the runtime's buffer for the specified container.

Why this answer

The crictl logs command retrieves the logs of a specific container identified by its container ID, analogous to docker logs or kubectl logs. It queries the container runtime (via CRI) for the container's stdout/stderr output. This is the correct tool for inspecting logs directly on a node without going through the Kubernetes API.

Exam trap

The trap is confusing crictl subcommands — candidates may pick exec or ps thinking they retrieve logs, but only crictl logs returns container log output.

How to eliminate wrong answers

Option B is wrong because crictl exec -it <container-id> sh opens an interactive shell inside the container rather than displaying its logs. Option C is wrong because crictl pods lists pods known to the runtime, not container logs. Option D is wrong because crictl ps -a lists all containers including stopped ones, providing status information rather than log output.

Full explanation →

358

MCQmedium

An audit policy is configured with level: Request. Which operations are recorded in the audit log?

A.Nothing, only the fact that a request occurred

B.Request metadata and the request body

C.Request and response metadata and bodies

D.Only metadata about the request

AnswerB

Request level is the correct configuration: it captures audit event metadata (e.g., user, source IP, verb, resource) and the complete request body. This gives deep visibility into exactly what the client sent, while intentionally omitting the response data to reduce storage and sensitive-data exposure. Because the question explicitly specifies level 'Request', this is precisely what gets logged.

Why this answer

When an audit policy is configured with `level: Request`, the API server logs the request metadata and the request body for all operations. This is defined in the Kubernetes audit policy specification, where the `Request` level captures the entire request object, including metadata and the body, but does not include the response. This level is useful for debugging and security analysis without the overhead of logging response data.

Exam trap

The CKS exam often tests the distinction between `Metadata`, `Request`, and `RequestResponse` levels, and the trap here is that candidates confuse `Request` with `Metadata`, thinking it only logs metadata, or mistakenly believe `Request` includes response data.

How to eliminate wrong answers

Option A is wrong because `level: Request` does record the request body and metadata, not just the fact that a request occurred (which would be `level: Metadata`). Option C is wrong because logging both request and response metadata and bodies corresponds to `level: RequestResponse`, not `Request`. Option D is wrong because logging only metadata about the request is the behavior of `level: Metadata`, which omits the request body.

Full explanation →

359

MCQeasy

Which kubectl command creates a valid webhook configuration that validates pods against a policy?

A.kubectl apply -f webhookconfiguration.yaml

B.kubectl apply -f podpreset.yaml

C.kubectl apply -f mutatingwebhookconfiguration.yaml

D.kubectl apply -f validatingwebhookconfiguration.yaml

AnswerD

ValidatingWebhookConfiguration is the correct resource type for registering validation webhooks, as it tells the API server which HTTP endpoint to call during admission and whether to allow or deny the request. When you apply a valid validatingwebhookconfiguration.yaml, the API server sends AdmissionReview objects to your configured webhook service and enforces the returned decisions. This is the idiomatic way to add custom validation logic to a cluster.

Why this answer

A ValidatingWebhookConfiguration is the Kubernetes resource that intercepts API server requests to validate resources (e.g., pods) against an external policy before they are persisted. The command `kubectl apply -f validatingwebhookconfiguration.yaml` creates this configuration, which triggers a webhook call to an admission webhook server that returns an admission review with an 'allowed' or 'denied' decision.

Exam trap

The trap here is that candidates confuse ValidatingWebhookConfiguration with MutatingWebhookConfiguration, or assume a generic 'webhookconfiguration.yaml' is valid, but the CKS exam specifically tests the distinction between validation and mutation in admission webhooks.

How to eliminate wrong answers

Option A is wrong because 'webhookconfiguration.yaml' is not a standard Kubernetes API resource; the correct resource types are ValidatingWebhookConfiguration or MutatingWebhookConfiguration. Option B is wrong because PodPreset is a deprecated alpha resource that injects information into pods at creation time, not a webhook configuration for validating pods against a policy. Option C is wrong because a MutatingWebhookConfiguration is used for mutating (modifying) resources, not for validating them; validation requires a ValidatingWebhookConfiguration.

Full explanation →

360

Multi-Selecthard

Which TWO of the following admission controllers are relevant for supply chain security in Kubernetes?

Select 2 answers

A.MutatingAdmissionWebhook (for sidecar injection)

B.ImagePolicyWebhook

C.AlwaysPullImages

D.NodeRestriction

E.ValidatingAdmissionWebhook (used by Kyverno/Gatekeeper)

AnswersB, E

ImagePolicyWebhook is a built-in admission controller that queries an external service to validate image references before pods are admitted. It directly supports supply chain security by blocking images that fail registry or signature policy checks at admission time.

Why this answer

ImagePolicyWebhook (B) is correct because it is the built-in admission controller that forwards pod image decisions to an external image policy service, enabling enforcement of trusted registries, signature verification, and vulnerability policies before a workload is admitted. ValidatingAdmissionWebhook (E) is correct because policy engines such as Kyverno and OPA Gatekeeper use it to validate resources against supply chain rules, for example rejecting images that lack a valid Cosign signature or that come from unapproved registries. MutatingAdmissionWebhook (A) is not the right answer here since its typical use is sidecar injection and defaulting, not supply chain verification.

AlwaysPullImages (C) only forces image pulls on every pod start to avoid stale cached images and does not verify provenance or trust. NodeRestriction (D) limits what kubelets can modify on Node and Pod objects, which is a node-security control rather than a supply chain control.

Exam trap

The CKS exam often tests the difference between the purpose-built ImagePolicyWebhook and generic admission webhooks. ValidatingAdmissionWebhook is relevant when used by policy engines such as Kyverno/Gatekeeper to enforce supply chain policies, but MutatingAdmissionWebhook for sidecar injection, AlwaysPullImages, and NodeRestriction are not supply chain security controllers in this context.

Full explanation →

361

MCQmedium

What is the effect of setting 'hostPID: true' in a pod's spec?

A.The container runs with the host's IPC namespace.

B.The container can access the host's network interfaces.

C.The container can mount the host's filesystem.

D.The container runs in the host's PID namespace.

AnswerD

The container runs in the host's PID namespace. This is correct because when hostPID: true is set, the container sees the exact same process list and process IDs as processes on the host, and processes inside the container are visible to all host processes. This removes process isolation, letting the container inspect or send signals (if permitted) to any host process. It effectively makes the container's own PID 1 correspond to the host's init process, so there is no separate PID namespace.

Why this answer

Setting 'hostPID: true' in a pod's spec allows the container to share the host node's PID namespace, meaning the container can see and interact with all processes running on the host, not just those within its own PID namespace. This is a privileged-level setting that bypasses the default process isolation provided by Kubernetes and Linux namespaces.

Exam trap

CNCF often tests the distinction between the three host namespace settings (hostPID, hostIPC, hostNetwork) and candidates frequently confuse 'hostPID' with 'hostNetwork' or 'hostIPC' due to similar naming patterns.

How to eliminate wrong answers

Option A is wrong because 'hostPID: true' controls the PID namespace, not the IPC namespace; to share the host's IPC namespace, you would set 'hostIPC: true'. Option B is wrong because accessing the host's network interfaces is achieved by setting 'hostNetwork: true', not 'hostPID: true'. Option C is wrong because mounting the host's filesystem is not directly controlled by 'hostPID'; that requires a hostPath volume mount or privileged container settings.

Full explanation →

362

MCQhard

A pod is configured with a custom seccomp profile stored at /var/lib/kubelet/seccomp/custom-profile.json. The pod manifest uses securityContext.seccompProfile with type: Localhost and localhostProfile: "custom-profile.json". The pod fails to start with an error 'seccomp profile not found'. What is the most likely cause?

A.The securityContext.seccompProfile.defaultRuntimeProfile field must be set to 'custom-profile.json'.

B.The seccomp profile should be defined in the pod's annotations, not securityContext.

C.The custom-profile.json file is not present on the node filesystem.

D.The localhostProfile field must be an absolute path.

AnswerC

A missing localhost profile file prevents the container runtime from initializing the container. When `type: Localhost` is used, the kubelet resolves `localhostProfile` against the node's seccomp profile root and sends the path to the runtime; if the file is not present, the container creation fails with a file-not-found error and the pod never reaches Running. Always verify that the profile file exists on every worker node that may schedule the pod.

Why this answer

The error 'seccomp profile not found' indicates that the Kubernetes kubelet cannot locate the specified profile file on the node's filesystem. When using `type: Localhost`, the `localhostProfile` value is resolved relative to the kubelet's seccomp profile root directory (default `/var/lib/kubelet/seccomp`). If the file `custom-profile.json` does not exist at that path on the node, the pod will fail to start.

Exam trap

CNCF often tests the misconception that `localhostProfile` requires an absolute path, but in reality it is a relative path from the kubelet's seccomp directory, and the error 'not found' points to a missing file, not a path format issue.

How to eliminate wrong answers

Option A is wrong because `defaultRuntimeProfile` is not a valid field in `securityContext.seccompProfile`; the correct field is `type`, and `defaultRuntimeProfile` is a separate concept used in the kubelet's configuration or in the `RuntimeDefault` type. Option B is wrong because seccomp profiles can be defined either via pod annotations (deprecated in Kubernetes 1.19) or via `securityContext.seccompProfile` (the current stable API); the error is not due to using `securityContext` instead of annotations. Option D is wrong because `localhostProfile` does not require an absolute path; it is interpreted as a filename relative to the kubelet's seccomp profile directory (`/var/lib/kubelet/seccomp`), and an absolute path would be incorrect unless it points to a file outside that directory, which is not supported.

Full explanation →

363

Multi-Selecthard

Which THREE of the following are required to configure encryption of secrets at rest in Kubernetes?

Select 3 answers

A.Specifying an encryption provider such as `aescbc` in the EncryptionConfiguration

B.An EncryptionConfiguration YAML file defining encryption providers and resources to encrypt

C.Running `kubectl get secrets --all-namespaces -o yaml | kubectl apply -f -` to rewrite existing secrets

D.Passing the `--encryption-provider-config` flag to the kube-apiserver

E.Modifying the etcd configuration to enable encryption at rest

AnswersA, B, D

Specifying an encryption provider such as `aescbc` in the EncryptionConfiguration is essential because the provider determines the cryptographic algorithm and key used to encrypt secrets at rest. `aescbc` uses AES-CBC with a 256-bit key and is the recommended provider for most clusters. Without a provider, the configuration is invalid and the API server cannot perform any encryption, so data would remain plaintext in etcd.

Why this answer

The `aescbc` encryption provider is one of the supported providers in Kubernetes for encrypting secrets at rest. Specifying it in the `EncryptionConfiguration` tells the kube-apiserver which encryption algorithm to use when writing data to etcd. Without a provider like `aescbc`, secrets are stored in plaintext in etcd.

Exam trap

A common misconception is that modifying etcd configuration directly enables encryption at rest, when in fact encryption is a kube-apiserver concern managed via the `--encryption-provider-config` flag and `EncryptionConfiguration` resource.

Full explanation →

364

MCQmedium

A security policy requires that all ServiceAccounts in a namespace do not automatically mount their tokens. How can this be achieved at the namespace level?

A.Set automountServiceAccountToken: false in each pod spec

B.Use a PodSecurityPolicy to deny token mounting

C.Set automountServiceAccountToken: false in the ServiceAccount definition

D.Delete the default ServiceAccount

AnswerC

Setting automountServiceAccountToken: false on the ServiceAccount definition is the correct, namespace-scoped control because this field controls whether the kubelet automatically projects the service account token into every pod that uses that account. When applied to the default ServiceAccount, it affects all pods in that namespace that do not explicitly override the setting, since most workloads implicitly use the default account unless a different one is specified. This is the precise, declarative mechanism designed to disable automatic token mounting at the service account level, fulfilling the security policy cleanly.

Why this answer

Setting `automountServiceAccountToken: false` in the ServiceAccount definition applies the setting to all pods that use that ServiceAccount, effectively enforcing the policy at the namespace level when the default or all ServiceAccounts are configured this way. This is the correct approach because the ServiceAccount's `automountServiceAccountToken` field controls token mounting for pods referencing it, overriding any pod-level setting unless explicitly set in the pod spec.

Exam trap

CNCF often tests the distinction between namespace-level and pod-level controls, and the trap here is that candidates mistakenly think PodSecurityPolicy can control token mounting or that deleting the default ServiceAccount is a viable solution, when in fact the ServiceAccount's `automountServiceAccountToken` field is the intended namespace-wide mechanism.

How to eliminate wrong answers

Option A is wrong because setting `automountServiceAccountToken: false` in each pod spec is a per-pod solution, not a namespace-level enforcement; it requires manual configuration for every pod and does not scale or guarantee compliance across the namespace. Option B is wrong because PodSecurityPolicy (PSP) does not have a field to control ServiceAccount token mounting; PSP controls pod security contexts, volumes, and capabilities, but token mounting is governed by the ServiceAccount or pod spec, not PSP. Option D is wrong because deleting the default ServiceAccount does not prevent token mounting; Kubernetes will still create a new default ServiceAccount automatically, and pods without an explicit ServiceAccount will use the new default, which still mounts tokens by default.

Full explanation →

365

MCQeasy

You are reviewing a pod specification that mounts a hostPath volume to /var/run/docker.sock. Which security risk does this present, and what is the recommended mitigation?

A.It allows the container to access the host's PID namespace; mitigate by setting hostPID: false.

B.It allows the container to control the Docker daemon, potentially leading to host compromise; mitigate by avoiding hostPath mounts to the Docker socket and using a least-privilege approach.

C.It allows the container to read only the Docker logs; mitigate by setting readOnly: true on the volume mount.

D.It exposes the host's network stack; mitigate by setting hostNetwork: false.

AnswerB

Mounting the Docker socket gives the container full control over the Docker daemon, which can be used to start privileged containers, access the host filesystem, and escalate to root on the node. The recommended mitigation is to avoid mounting the Docker socket and instead use a secure API or a dedicated sidecar with least privilege. This is a well-known container escape vector.

Why this answer

Mounting the Docker socket gives the container control over the Docker daemon, enabling container escapes and host compromise. The correct mitigation is to avoid such mounts and use least-privilege alternatives. Read-only flags, hostNetwork, and hostPID settings do not mitigate this specific risk.

Exam trap

The trap here is thinking that a readOnly volume mount or disabling hostNetwork/hostPID mitigates the Docker socket risk, when the socket itself grants full daemon control regardless of those settings.

Full explanation →

366

Matchingmedium

Match each Kubernetes API server flag to its security function.

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

Concepts

Matches

Enables RBAC authorization

Comma-separated list of admission controllers to enable

Disables anonymous requests to the API server

Path to a CA file for verifying kubelet certificates

File containing PEM-encoded x509 RSA or ECDSA private or public keys for service account token signing

Why these pairings

Correct matches: --authorization-mode=RBAC enables RBAC; --anonymous-auth=false disables anonymous auth; --profiling=false disables profiling. Common confusions involve mixing authorization and authentication flags.

Full explanation →

367

MCQmedium

You are configuring an Istio service mesh for mTLS between services. Which resource defines the TLS mode for traffic between services in a namespace?

A.PeerAuthentication

B.ServiceEntry

C.VirtualService

D.DestinationRule

AnswerA

PeerAuthentication is the Istio Custom Resource Definition (CRD) that directly defines the mTLS policy for workloads, either mesh-wide, per-namespace, or with a pod selector. Its mode field accepts STRICT, PERMISSIVE, or DISABLE, and STRICT tells the server sidecar to reject plaintext traffic and require a client certificate. This is the authoritative security policy for enforcing mutual TLS between internal services, so it is the correct resource for this task.

Why this answer

PeerAuthentication is the correct resource because it defines the TLS mode (e.g., STRICT, PERMISSIVE, DISABLE) for mTLS between services within a namespace in Istio. It enforces the authentication policy for workloads, ensuring that all traffic between them uses mutual TLS as specified. This directly controls the TLS mode for inter-service communication at the namespace or mesh level.

Exam trap

The trap here is that candidates often confuse DestinationRule with PeerAuthentication, thinking DestinationRule's 'tls' field controls mTLS mode, but DestinationRule only configures client-side TLS settings (e.g., SNI) for outbound traffic, not the server-side authentication policy that PeerAuthentication enforces.

How to eliminate wrong answers

Option B (ServiceEntry) is wrong because it is used to add external services to the mesh, not to define TLS modes for internal traffic between services. Option C (VirtualService) is wrong because it defines traffic routing rules (e.g., weight-based routing, retries) and does not set TLS authentication policies. Option D (DestinationRule) is wrong because it configures traffic policies like load balancing and connection pool settings, but the TLS mode for mTLS is specifically governed by PeerAuthentication, not DestinationRule.

Full explanation →

368

MCQmedium

Which crictl command can you use to view the logs of a specific container?

A.crictl inspect <container-id>

B.crictl exec <container-id> cat /var/log/syslog

C.crictl ps

D.crictl logs <container-id>

AnswerD

This is the correct command. It fetches the log output of the specified container, capturing what the container wrote to stdout/stderr as captured by the container runtime (e.g., containerd). It works similarly to `docker logs` and is the standard way to view container logs in a CRI-compatible environment. The container ID can be obtained from `crictl ps`, and the command shows both historical and, with `-f`, live logs.

Why this answer

`crictl logs` is the dedicated command to retrieve and display the logs of a specific container managed by a CRI-compatible runtime (e.g., containerd, CRI-O). It works similarly to `docker logs` and reads the container's stdout/stderr streams, which are captured by the container runtime.

Exam trap

The CKS exam often tests the distinction between `crictl` and `docker` commands, and the trap here is that candidates might confuse `crictl inspect` (which shows metadata) with log retrieval, or assume `crictl exec` can read logs from a file inside the container, ignoring that container logs are streamed to stdout/stderr by default.

How to eliminate wrong answers

Option A is wrong because `crictl inspect` returns detailed configuration and state information about a container (e.g., mounts, environment variables, resource limits), not its log output. Option B is wrong because `crictl exec` runs a command inside a running container, but `/var/log/syslog` is not the standard location for container logs; container logs are captured via stdout/stderr, not written to syslog by default. Option C is wrong because `crictl ps` lists running containers with their IDs, names, and statuses, but does not display log content.

Full explanation →

369

Multi-Selecthard

Which THREE of the following are valid approaches to prevent containers from running as root in a Kubernetes cluster?

Select 3 answers

A.Use Pod Security Admission with the 'restricted' profile

B.Set the container's entrypoint to 'sudo'

C.Use OPA/Gatekeeper with a constraint that requires runAsNonRoot: true

D.Use a Seccomp profile that blocks root system calls

E.Use Kyverno with a policy that validates runAsNonRoot

AnswersA, C, E

Pod Security Admission with the 'restricted' profile is a native Kubernetes admission controller that enforces the most stringent Pod Security Standard. It requires each container to set `securityContext.runAsNonRoot: true`, and it also fails pods if the image is configured to run as UID 0 unless an explicit non-root user is set. Because it is built into the kube-apiserver, it requires no extra components and can be enforced per-namespace via labels, making it a reliable and straightforward approach to prevent root execution.

Why this answer

Pod Security Admission (PSA) is a built-in Kubernetes admission controller that enforces Pod Security Standards (PSS). The 'restricted' profile, as defined in the Kubernetes documentation, requires that containers run with `runAsNonRoot: true`, preventing root execution at the admission level without needing external tools.

Exam trap

The CKS exam often tests the distinction between preventing root execution (via `runAsNonRoot` or user ID constraints) and limiting kernel capabilities (via Seccomp or AppArmor), leading candidates to mistakenly choose Seccomp as a root-prevention mechanism.

Full explanation →

370

MCQmedium

You need to use gVisor as a container runtime for a set of workloads in the cluster. Which Kubernetes resource must be created to reference the runtime class?

A.Create a RuntimeClass resource with handler: runsc

B.Set the kubelet runtime flag --runtime-class=gvisor

C.Install a CRD for gVisor

D.Create a Pod with spec.runtimeClassName set to "gvisor"

AnswerA

A RuntimeClass resource names the runtime handler, here runsc, which the kubelet uses to run matching pods under gVisor. Creating it with handler: runsc registers the sandboxed runtime so pods can select it via runtimeClassName, satisfying the requirement.

Why this answer

In Kubernetes, a RuntimeClass resource is used to select a container runtime configuration, such as gVisor. The RuntimeClass must specify the handler field set to 'runsc', which is the gVisor runtime binary. This resource is then referenced by pods via the `runtimeClassName` field to enforce sandboxed isolation.

Exam trap

The trap here is that candidates confuse creating the RuntimeClass resource with simply setting a field on a Pod, forgetting that the RuntimeClass object must exist in the cluster first, and that gVisor does not require a CRD or kubelet flag.

How to eliminate wrong answers

Option B is wrong because `--runtime-class` is not a valid kubelet flag; the kubelet uses `--container-runtime` and `--container-runtime-endpoint` to configure runtimes, and runtime classes are defined as Kubernetes API objects, not kubelet flags. Option C is wrong because gVisor does not require a Custom Resource Definition (CRD); it uses the built-in RuntimeClass API resource, which is available in standard Kubernetes without CRDs. Option D is wrong because setting `spec.runtimeClassName` in a Pod spec references an existing RuntimeClass object; it does not create the RuntimeClass itself, which must exist beforehand.

Full explanation →

371

MCQhard

A user creates a Deployment with image 'alpine:3.18' and the Pod status is 'ErrImagePull'. The admin checks the image policy and sees that only images with SHA digests are allowed. What is the fix?

A.Enable the AlwaysPullImages admission controller

B.Change the image to 'alpine:latest'

C.Add a non-root user to the Dockerfile

D.Change the image to 'alpine@sha256:...'

AnswerD

Changing the image to alpine@sha256:... provides a content-addressable reference that uniquely pins the image manifest to its cryptographic digest. This mutability is eliminated: even if the original tag is moved, the deployment will always pull the exact verified image, and this format precisely satisfies the immutable-reference policy.

Why this answer

The cluster policy requires images to be identified by SHA digest rather than tags. Using an image reference like 'alpine@sha256:...' ensures the image is pulled by its immutable digest, bypassing tag-based resolution and satisfying the policy. This is a common supply chain security measure to prevent tag mutability and ensure image integrity.

Exam trap

The trap here is that candidates often confuse admission controllers (like AlwaysPullImages) with image reference policies, or assume that changing to a different tag (like 'latest') will bypass the restriction, when in fact the policy explicitly requires a digest-based reference.

How to eliminate wrong answers

Option A is wrong because enabling the AlwaysPullImages admission controller forces image pulls on every Pod creation but does not address the requirement to use SHA digests; the image tag 'alpine:3.18' would still be rejected by the policy. Option B is wrong because changing the tag to 'alpine:latest' still uses a mutable tag, which violates the policy that only SHA digests are allowed; it would also introduce a different security risk by pulling an unpredictable version. Option C is wrong because adding a non-root user to the Dockerfile improves container security but has no effect on image pull policies or digest requirements; the Pod would still fail with ErrImagePull due to the tag-based reference.

Full explanation →

372

Multi-Selecthard

Which THREE of the following are valid methods to enforce pod security standards in a Kubernetes cluster?

Select 3 answers

A.Use Kyverno policy engine

B.Run kube-bench on the cluster

C.Manual review of all pod specs

D.Use Open Policy Agent (OPA) with Gatekeeper

E.Enable PodSecurity admission plugin

AnswersA, D, E

Kyverno is a Kubernetes-native policy engine that operates as a dynamic admission controller, intercepting AdmissionReview requests during resource creation and modification. It enforces pod security by evaluating policies written as custom Kubernetes resources, which can include built-in rules aligned with the Pod Security Standards. Unlike static analysis or auditing, Kyverno actively rejects or mutates non-compliant pod manifests before they are persisted in etcd, making it a valid enforcement method.

Why this answer

Kyverno is a Kubernetes-native policy engine that can enforce pod security standards by validating, mutating, and generating resources based on policies written as Kubernetes custom resources. It integrates with the Kubernetes API server via dynamic admission webhooks, allowing it to reject non-compliant pod specs before they are persisted.

Exam trap

CNCF often tests the distinction between auditing tools (like kube-bench) and admission controllers that enforce policies at runtime, leading candidates to mistakenly select kube-bench as an enforcement method.

Full explanation →

373

MCQeasy

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

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

B.It limits each container to 1000 PIDs

C.It disables PID limiting, allowing a single pod to consume all PIDs on the node, risking a fork bomb

D.It enforces a default PID limit of 100 per pod

AnswerC

A podPidsLimit of -1 removes the cgroup pids.max cap entirely, so the container can spawn unlimited processes. A fork bomb inside that pod would exhaust the node's PID table, starving kubelet and other workloads of process IDs.

Why this answer

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

Exam trap

The trap here is that candidates often assume `-1` means 'no limit' is safe or that it enforces a default, but the CKS exam tests the specific security implication of disabling PID limiting, which is the risk of a fork bomb and node-wide DoS.

How to eliminate wrong answers

Option A is wrong because `-1` does not set a hard limit of 1 PID; it disables the limit entirely, and a value of 1 would be impractical and not the default behavior. Option B is wrong because `-1` does not limit each container to 1000 PIDs; that would correspond to a positive integer value, not `-1`. Option D is wrong because `-1` does not enforce a default PID limit of 100 per pod; it explicitly removes any limit, and the default in Kubernetes is typically 100 (set via `--pod-max-pids` in kubelet), but `-1` overrides that.

Full explanation →

374

MCQhard

A cluster uses Kyverno to enforce that all images come from a trusted registry. A new Deployment fails with a message that the image 'docker.io/library/nginx:latest' is not allowed. What Kyverno policy rule likely caused this?

A.A validate rule that checks the container's resource limits

B.A validate rule that checks the image registry

C.A generate rule that creates a ConfigMap

D.A mutating rule that adds a label to the pod

AnswerB

A validate rule that checks the image registry is the correct enforcement mechanism in Kyverno. Such a rule can use a pattern, a deny condition, or CEL expression to inspect the image field and reject any container whose registry is not in an allowed list. When the rule evaluates to deny, Kubernetes admission control fails, and the pod or workload is not created. This directly matches the requirement to enforce that all images come from approved registries.

Why this answer

Kyverno uses validate rules to enforce policies by checking resource attributes against defined conditions. The error message indicates that the image 'docker.io/library/nginx:latest' was rejected because it does not come from a trusted registry. A validate rule with a pattern or deny condition that inspects the image field (e.g., `spec.containers[*].image`) and restricts it to a specific registry prefix (like `trusted-registry.io/*`) would cause this rejection.

Exam trap

The trap here is that candidates confuse Kyverno's 'validate' rules (which deny non-compliant resources) with 'mutate' or 'generate' rules, which do not block admission; the explicit rejection message indicates that a validate rule with a condition on the image registry denied the deployment.

How to eliminate wrong answers

Option A is wrong because a validate rule checking resource limits would reject a Pod based on CPU/memory constraints, not image registry origin. Option C is wrong because a generate rule creates or synchronizes resources (like ConfigMaps) but does not block or validate existing resources. Option D is wrong because a mutating rule modifies resources (e.g., adding labels) but does not enforce admission denials; it would not produce a rejection message.

Full explanation →

375

Multi-Selectmedium

Which TWO of the following are recommended practices for securing container images and runtime?

Select 2 answers

A.Set runAsNonRoot to true in securityContext

B.Run containers as root inside the container for easier management

C.Set readOnlyRootFilesystem to true in securityContext

D.Mount the docker socket inside the container for debugging

E.Use the latest tag for all images

AnswersA, C

Setting runAsNonRoot to true in the securityContext forces the container process to run with a non-zero UID, preventing it from having root privileges. This is a critical defense-in-depth control because even if container is compromised, the attacker cannot exploit root-level capabilities to escalate to the host. Kubernetes will also reject the pod if the image specifies USER root when admission policies enforce this setting.

Why this answer

Setting `runAsNonRoot: true` in the securityContext ensures that the container's entrypoint runs with a user ID other than 0 (root), reducing the risk of container escape if an attacker gains code execution. Setting `readOnlyRootFilesystem: true` makes the container's filesystem read-only, preventing attackers from modifying critical system files or binaries. Both are key hardening practices recommended by Kubernetes security best practices.

Exam trap

A common pitfall is thinking that running as root inside a container is safe due to namespace isolation. However, root inside a container still has dangerous capabilities (e.g., CAP_SYS_ADMIN) that can lead to container escape, especially without proper seccomp or AppArmor profiles. This is a critical concept for the CNCF Kubernetes Security Specialist exam.

Full explanation →

Certified Kubernetes Security Specialist CKS (CKS) — Questions 301–375