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

301

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

Another admission controller.

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 →

302

MCQmedium

A developer wants to ensure that a pod can only receive traffic from pods with label 'app: frontend' in the same namespace. Which NetworkPolicy egress rule should be applied to the source pods?

A.Apply an egress rule on the target pod with 'to' podSelector matching 'app: frontend'

B.Apply an egress rule on the source pods with 'to' podSelector matching the target pod

C.Apply an ingress rule on the source pods with 'from' podSelector matching the target pod

D.Apply an ingress rule on the target pod with 'from' podSelector matching 'app: frontend'

AnswerD

Correct. Ingress rules on the target pod control which sources can send traffic to it.

Why this answer

The correct approach is to apply an ingress rule on the target pod, not an egress rule on the source pods. In Kubernetes NetworkPolicy, ingress rules control incoming traffic to the pods selected by the policy. Since the target pod needs to receive traffic only from pods with label 'app: frontend', you define a NetworkPolicy with a podSelector matching the target pod, and an ingress rule that uses a from selector with a podSelector matching 'app: frontend'.

This ensures that only pods with that label can send traffic to the target pod. Option D correctly describes this configuration, while options A, B, and C incorrectly apply rules on the wrong pods or use wrong directions.

Full explanation →

303

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

Ensures the container runs as a non-root user.

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 →

304

Multi-Selecthard

You are securing a Kubernetes cluster that runs workloads from multiple teams. The cluster uses a private container registry and an admission controller to enforce image policies. Which TWO of the following actions are most effective in preventing the use of unapproved or tampered container images? (Choose two correct answers.)

Select 2 answers

A.Use OPA Gatekeeper to enforce a policy that rejects pods using images with the 'latest' tag.

B.Configure imagePullSecrets for each namespace to ensure only authorized service accounts can pull images.

C.Deploy Kyverno with a policy that requires images to have a specific annotation indicating they passed a security scan.

D.Implement a NetworkPolicy that blocks egress traffic from the cluster to unauthorized container registries.

E.Set up an ImagePolicyWebhook admission controller that checks image signatures and only allows signed images from your registry.

AnswersC, E

Kyverno can enforce custom policies including image annotations that prove scanning.

Why this answer

Kyverno can enforce policies that require images to have specific annotations, such as one indicating a passed security scan. This ensures only images that have been verified by your security pipeline are allowed to run, directly preventing unapproved or tampered images from being deployed.

Exam trap

CNCF often tests the distinction between authentication/authorization and image integrity verification, where candidates mistakenly choose options that control access to registries (like imagePullSecrets or NetworkPolicy) instead of options that validate image content or approval status.

Full explanation →

305

Multi-Selecthard

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

Select 3 answers

A.Ignore the incident and monitor for further activity

B.Copy the container's filesystem using kubectl cp for offline analysis

C.Capture the container logs using kubectl logs

D.Apply a NetworkPolicy to isolate the pod

E.Immediately terminate the pod to contain the threat

AnswersB, C, D

Correct. This preserves evidence without altering the running container.

Why this answer

Isolating the pod via NetworkPolicy, preserving evidence by copying the filesystem, and capturing logs are key steps. Terminating the pod immediately may lose evidence, and ignoring is not recommended.

Full explanation →

306

MCQeasy

You need to configure the Kubernetes API server to log all requests at the Metadata level. Which flag should you use when starting kube-apiserver?

A.--audit-log-level=Metadata

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

C.--audit-webhook-mode=Metadata

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

AnswerB

Why this answer

The --audit-policy-file flag points to a YAML file that defines the audit policy. The policy file specifies the level for different resources. Option B is correct.

Option A is not a valid flag; Option C sets a different level; Option D is used to set the audit log path.

Full explanation →

307

MCQeasy

Which of the following is a valid way to check the status of AppArmor profiles on a node?

A.Use 'apparmor_parser --status'

B.Run 'kubectl get apparmorprofiles'

C.Read the file /sys/kernel/security/apparmor/profiles

D.Run 'aa-status' on the node

AnswerD

aa-status displays the current AppArmor profile status.

Why this answer

`aa-status` is the standard command-line tool for checking the status of AppArmor profiles on a Linux node. It displays which profiles are loaded, which processes are confined, and the enforcement mode (enforce/complain). This is the direct, node-level utility for AppArmor status verification.

Exam trap

The trap here is that candidates may confuse Kubernetes-native resources (like `kubectl get`) with node-level security tools, or assume that reading a kernel file is equivalent to using the dedicated status command, but the exam expects familiarity with the standard Linux administration command `aa-status` for AppArmor.

How to eliminate wrong answers

Option A is wrong because `apparmor_parser` is used to load or unload AppArmor profiles into the kernel, not to check their status; the `--status` flag does not exist for this command. Option B is wrong because `kubectl get apparmorprofiles` is not a valid Kubernetes API resource; AppArmor profiles are managed at the node level, not via Kubernetes objects. Option C is wrong because while `/sys/kernel/security/apparmor/profiles` lists loaded profiles, it is a raw kernel interface that requires parsing and does not provide a human-readable status summary like `aa-status` does.

Full explanation →

308

MCQhard

During a security incident, you need to isolate a compromised pod named 'malicious-pod' in namespace 'default' to prevent it from communicating with other pods. Which command should you run?

A.kubectl run networkpolicy --image=nginx --restart=Never

B.kubectl delete pod malicious-pod

C.kubectl apply -f networkpolicy.yaml

D.kubectl create networkpolicy isolate --pod-selector=app=malicious --policy-types=Ingress,Egress

AnswerC

Correct. You must write a NetworkPolicy YAML that selects the malicious pod and denies all traffic, then apply it.

Why this answer

Pod isolation is achieved by applying a NetworkPolicy that denies ingress/egress traffic. 'kubectl apply -f networkpolicy.yaml' applies the policy. The policy must be written to deny all traffic.

Full explanation →

309

Multi-Selecteasy

Which TWO of the following flags are used to secure the kubelet?

Select 2 answers

A.--protect-kernel-defaults

B.--anonymous-auth=false

C.--enable-admission-plugins

D.--audit-log-path

E.--authorization-mode=RBAC

AnswersA, B

Correct. This flag protects kernel defaults.

Why this answer

The `--protect-kernel-defaults` flag is used to secure the kubelet by ensuring that kernel tunable parameters (e.g., `vm.overcommit_memory`, `kernel.panic`) are set to safe values. If the kernel defaults are not properly configured, the kubelet will fail to start, preventing insecure kernel settings from being used. This flag is part of the kubelet's security hardening measures, as recommended by the CIS Kubernetes Benchmark.

Exam trap

CNCF often tests the distinction between kubelet flags and API server flags, so the trap here is that candidates may confuse `--authorization-mode=RBAC` or `--audit-log-path` as kubelet security settings when they are actually API server parameters.

Full explanation →

310

MCQmedium

A security admin wants to ensure all pods in a cluster drop ALL Linux capabilities. Which of the following YAML snippets should be added to a PodSecurityPolicy (assuming PSP is enabled) or a pod spec?

A.capabilities: drop: "ALL"

B.capabilities: drop: - "NET_RAW"

C.capabilities: add: ["ALL"]

D.capabilities: drop: ["ALL"]

AnswerD

This drops all capabilities, which is a security best practice.

Why this answer

Dropping all Linux capabilities from a container is achieved by specifying `drop: ["ALL"]` in the PodSecurityPolicy or pod security context. This ensures the container runs with no capabilities, following the principle of least privilege. The correct syntax uses a YAML list (array) for the `drop` field, not a string.

Exam trap

The trap here is that candidates confuse the YAML syntax for dropping capabilities (must be a list) with a string value, or they think dropping a single capability like NET_RAW is sufficient to remove all capabilities. Also, note that PodSecurityPolicy is deprecated in Kubernetes 1.21 and removed in 1.25, so for newer clusters, use Pod Security Admission or a pod security context.

How to eliminate wrong answers

Option A is wrong because `drop: "ALL"` uses a string value instead of a list, which is invalid YAML syntax for the capabilities field; the Kubernetes API expects an array of strings. Option B is wrong because it only drops the `NET_RAW` capability, not all capabilities, leaving the container with other potentially dangerous capabilities. Option C is wrong because `add: ["ALL"]` adds all capabilities, which is the opposite of what the security admin wants and would grant maximum privileges.

Full explanation →

311

MCQmedium

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

A.Container runtime will not be able to pull images

B.The node will be unable to schedule pods

C.The kubelet will refuse to start

D.Kernel parameters may be modified, potentially reducing node security

AnswerD

Without --protect-kernel-defaults, kubelet does not enforce recommended kernel security settings.

Why this answer

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

Exam trap

The trap here is that candidates assume a missing security flag will cause an immediate failure (like kubelet not starting), when in reality the kubelet runs but the node becomes vulnerable to kernel parameter tampering.

How to eliminate wrong answers

Option A is wrong because the container runtime's ability to pull images depends on network connectivity and registry access, not on kernel parameter protection. Option B is wrong because pod scheduling is controlled by the scheduler and node conditions, not by the `--protect-kernel-defaults` flag; the node will still schedule pods. Option C is wrong because the kubelet will start without this flag; it only logs a warning or fails if the kernel parameters are not set correctly, but the flag itself does not prevent startup.

Full explanation →

312

MCQeasy

Which admission plugin should be used to enforce Pod Security Standards at the namespace level?

A.PodSecurity

B.PodSecurityPolicy

C.NodeRestriction

D.SecurityContextDeny

AnswerA

This plugin enforces Pod Security Standards.

Why this answer

The PodSecurity admission plugin is the successor to PodSecurityPolicy (PSP) and is designed specifically to enforce Pod Security Standards (PSS) at the namespace level. It evaluates pods against the three predefined PSS levels (privileged, baseline, restricted) based on labels set on the namespace, and can be configured in warn, audit, or enforce mode. This plugin is built into the kube-apiserver and is the recommended approach for pod security in Kubernetes v1.25 and later.

Exam trap

CNCF often tests the fact that PodSecurityPolicy is deprecated and removed, so candidates who studied older material may mistakenly choose PodSecurityPolicy, not realizing it has been replaced by the PodSecurity admission plugin.

How to eliminate wrong answers

Option B is wrong because PodSecurityPolicy (PSP) was deprecated in Kubernetes v1.21 and removed in v1.25, and it enforces security policies cluster-wide via a CRD, not at the namespace level using Pod Security Standards. Option C is wrong because NodeRestriction is an admission plugin that limits the Node API objects a kubelet can modify, and has nothing to do with pod security standards. Option D is wrong because SecurityContextDeny is an older admission plugin that rejects pods with certain security context settings, but it does not enforce the namespace-scoped Pod Security Standards and is not the recommended replacement for PSP.

Full explanation →

313

MCQmedium

An administrator wants to prevent the kubelet from serving anonymous requests. Which flag should be set on the kubelet?

A.--client-ca-file=/etc/kubernetes/pki/ca.crt

B.--authorization-mode=Webhook

C.--anonymous-auth=false

D.--authentication-token-webhook=true

AnswerC

This disables anonymous authentication on the kubelet.

Why this answer

The `--anonymous-auth=false` flag explicitly disables anonymous authentication on the kubelet, preventing unauthenticated requests from being processed. By default, anonymous authentication is enabled (`--anonymous-auth=true`), which allows any unauthenticated user to make requests to the kubelet API. Setting this flag to `false` ensures that only authenticated clients can interact with the kubelet, directly addressing the requirement to block anonymous requests.

Exam trap

The trap here is that candidates often confuse authentication with authorization—they think setting a client CA file or enabling webhook authorization will block anonymous requests, but those controls only affect already-authenticated users or authorization decisions, not the initial authentication step where anonymous access is allowed by default.

How to eliminate wrong answers

Option A is wrong because `--client-ca-file` configures the certificate authority used to validate client certificates for mutual TLS authentication, but it does not disable anonymous authentication—anonymous requests are still allowed unless explicitly blocked. Option B is wrong because `--authorization-mode=Webhook` sets the authorization mode to delegate authorization decisions to an external webhook, but it does not affect authentication; anonymous users can still be authenticated and then authorized. Option D is wrong because `--authentication-token-webhook=true` enables token-based authentication via a webhook, but it does not disable anonymous authentication—anonymous requests remain permitted unless `--anonymous-auth` is set to `false`.

Full explanation →

314

MCQeasy

Which kubectl command creates a secret named 'mysecret' from a file called 'credentials.json'?

A.kubectl create secret generic mysecret --from-file=credentials.json

B.kubectl apply -f credentials.json

C.kubectl create configmap mysecret --from-file=credentials.json

D.kubectl create secret tls mysecret --cert=credentials.json

AnswerA

The --from-file flag creates a secret from the contents of a file, using the filename as the key.

Why this answer

`kubectl create secret generic` is the command to create a generic (opaque) secret from a file. The `--from-file` flag reads the contents of `credentials.json` and stores them as the secret's data, using the filename as the key by default. This is the standard method for injecting sensitive file-based data into a Kubernetes secret.

Exam trap

Kubernetes often tests the distinction between `kubectl create secret generic` and `kubectl create secret tls`, and the trap here is that candidates may confuse the `--from-file` flag (for generic secrets) with the `--cert`/`--key` flags (for TLS secrets) or mistakenly use `kubectl apply` on a raw data file instead of a manifest.

How to eliminate wrong answers

Option B is wrong because `kubectl apply -f credentials.json` expects a valid Kubernetes manifest (YAML/JSON) defining a resource, not a raw data file like `credentials.json`. Option C is wrong because `kubectl create configmap` creates a ConfigMap, not a Secret; ConfigMaps store non-sensitive data, while Secrets are base64-encoded and intended for sensitive information. Option D is wrong because `kubectl create secret tls` is specifically for TLS certificates and requires `--cert` and `--key` flags pointing to PEM-encoded certificate and key files, not a generic JSON file.

Full explanation →

315

MCQhard

A container runs as non-root and needs to perform operations that require CAP_SYS_PTRACE. Which YAML snippet correctly adds only this capability while following the principle of least privilege?

A.securityContext: capabilities: add: ['SYS_PTRACE']

B.securityContext: capabilities: drop: ['ALL'] add: ['SYS_PTRACE']

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

D.securityContext: privileged: true

AnswerB

This drops all and adds only SYS_PTRACE.

Why this answer

It first drops all capabilities with `drop: ['ALL']` and then explicitly adds only `SYS_PTRACE`, ensuring the container runs with the minimum privileges required. This follows the principle of least privilege by removing any inherited or default capabilities before granting only the needed one. In Kubernetes, capabilities are Linux kernel capabilities; dropping all and adding only what is necessary is the recommended security practice.

Exam trap

CNCF often tests the misconception that simply adding a capability is sufficient, but the trap is that candidates forget to drop all other capabilities first, leaving the container with more privileges than intended.

How to eliminate wrong answers

Option A is wrong because it only adds `SYS_PTRACE` without dropping existing capabilities, meaning the container retains all default capabilities (e.g., CHOWN, DAC_OVERRIDE, FOWNER, etc.), violating the principle of least privilege. Option C is wrong because it drops all capabilities but does not add `SYS_PTRACE`, so the container would lack the required capability to perform ptrace operations. Option D is wrong because setting `privileged: true` grants all capabilities (including SYS_PTRACE) and disables most security constraints, which is excessive and violates least privilege.

Full explanation →

316

MCQmedium

An administrator runs kube-bench on a cluster node and receives failures for CIS benchmark checks related to kubelet configuration. Which kubelet flag should be set to ensure that kernel defaults are not used when they might be insecure?

A.--protect-kernel-defaults

B.--read-only-port=0

C.--anonymous-auth=false

D.--kubelet-extra-args

AnswerA

This flag is explicitly checked by kube-bench for CIS compliance.

Why this answer

The `--protect-kernel-defaults` kubelet flag ensures that the kubelet will not use insecure kernel defaults by enforcing that certain sysctl settings (e.g., `kernel.panic`, `vm.overcommit_memory`) are set to secure values. If these kernel parameters are not explicitly configured to safe values, the kubelet will fail to start, preventing the node from running with potentially insecure kernel defaults. This directly addresses CIS benchmark checks that require hardening of the kubelet's interaction with the host kernel.

Exam trap

The trap here is that candidates often confuse `--protect-kernel-defaults` with other kubelet security flags like `--read-only-port` or `--anonymous-auth`, or mistakenly think `--kubelet-extra-args` is a direct kubelet flag, when in fact it is a kubeadm configuration option and not a solution for kernel default protection.

How to eliminate wrong answers

Option B is wrong because `--read-only-port=0` disables the read-only port (10255) on the kubelet, which prevents unauthenticated access to kubelet metrics, but it does not address kernel default security. Option C is wrong because `--anonymous-auth=false` disables anonymous authentication to the kubelet API, which is a separate CIS check for authentication hardening, not for kernel defaults. Option D is wrong because `--kubelet-extra-args` is a kubeadm configuration field used to pass additional flags to the kubelet, not a kubelet flag itself, and it does not specifically enforce kernel default protection.

Full explanation →

317

Multi-Selecthard

Which THREE of the following practices help protect microservice applications against supply chain attacks? (Choose three.)

Select 3 answers

A.Use images from any public registry for flexibility

B.Use minimal base images (e.g., distroless or scratch) to reduce attack surface

C.Always use the latest tag to get the most recent patches

D.Scan images for vulnerabilities using tools like Trivy or Clair

E.Enable image verification using digital signatures (e.g., Notary or Cosign)

AnswersB, D, E

Smaller images have fewer packages that could contain vulnerabilities.

Why this answer

Using minimal base images like distroless or scratch significantly reduces the attack surface by eliminating unnecessary packages, libraries, and utilities that could contain vulnerabilities. This aligns with the principle of least functionality, as fewer components mean fewer potential entry points for an attacker to exploit in a supply chain attack.

Exam trap

CNCF often tests the misconception that using the latest tag is a safe practice for getting patches, when in fact it undermines supply chain security by breaking image immutability and reproducibility.

Full explanation →

318

MCQeasy

What is the purpose of the --audit-log-path flag on the kube-apiserver?

A.It sets the maximum number of audit log files to retain.

B.It disables audit logging.

C.It enables audit logging and sets the output file path.

D.It specifies the path to the audit policy file.

AnswerC

This flag enables audit logging and specifies the log file location.

Why this answer

The `--audit-log-path` flag on the kube-apiserver enables audit logging and specifies the file path where audit events are written. Without this flag, audit logging is disabled by default. Setting this flag is the first step to capturing API request logs for security monitoring and compliance.

Exam trap

CNCF often tests the distinction between `--audit-log-path` (enables logging and sets output path) and `--audit-policy-file` (defines what to log), causing candidates to confuse the two flags.

How to eliminate wrong answers

Option A is wrong because the `--audit-log-maxbackup` flag, not `--audit-log-path`, controls the maximum number of audit log files to retain. Option B is wrong because the `--audit-log-path` flag enables audit logging, not disables it; disabling audit logging is the default behavior when the flag is omitted. Option D is wrong because the path to the audit policy file is set by the `--audit-policy-file` flag, not `--audit-log-path`.

Full explanation →

319

Multi-Selectmedium

Which TWO of the following are valid ways to securely manage secrets in Kubernetes? (Choose two.)

Select 2 answers

A.Mount Kubernetes Secrets as volumes into the pod.

B.Use environment variables from the pod spec referencing Secret keys.

C.Use an external secrets manager like HashiCorp Vault integrated with the pod.

D.Pass secrets as command-line arguments to the container.

E.Store secrets in ConfigMaps with base64 encoded data.

AnswersA, C

Volume mounts are more secure than env vars.

Why this answer

Mounting Kubernetes Secrets as volumes into the pod ensures that secret data is stored in the pod's filesystem as files, which are created with in-memory tmpfs to avoid writing to disk. This approach leverages Kubernetes' native secret handling, where the secret data is base64-decoded and presented as plaintext files, and access can be controlled via RBAC and PodSecurityPolicies. It also supports automatic rotation when secrets are updated, provided the pod is restarted or the volume is remounted.

Exam trap

Kubernetes often tests the misconception that environment variables are a secure way to inject secrets, when in fact they are vulnerable to exposure through process introspection and logging, making volume mounts or external secret stores the recommended approaches.

Full explanation →

320

Multi-Selectmedium

Which TWO of the following are valid ways to reduce the attack surface of a Kubernetes node? (Select 2)

Select 2 answers

A.Load all kernel modules to support any workload

B.Restrict hostNetwork, hostPID, and hostIPC access from containers

C.Enable SSH access for all users for troubleshooting

D.Disable unnecessary system services on the node

E.Allow containers to run as root

AnswersB, D

These settings reduce a container's ability to access host resources.

Why this answer

Restricting hostNetwork, hostPID, and hostIPC access from containers is a valid way to reduce the attack surface of a Kubernetes node because it prevents containers from breaking out of their namespace isolation. When a container uses hostNetwork, it shares the node's network stack, potentially allowing it to sniff traffic or bind to privileged ports. Similarly, hostPID and hostIPC grant access to the host's process table and inter-process communication mechanisms, which can be leveraged for privilege escalation or information disclosure.

By default, these should be disabled unless absolutely necessary, as they directly expose host-level resources to the container.

Exam trap

CNCF often tests the misconception that loading all kernel modules is beneficial for compatibility, when in fact it violates the principle of minimizing the attack surface by only loading required modules.

Full explanation →

321

MCQeasy

What is the purpose of the CIS Kubernetes Benchmark?

A.To provide a set of security best practices for Kubernetes

B.To benchmark performance of Kubernetes clusters

C.To test network policies

D.To automate deployment of Kubernetes clusters

AnswerA

The CIS Benchmark outlines security recommendations.

Why this answer

The CIS Kubernetes Benchmark is a set of security best practices developed by the Center for Internet Security (CIS) specifically for hardening Kubernetes clusters. It provides prescriptive guidance on configuring cluster components (e.g., kube-apiserver, kubelet, etcd) to reduce the attack surface and meet compliance standards. Option A correctly identifies this purpose, as the benchmark is not about performance, networking, or automation.

Exam trap

The trap here is that candidates confuse the CIS Benchmark with a performance or automation tool, because 'benchmark' often implies performance testing in other contexts, but in Kubernetes security, it strictly refers to a compliance and hardening standard.

How to eliminate wrong answers

Option B is wrong because the CIS Kubernetes Benchmark focuses on security configuration, not performance benchmarking; performance metrics are measured by tools like the Kubernetes Performance and Scalability Working Group's benchmarks. Option C is wrong because while the benchmark includes recommendations for network policies, its scope is far broader, covering all aspects of cluster security (e.g., RBAC, secrets, pod security). Option D is wrong because the benchmark is a set of guidelines, not a deployment tool; automation of cluster deployment is handled by tools like kubeadm, Terraform, or Cluster API.

Full explanation →

322

MCQmedium

A Kubernetes cluster has Kyverno installed. You want to enforce that all container images come from a trusted registry 'trusted-registry.example.com'. Which Kyverno policy rule type would you use?

A.validate with a deny condition

B.mutate

C.validate.deny

D.generate

AnswerA

Using a validate rule with a deny condition can block pods that use images from unauthorized registries.

Why this answer

Kyverno's `validate` rule type with a `deny` condition is specifically designed to reject resources that violate a policy. In this case, the policy would deny any Pod that references an image not matching the pattern `trusted-registry.example.com/*`, enforcing the trusted registry requirement at admission time.

Exam trap

The trap here is that candidates confuse the `validate.deny` syntax (which does not exist) with the correct approach of using a `validate` rule containing a `deny` condition, often because other tools like OPA/Gatekeeper use a `deny` rule type directly.

How to eliminate wrong answers

Option B is wrong because `mutate` rules modify resources (e.g., prefixing an image registry) but do not block non-compliant resources; they cannot enforce a deny. Option C is wrong because `validate.deny` is not a valid Kyverno rule type; the correct syntax is `validate` with a `deny` condition under the `validationFailureAction` or `deny` block. Option D is wrong because `generate` rules create new resources (e.g., default NetworkPolicies) and have no capability to validate or deny existing resources.

Full explanation →

323

MCQhard

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

A.PodSecurityPolicy (deprecated)

B.ResourceQuota

C.ValidatingAdmissionPolicy

D.MutatingWebhookConfiguration

AnswerD

A mutating webhook can modify resources during admission, such as adding labels.

Why this answer

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

Exam trap

In the CNCF CKS exam, candidates often confuse MutatingAdmissionPolicy with ValidatingAdmissionPolicy. Remember that only mutating admission controllers can modify objects; ValidatingAdmissionPolicy only checks and rejects.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy is deprecated and does not add labels; it enforces security contexts. Option B is wrong because ResourceQuota limits resource consumption, not labels. Option C is wrong because ValidatingAdmissionPolicy only validates requests and cannot mutate objects to add labels.

Full explanation →

324

Multi-Selectmedium

Which THREE of the following are features of container sandboxing solutions like gVisor or Kata Containers?

Select 3 answers

A.They are compatible with the OCI runtime specification

B.They improve container performance over native runc

C.They can be used with RuntimeClass to select the sandbox runtime per pod

D.They provide an additional layer of isolation between containers and the host kernel

E.They use the host kernel directly for all system calls

AnswersA, C, D

Both gVisor (runsc) and Kata Containers implement the OCI runtime spec.

Why this answer

Both gVisor and Kata Containers implement the OCI (Open Container Initiative) runtime specification, which allows them to be used as drop-in replacements for runc. This compatibility ensures that container images and tools like containerd can interface with these sandboxed runtimes without modification, as they expose the same runtime lifecycle commands (create, start, delete).

Exam trap

The CKS exam often tests the misconception that sandboxing improves performance, when in reality the added isolation layer (user-space kernel or VM) introduces latency and resource overhead compared to native runc.

Full explanation →

325

MCQmedium

A Falco rule is configured to detect privilege escalation via setuid binaries. Which syscall is commonly associated with this activity?

A.connect

B.setuid

C.open

D.execve

AnswerB

Correct. The setuid syscall changes the user ID of the process, commonly used in privilege escalation attacks.

Why this answer

The setuid syscall is used to change the user ID of the current process, which is a common method for privilege escalation. Falco rules often monitor setuid and setgid syscalls to detect such activity. Option A (connect) is a network syscall.

Option C (open) is a file operation syscall. Option D (execve) is used to execute a new program, but the direct privilege escalation is via setuid.

Full explanation →

326

MCQmedium

You want to enable mutual TLS (mTLS) between services in a namespace using Istio. Which custom resource should you configure to enforce STRICT mTLS for all workloads in the namespace?

A.DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL

B.VirtualService with tls.mode: SIMPLE

C.PeerAuthentication with mtls.mode: STRICT

D.ServiceEntry with resolution: NONE

AnswerC

PeerAuthentication enforces mTLS on inbound traffic; STRICT mode requires mutual TLS.

Why this answer

PeerAuthentication is the Istio custom resource specifically designed to define traffic authentication policies between workloads. Setting `mtls.mode: STRICT` enforces that all traffic in the namespace must use mutual TLS (mTLS), rejecting any plain-text or non-mTLS connections. This is the standard way to enforce STRICT mTLS at the namespace level in Istio.

Exam trap

The trap here is confusing DestinationRule's `trafficPolicy.tls.mode: ISTIO_MUTUAL` with PeerAuthentication's `mtls.mode: STRICT`; candidates often mistakenly think DestinationRule enforces mTLS, but it only configures TLS for outbound traffic, not inbound authentication enforcement.

How to eliminate wrong answers

Option A is wrong because DestinationRule controls traffic routing and load balancing policies, not authentication; its `trafficPolicy.tls.mode: ISTIO_MUTUAL` only configures TLS settings for outbound connections to a specific host, not enforcing mTLS on inbound traffic. Option B is wrong because VirtualService is used for traffic routing and manipulation, not authentication; `tls.mode: SIMPLE` is not a valid field in VirtualService and does not relate to mTLS enforcement. Option D is wrong because ServiceEntry is used to register external services into the mesh, not to enforce authentication policies; `resolution: NONE` controls DNS resolution, not TLS mode.

Full explanation →

327

MCQmedium

You suspect a pod is making unexpected outbound connections. Which tool can you use to inspect network connections from within the container?

A.kubectl port-forward

B.crictl exec

C.falco

D.kubectl logs

AnswerB

crictl exec can run ss or netstat inside the container.

Why this answer

`crictl exec` allows you to run commands inside a container managed by CRI-compatible runtimes (like containerd), enabling you to inspect network connections from within the container using tools like `ss`, `netstat`, or `ip`. This is the direct method to check outbound connections from the container's network namespace, which is isolated from the host.

Exam trap

The trap here is that candidates may choose `kubectl logs` thinking it shows network activity, but logs only capture application output, not kernel-level connection states, while `crictl exec` provides direct access to the container's network namespace.

How to eliminate wrong answers

Option A is wrong because `kubectl port-forward` is used to forward local ports to a pod for debugging or accessing applications, not to inspect network connections from within the container. Option C is wrong because Falco is a runtime security tool that monitors system calls and detects anomalous behavior at the host level, but it does not provide an interactive shell to inspect connections from inside the container. Option D is wrong because `kubectl logs` retrieves container logs (stdout/stderr), which typically do not contain real-time network connection information unless the application explicitly logs them.

Full explanation →

328

MCQmedium

An admin runs 'kubectl auth reconcile -f rbac.yaml' and gets an error that the user does not have permission to create ClusterRoleBindings. What is the most likely cause?

A.The ClusterRoleBinding already exists.

B.The YAML file has a syntax error.

C.The Kubernetes API server is not reachable.

D.The user's kubeconfig context does not have RBAC permissions to create ClusterRoleBindings.

AnswerD

The error indicates insufficient permissions; the user needs a ClusterRoleBinding that grants the necessary permissions.

Why this answer

The error indicates that the user's current kubeconfig context lacks RBAC permissions to create ClusterRoleBindings. The `kubectl auth reconcile` command attempts to apply the RBAC resources defined in the YAML file, and if the user's credentials (typically from a certificate or token) do not include the `create` verb on `clusterrolebindings` in the RBAC authorization layer, the API server will reject the request with a 403 Forbidden error. This is a direct permission issue, not a connectivity or syntax problem.

Exam trap

The trap here is that candidates may confuse a permission error with a resource conflict (Option A) or a connectivity issue (Option C), but the specific error message 'does not have permission to create ClusterRoleBindings' directly points to insufficient RBAC privileges in the current kubeconfig context.

How to eliminate wrong answers

Option A is wrong because if the ClusterRoleBinding already exists, `kubectl auth reconcile` would attempt to update it (which requires `update` permission), but the error specifically mentions lack of permission to `create`, not a conflict error like 'AlreadyExists'. Option B is wrong because a syntax error in the YAML file would produce a parsing error from kubectl (e.g., 'error converting YAML to JSON'), not an RBAC permission error. Option C is wrong because if the API server were unreachable, the error would be a connection timeout or 'Unable to connect to the server', not a permission-denied message.

Full explanation →

329

Multi-Selectmedium

Which TWO actions should be taken to secure etcd in a Kubernetes cluster?

Select 2 answers

A.Enable TLS authentication for etcd peer and client communication

B.Run etcd as a DaemonSet to ensure high availability

C.Disable client certificate authentication for etcd

D.Enable the NodeRestriction admission plugin on etcd

E.Restrict access to etcd using network policies or firewall rules

AnswersA, E

TLS ensures encrypted and authenticated communication.

Why this answer

Enabling TLS authentication for etcd peer and client communication ensures that all data in transit between etcd members and between etcd and the Kubernetes API server is encrypted and mutually authenticated. This prevents man-in-the-middle attacks and unauthorized access to the cluster's state store, which is a critical requirement for securing etcd as per the CIS Kubernetes Benchmark.

Exam trap

CNCF often tests the misconception that admission plugins like NodeRestriction apply to etcd, when in fact they are exclusively API server components and have no role in securing the etcd datastore itself.

Full explanation →

330

MCQeasy

A security engineer wants to ensure that only images signed with a specific key are allowed to run in the cluster. Which tool can be used to sign container images?

A.kubesec

B.syft

C.cosign

D.trivy

AnswerC

Cosign supports signing container images and verifying signatures.

Why this answer

Cosign is the correct tool because it is specifically designed for signing and verifying container images using cryptographic keys, integrating directly with OCI-compliant registries. It supports keyless signing via Fulcio and transparency logs via Rekor, making it the standard choice for enforcing image signature verification in Kubernetes admission controllers like Kyverno or OPA.

Exam trap

CNCF often tests the distinction between image scanning (Trivy, Syft) and image signing (Cosign), so candidates mistakenly choose a vulnerability scanner or SBOM tool when the question explicitly asks for signing.

How to eliminate wrong answers

Option A is wrong because kubesec is a static analysis tool that evaluates Kubernetes resource manifests against security best practices, not a tool for signing container images. Option B is wrong because syft is a software bill of materials (SBOM) generator that produces dependency lists from container images, not a signing tool. Option D is wrong because trivy is a vulnerability scanner for container images, filesystems, and Git repositories, and does not provide image signing capabilities.

Full explanation →

331

MCQmedium

You are tasked with enabling audit logging for the Kubernetes API server. Which API server flag must be used to specify the audit log file path?

A.--audit-log-path

B.--audit-log-dir

C.--audit-policy-file

D.--audit-log-file

AnswerA

This flag sets the path for the audit log file.

Why this answer

The `--audit-log-path` flag is the correct API server flag to specify the file path where audit logs are written. This flag defines the absolute or relative path to the audit log file, and the kube-apiserver will create or append to that file. Without this flag, no audit log file is generated, even if an audit policy is configured.

Exam trap

CNCF often tests the exact flag name `--audit-log-path` versus the plausible but incorrect `--audit-log-file`, exploiting the common assumption that the flag would be named after the file rather than the path.

How to eliminate wrong answers

Option B is wrong because `--audit-log-dir` is not a valid kube-apiserver flag; the correct flag for specifying the directory is `--audit-log-path`, which can include a directory path as part of the filename. Option C is wrong because `--audit-policy-file` specifies the path to the audit policy YAML file that defines which events to log, not the log file path itself. Option D is wrong because `--audit-log-file` is not a valid flag; the correct flag name is `--audit-log-path`.

Full explanation →

332

Multi-Selectmedium

Which TWO tools can generate an SBOM for a container image? (Select two.)

Select 2 answers

A.checkov

B.trivy

C.syft

D.cosign

E.kubesec

AnswersB, C

Trivy can generate SBOMs in CycloneDX or SPDX format.

Why this answer

Trivy is a comprehensive vulnerability scanner that can generate an SBOM (Software Bill of Materials) for container images using its `trivy image --format cyclonedx` or `trivy image --format spdx` commands, outputting in CycloneDX or SPDX formats. Syft is a dedicated SBOM generation tool from Anchore that produces detailed SBOMs from container images using `syft packages <image>` and supports multiple output formats including CycloneDX and SPDX. Both tools are specifically designed to inventory all software components within a container image, making them correct choices for SBOM generation.

Exam trap

The CNCF CKS exam often tests the distinction between tools that generate SBOMs (Trivy, Syft) versus tools that scan for vulnerabilities (Trivy can do both, but the question specifically asks for SBOM generation) or perform other supply chain tasks like signing (Cosign) or IaC scanning (Checkov), leading candidates to confuse a tool's primary function with its secondary capabilities.

Full explanation →

333

Multi-Selecteasy

An auditor requires that all audit logs from the Kubernetes API server be stored for 90 days and be tamper-proof. Which TWO measures should be implemented?

Select 2 answers

A.Configure the audit log backend to write to an immutable object store like S3 with Object Lock

B.Enable the AuditDynamicConfiguration feature gate

C.Deploy Fluentd to forward logs to a central Elasticsearch cluster

D.Set the API server flag --audit-log-maxage=90

E.Set --audit-log-maxbackup=10 and --audit-log-maxsize=100

AnswersA, D

Immutable storage prevents log modification or deletion.

Why this answer

Storing audit logs in an immutable object store like S3 with Object Lock ensures tamper-proof retention by preventing any object from being overwritten or deleted for a specified retention period. This directly satisfies the auditor's requirement for logs that cannot be altered or destroyed, regardless of the Kubernetes cluster state.

Exam trap

CNCF often tests the distinction between log rotation/retention settings (like --audit-log-maxage) and true immutability features, leading candidates to incorrectly select options that only manage log file age without preventing tampering.

Full explanation →

334

MCQeasy

What is the default authorization mode for a new Kubernetes cluster?

A.ABAC

B.Node

C.AlwaysDeny

D.RBAC

AnswerD

RBAC is the default in most modern distributions.

Why this answer

RBAC (Role-Based Access Control) is the default authorization mode for new Kubernetes clusters since version 1.8. When you initialize a cluster with kubeadm, the API server is automatically configured with the `--authorization-mode=RBAC` flag, enabling fine-grained access control based on roles and bindings.

Exam trap

CNCF often tests the misconception that ABAC is the default because it was the original authorization mode in early Kubernetes versions, but RBAC has been the default since v1.8 and is the recommended standard for security.

How to eliminate wrong answers

Option A is wrong because ABAC (Attribute-Based Access Control) is not the default; it requires manual configuration with `--authorization-mode=ABAC` and a policy file, and it is less secure and harder to manage than RBAC. Option B is wrong because Node authorization is a special-purpose mode used to authorize kubelet API requests, not the default for the entire cluster; it is typically combined with other modes like RBAC. Option C is wrong because AlwaysDeny is a legacy mode that denies all requests and is not used in production; it was removed in Kubernetes 1.10 and is never the default.

Full explanation →

335

MCQhard

During a security audit, a team discovers that their microservice application, deployed on Kubernetes, is vulnerable to container breakout attacks. The containers run as root and have many Linux capabilities. Which set of Pod Security Standards (PSS) enforcement modes and policies would best mitigate this risk?

A.Use 'privileged' PSS with Warn mode

B.Use 'baseline' PSS with Audit mode

C.Use 'restricted' PSS with Enforce mode

D.Use 'baseline' PSS with Enforce mode

AnswerC

Restricted profile requires non-root and drops all capabilities except net bind service.

Why this answer

The 'restricted' Pod Security Standard with 'Enforce' mode is the correct choice because it mandates the most stringent security controls, including dropping all Linux capabilities and preventing containers from running as root. This directly mitigates container breakout attacks by eliminating the excessive privileges that enable such exploits. 'Enforce' mode actively blocks non-compliant pods, ensuring the policy is applied without relying on user awareness or audit logs.

Exam trap

CNCF often tests the misconception that 'baseline' PSS is sufficient for most security needs, but the trap here is that 'baseline' still allows root and default capabilities, which are exactly the vectors exploited in container breakout attacks, making 'restricted' the only adequate choice for this specific risk.

How to eliminate wrong answers

Option A is wrong because 'privileged' PSS is the least restrictive policy, allowing all capabilities and root access, which would not mitigate breakout risks; 'Warn' mode only alerts but does not block non-compliant pods. Option B is wrong because 'baseline' PSS allows some default capabilities and does not enforce dropping all capabilities or preventing root, and 'Audit' mode only logs violations without enforcement. Option D is wrong because while 'baseline' PSS with 'Enforce' mode blocks some obvious misconfigurations, it still permits containers to run as root and retains default capabilities, leaving significant breakout vectors unaddressed.

Full explanation →

336

MCQeasy

Which admission plugin is recommended by the CIS Kubernetes Benchmark to restrict the kubelet's ability to modify nodes?

A.NodeRestriction

B.PodNodeSelector

C.SecurityContextDeny

D.AlwaysPullImages

AnswerA

NodeRestriction ensures kubelets can only modify their own node objects.

Why this answer

The NodeRestriction admission plugin is recommended by the CIS Kubernetes Benchmark to restrict the kubelet's ability to modify nodes. It limits the kubelet's permissions to only modify its own node and its own pods, preventing it from altering other nodes or performing unauthorized operations. This plugin enforces a security boundary by rejecting requests that attempt to modify node labels, taints, or status outside the kubelet's assigned scope.

Exam trap

The trap here is that candidates often confuse admission plugins that control pod security (like SecurityContextDeny or PodNodeSelector) with the specific plugin that restricts kubelet node modification, leading them to pick a security-focused option that does not address the kubelet's API access.

How to eliminate wrong answers

Option B (PodNodeSelector) is wrong because it enforces namespace-level pod node selector constraints, not kubelet node modification restrictions. Option C (SecurityContextDeny) is wrong because it rejects pods with certain security context settings, such as privileged containers, but does not limit kubelet actions on nodes. Option D (AlwaysPullImages) is wrong because it forces image pull policy to Always for every pod, addressing image freshness and security, not kubelet node modification control.

Full explanation →

337

MCQeasy

A cluster administrator wants to monitor network traffic between pods for security analysis. Which tool is designed specifically for this purpose and integrates with Kubernetes?

A.Configure Fluentd to collect network logs from each node.

B.Use Prometheus to scrape network metrics from kube-proxy.

C.Run kube-bench to audit network policies.

D.Deploy Cilium with Hubble for network flow visibility.

AnswerD

Cilium/Hubble provides pod-level network monitoring.

Why this answer

D is correct because Cilium, combined with Hubble, is specifically designed to provide deep network flow visibility and monitoring for Kubernetes pods. Hubble leverages eBPF to capture and report network traffic at the kernel level, offering granular observability into pod-to-pod communications, which directly meets the requirement for security analysis of network traffic between pods.

Exam trap

The trap here is that candidates may confuse general monitoring tools (Fluentd, Prometheus) or security auditing tools (kube-bench) with a purpose-built network flow visibility solution like Cilium/Hubble, which is the only option that directly addresses pod-to-pod traffic monitoring for security analysis.

How to eliminate wrong answers

Option A is wrong because Fluentd is a log collector and aggregator, not a network traffic monitoring tool; it collects log files (e.g., from containers or applications) but does not capture or analyze network flows between pods. Option B is wrong because Prometheus scrapes metrics (e.g., from kube-proxy for iptables rules or service endpoints) but does not provide real-time network flow visibility or capture individual packet-level communications between pods. Option C is wrong because kube-bench is a compliance auditor that checks Kubernetes clusters against CIS benchmarks, focusing on configuration security, not on monitoring live network traffic between pods.

Full explanation →

338

MCQhard

A cluster administrator wants to prevent all containers in a namespace from running with the NET_RAW capability. They plan to use a PodSecurityPolicy (PSP) but PSP is deprecated. Which approach should they use instead?

A.Apply a PodSecurity admission label with 'pod-security.kubernetes.io/enforce: privileged'

B.Apply a PodSecurity admission label with 'pod-security.kubernetes.io/enforce: restricted'

C.Apply a PodSecurity admission label with 'pod-security.kubernetes.io/enforce: baseline'

D.Use a PodSecurityPolicy with 'requiredDropCapabilities: [NET_RAW]'

AnswerC

Baseline policy drops NET_RAW and other dangerous capabilities while being less restrictive than restricted.

Why this answer

The 'baseline' PodSecurity standard enforces the minimum restrictions that prevent privilege escalation, including dropping the NET_RAW capability by default. The 'baseline' profile is designed to be applied to namespaces where most workloads run, and it automatically adds NET_RAW to the required drop capabilities list, which directly addresses the administrator's goal without the overhead of the more restrictive 'restricted' profile.

Exam trap

CNCF often tests the distinction between the three PodSecurity standards, and the trap here is that candidates may choose 'restricted' (option B) because it is the most secure, but the question only requires dropping NET_RAW, which is already covered by the 'baseline' profile without imposing unnecessary restrictions like requiring non-root users or seccomp profiles.

How to eliminate wrong answers

Option A is wrong because the 'privileged' PodSecurity standard allows all capabilities, including NET_RAW, and does not enforce any capability drops, so it would not prevent containers from running with NET_RAW. Option B is wrong because the 'restricted' standard is overly restrictive for many workloads (e.g., it requires running as non-root, seccomp profiles, and dropping all capabilities), and while it would drop NET_RAW, it imposes additional constraints that are not necessary for the stated requirement. Option D is wrong because PodSecurityPolicy (PSP) is deprecated in Kubernetes v1.21 and removed in v1.25, and the question explicitly states that PSP is deprecated, so using it is not the recommended approach; the correct replacement is PodSecurity admission with the 'baseline' profile.

Full explanation →

339

MCQeasy

Which Kubernetes resource can be used to enforce that a container's filesystem is read-only?

A.ResourceQuota

B.PodSecurityPolicy

C.SecurityContext

D.NetworkPolicy

AnswerC

SecurityContext with readOnlyRootFilesystem: true makes the container filesystem read-only.

Why this answer

The SecurityContext at the container level has a 'readOnlyRootFilesystem' field. When set to true, the container's root filesystem is read-only.

Full explanation →

340

MCQmedium

An administrator wants to use gVisor to sandbox containers in a Kubernetes cluster. Which resource must be created to enable this?

A.RuntimeClass with handler: runsc

B.DaemonSet to install gVisor on nodes

C.PodSecurityPolicy with gVisor enabled

D.SecurityContext with runtime: gvisor

AnswerA

RuntimeClass allows selecting a container runtime. gVisor's runsc is specified as the handler.

Why this answer

To use gVisor as a container runtime sandbox in Kubernetes, you must create a RuntimeClass resource with the handler set to 'runsc'. This tells the kubelet which runtime handler to use when running pods that reference this RuntimeClass, enabling gVisor's user-space kernel (runsc) to intercept and sandbox system calls.

Exam trap

The CKS exam often tests the distinction between installing a runtime (DaemonSet) and enabling it via a Kubernetes API object (RuntimeClass), leading candidates to confuse node-level setup with cluster-level resource creation.

How to eliminate wrong answers

Option B is wrong because a DaemonSet can install gVisor binaries on nodes, but the actual enablement requires a RuntimeClass to select the runsc handler at pod creation time. Option C is wrong because PodSecurityPolicy (deprecated in 1.21) controls security contexts and admission, not runtime selection; gVisor is not a PSP feature. Option D is wrong because SecurityContext does not have a 'runtime' field; runtime selection is done via RuntimeClass, not via pod security context settings.

Full explanation →

341

MCQmedium

A team wants to use an external secret manager (HashiCorp Vault) to inject secrets into pods. Which approach is most aligned with Kubernetes best practices?

A.Use a ConfigMap to mount secrets as files

B.Store secrets as environment variables in the pod spec

C.Use kubectl exec to copy secrets into the container at startup

D.Use a mutating webhook that injects a sidecar container to fetch secrets and mount them as volumes

AnswerD

This approach securely injects secrets without exposing them in the pod spec.

Why this answer

It follows the Kubernetes best practice of using a mutating admission webhook to inject a sidecar container (e.g., Vault Agent or Bank-Vaults) that authenticates with HashiCorp Vault, fetches secrets, and mounts them as volumes into the pod. This approach avoids storing secrets in etcd (as ConfigMaps or environment variables do) and eliminates the need for manual secret injection, aligning with the principle of least privilege and dynamic secret management.

Exam trap

The CKS exam often tests the misconception that ConfigMaps or environment variables are acceptable for secrets, but the exam emphasizes that any secret stored in etcd (even if base64-encoded) is not secure, and the only best-practice approach is to use external secret stores with sidecar injection or CSI drivers.

How to eliminate wrong answers

Option A is wrong because ConfigMaps store data in etcd in plaintext (unless encrypted at rest) and are not designed for secret management; they are for non-confidential configuration data. Option B is wrong because storing secrets as environment variables in the pod spec exposes them in the pod’s spec (visible via kubectl describe) and in etcd, and they can be leaked through process listings or logs. Option C is wrong because using kubectl exec to copy secrets into a container at startup is an insecure, manual, and non-scalable practice that violates the principle of immutable infrastructure and leaves secrets in the container filesystem without proper lifecycle management.

Full explanation →

342

MCQmedium

You are investigating a security incident where a container ran a shell inside a pod. Which Falco rule condition would trigger on a shell spawned in a container?

A.evt.type=clone and proc.name = 'shell'

B.evt.type=execve and proc.name contains 'sh'

C.proc.name in (sh, bash)

D.container.id != host and proc.name = shell

AnswerC

Correct: Falco conditions check process names to detect shell execution.

Why this answer

Falco rules use syscalls and process names to detect events. The condition 'proc.name in (sh, bash)' correctly matches processes named 'sh' or 'bash', which are common shells spawned in containers. Option A is incorrect because 'clone' is not the typical syscall for shell execution (execve is used).

Option B is incorrect because 'proc.name contains sh' would match any process with 'sh' in its name (e.g., 'sshd'), leading to false positives. Option D is incorrect because 'container.id != host' is unnecessary and 'proc.name = shell' does not match typical shell names like sh or bash.

Full explanation →

343

Multi-Selectmedium

Which TWO of the following are valid ways to enforce that containers cannot run as root in a Kubernetes cluster? (Select TWO.)

Select 2 answers

A.Create a Gatekeeper Constraint that requires runAsNonRoot

B.Use a NetworkPolicy to block root containers

C.Set the kubelet flag --run-non-root

D.Enable the PodSecurity admission controller with the 'restricted' profile

E.Use a ServiceAccount to restrict root

AnswersA, D

Correct. Gatekeeper can enforce arbitrary policies.

Why this answer

Gatekeeper, using the Open Policy Agent (OPA) framework, can enforce custom policies via ConstraintTemplates. A Constraint requiring `runAsNonRoot: true` in the Pod security context ensures containers cannot run as root, providing a flexible, admission-time control that works across all namespaces.

Exam trap

The exam often tests the distinction between network-layer controls (NetworkPolicy) and identity objects (ServiceAccount) versus admission controllers that enforce security contexts, leading candidates to overestimate the scope of NetworkPolicies or ServiceAccounts.

Full explanation →

344

Multi-Selecthard

Which THREE of the following are valid ways to enforce mTLS in an Istio service mesh? (Select 3)

Select 3 answers

A.DestinationRule with trafficPolicy.tls.mode set to ISTIO_MUTUAL

B.PeerAuthentication with mTLS mode set to STRICT

C.ServiceEntry with mTLS enabled for external services

D.AuthorizationPolicy with deny rules for non-mTLS traffic

E.NetworkPolicy with ingress rules to allow only TLS traffic

AnswersA, B, C

Configures client-side mTLS for traffic to a specific host.

Why this answer

A DestinationRule with `trafficPolicy.tls.mode` set to `ISTIO_MUTUAL` explicitly enforces mutual TLS for traffic to a specific host or subset, overriding the mesh-wide default. This ensures that both the client and server present certificates, providing strong identity-based authentication and encryption.

Exam trap

CNCF often tests the distinction between mTLS enforcement (which requires proxy-level TLS configuration) and reactive policies (like AuthorizationPolicy) that only filter based on mTLS metadata, leading candidates to mistakenly select options that merely check for mTLS rather than enforce it.

Full explanation →

345

MCQeasy

Which command is used to sign a container image with Cosign?

A.cosign attest

B.cosign sign

C.cosign generate

D.cosign verify

AnswerB

cosign sign signs a container image.

Why this answer

The `cosign sign` command is used to sign container images and other artifacts, creating a digital signature that is stored alongside the image in the registry. This signature can later be verified with `cosign verify` to ensure the image's integrity and origin. The other options serve different purposes: `cosign attest` attaches an in-toto attestation, `cosign generate` creates key pairs, and `cosign verify` checks signatures.

Exam trap

A common pitfall on the CKS exam is confusing `cosign sign` (which creates a signature) with `cosign attest` (which creates an in-toto attestation) or `cosign verify` (which checks a signature). Candidates must remember that `sign` is the action that produces the cryptographic signature, while `verify` and `attest` are separate operations.

How to eliminate wrong answers

Option A is wrong because `cosign attest` is used to create an in-toto attestation (a signed statement about the image's build process or metadata), not to sign the image itself. Option C is wrong because `cosign generate` generates a key pair for signing, but does not perform the signing operation. Option D is wrong because `cosign verify` is used to validate an existing signature, not to create one.

Full explanation →

346

MCQhard

A cluster uses Kubernetes v1.24 with Pod Security Admission enabled. The cluster administrator wants to enforce that all pods in the 'production' namespace run with the 'restricted' policy level, but some existing deployments use privileged containers. Which approach ensures that only new pods violating the policy are rejected, while existing pods continue to run?

A.Patch existing deployments to remove privileged containers, then add the label 'pod-security.kubernetes.io/enforce=restricted' to the namespace.

B.Add the namespace label 'pod-security.kubernetes.io/enforce=restricted' and leave existing pods unchanged; new pods violating the policy will be rejected.

C.Create a PodSecurityPolicy that restricts privileged containers and bind it to all service accounts in the namespace.

D.Set the namespace label 'pod-security.kubernetes.io/enforce=restricted' and use the 'inform' mode to allow existing pods.

AnswerB

Correctly enforces the policy on new pods without affecting existing ones.

Why this answer

Pod Security Admission (PSA) in Kubernetes v1.24 enforces policies via namespace labels. Setting `pod-security.kubernetes.io/enforce=restricted` on the 'production' namespace will reject any new pod that violates the restricted policy, but existing pods are not re-evaluated and continue running. This behavior is by design: PSA evaluates pods at creation or update time, not retroactively, so existing workloads are unaffected.

Exam trap

The trap here is that candidates confuse Pod Security Admission with the deprecated PodSecurityPolicy, or assume that setting an enforce label will retroactively terminate existing pods, when in fact PSA only applies to new or updated pods.

How to eliminate wrong answers

Option A is wrong because patching existing deployments to remove privileged containers is unnecessary and contradicts the requirement to let existing pods continue running; PSA does not require modifying existing workloads. Option C is wrong because PodSecurityPolicy (PSP) was deprecated in Kubernetes v1.21 and removed in v1.25, and the question specifies v1.24 with Pod Security Admission enabled, making PSP irrelevant and non-functional. Option D is wrong because setting the label to 'enforce=restricted' already enforces the policy; 'inform' mode would only log violations without rejecting pods, which does not meet the requirement to reject new violating pods.

Full explanation →

347

MCQmedium

An OPA/Gatekeeper constraint requires that all images' registries match a pattern. A Deployment uses 'myregistry.io/app:v1'. The admission controller rejects it. The admin runs 'kubectl get constraints' and sees the constraint is active. What is the next debugging step?

A.Disable the Gatekeeper webhook

B.Check the audit logs of Gatekeeper

C.Reapply the Deployment YAML

D.Describe the constraint and constraint template to see the denial reason

AnswerD

Describing shows violations and reasons.

Why this answer

When a Gatekeeper constraint is active but a resource is rejected, the next debugging step is to describe the constraint and its associated constraint template. The constraint template contains the Rego policy logic, and describing both objects reveals the specific denial reason, such as a pattern mismatch or a violation of the allowed registries list. This provides the exact error message from the OPA engine, enabling targeted troubleshooting without disabling or bypassing the admission controller.

Exam trap

The trap here is that candidates may think audit logs (Option B) are the primary source for real-time admission denials, when in fact the denial reason is embedded in the constraint’s status and admission response, not in periodic audit reports.

How to eliminate wrong answers

Option A is wrong because disabling the Gatekeeper webhook would bypass all policy enforcement, which is not a debugging step but a dangerous workaround that defeats the purpose of admission control. Option B is wrong because Gatekeeper audit logs are used for periodic compliance checks and reporting, not for real-time admission request denials; the denial reason is returned in the admission response and stored in the constraint status. Option C is wrong because reapplying the same Deployment YAML will not change the outcome if the constraint is active and the image registry does not match the allowed pattern; it would simply trigger the same rejection.

Full explanation →

348

MCQmedium

An administrator runs kube-bench and receives a failing result for CIS control 1.1.1. What does this control typically check?

A.That the API server pod specification file permissions are set to 644 or more restrictive

B.That etcd is using TLS

C.That the API server audit log path is configured

D.That anonymous authentication is disabled on the API server

AnswerA

This is the check for control 1.1.1.

Why this answer

CIS control 1.1.1 specifically checks that the API server pod specification file (typically /etc/kubernetes/manifests/kube-apiserver.yaml) has permissions set to 644 or more restrictive (e.g., 600 or 640). This ensures that only authorized users (root or the kube-apiserver process) can read or modify the file, preventing unauthorized changes to critical API server configuration.

Exam trap

CNCF often tests candidates' ability to map CIS control numbers to their exact checks, so the trap here is that candidates confuse control 1.1.1 (file permissions) with other common API server hardening controls like TLS, audit logging, or authentication settings.

How to eliminate wrong answers

Option B is wrong because etcd TLS configuration is covered under a different CIS control (e.g., 2.1 or 2.2), not 1.1.1. Option C is wrong because API server audit log path configuration is checked under CIS control 1.2.1 or similar audit-related controls, not 1.1.1. Option D is wrong because disabling anonymous authentication on the API server is a separate control (e.g., 1.2.3 or 1.2.4), not part of control 1.1.1 which focuses on file permissions.

Full explanation →

349

Multi-Selecteasy

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

Select 2 answers

A.Set --cors-allowed-origins=* for easy access.

B.Disable TLS to improve performance.

C.Enable audit logging.

D.Set --insecure-port=8080 to allow non-TLS access.

E.Set --anonymous-auth=false.

AnswersC, E

Audit logs help detect and investigate suspicious activities.

Why this answer

Enabling audit logging on the API server records all requests to the cluster, providing an immutable record for security monitoring, incident response, and compliance. Audit logs are essential for detecting unauthorized access attempts, misconfigurations, and policy violations, and are a core requirement for Kubernetes security hardening.

Exam trap

CNCF often tests the misconception that disabling security features (like TLS or authentication) improves performance or simplifies access, when in fact these actions directly violate the principle of defense in depth and are explicitly discouraged in Kubernetes security best practices.

Full explanation →

350

Multi-Selecteasy

Which TWO of the following are tools that can be used to generate an SBOM for a container image?

Select 2 answers

A.Trivy

B.Cosign

C.Syft

D.Clair

E.Kubesec

AnswersA, C

Trivy can generate SBOMs in addition to vulnerability scanning.

Why this answer

Trivy is a comprehensive vulnerability scanner that can also generate Software Bill of Materials (SBOM) for container images. It supports multiple output formats such as CycloneDX and SPDX, making it a valid tool for SBOM generation. Syft is specifically designed to generate SBOMs from container images and filesystems, producing output in formats like CycloneDX, SPDX, and Syft's own JSON format.

Both tools are widely used in supply chain security workflows.

Exam trap

The CKS exam often tests the distinction between tools that generate SBOMs (like Syft and Trivy) versus tools that consume, sign, or attach SBOMs (like Cosign), causing candidates to confuse signing capabilities with SBOM generation.

Full explanation →

351

MCQmedium

A security engineer wants to integrate image scanning into a CI/CD pipeline. They are using a tool that can scan the filesystem of the build context before building the image. Which tool is best suited for this purpose?

A.Trivy (trivy fs)

B.Kubesec

C.Notary

D.Cosign

AnswerA

trivy fs scans the filesystem for vulnerabilities, ideal for scanning a build context.

Why this answer

Trivy's `fs` subcommand scans the filesystem of a build context (directory) for vulnerabilities and misconfigurations before the container image is built. This allows the security engineer to catch issues early in the CI/CD pipeline, such as vulnerable application dependencies or insecure configurations in Dockerfiles, without needing a built image. Trivy is purpose-built for this filesystem scanning use case, making it the correct choice.

Exam trap

The CKS exam often tests the distinction between tools that scan build context filesystems (like Trivy fs) versus tools that scan built container images (like Trivy image or Grype), causing candidates to confuse the pipeline stage where each tool applies.

How to eliminate wrong answers

Option B is wrong because Kubesec is a static analysis tool for Kubernetes resource manifests (YAML/JSON), not for scanning filesystem contents or build contexts. Option C is wrong because Notary is a tool for signing and verifying container image metadata (using TUF framework), not for scanning filesystems. Option D is wrong because Cosign is a tool for signing and verifying container image signatures (part of Sigstore), not for scanning build context filesystems.

Full explanation →

352

MCQeasy

Which Pod Security Standard level allows the most relaxed security controls?

A.restricted

B.default

C.baseline

D.privileged

AnswerD

Privileged allows all capabilities and has no restrictions.

Why this answer

The privileged Pod Security Standard (PSS) level imposes no restrictions on pod behavior, allowing unrestricted access to host resources, capabilities, and security contexts. This makes it the most relaxed level, as it does not enforce any of the constraints found in baseline or restricted profiles.

Exam trap

The trap here is that candidates may confuse 'default' with a valid PSS level, or assume 'baseline' is the most relaxed because it sounds less restrictive than 'restricted', but privileged explicitly allows all controls without limitation.

How to eliminate wrong answers

Option A is wrong because restricted is the most restrictive PSS level, enforcing strict security contexts, read-only root filesystems, and dropping all capabilities. Option B is wrong because 'default' is not a valid Pod Security Standard level; the three defined levels are privileged, baseline, and restricted. Option C is wrong because baseline applies a moderate set of restrictions (e.g., preventing hostPID, hostNetwork, and privileged containers) but is less relaxed than privileged.

Full explanation →

353

Multi-Selectmedium

Which TWO of the following are best practices for securing the software supply chain in a CI/CD pipeline?

Select 2 answers

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

B.Store sensitive credentials directly in the pipeline YAML file

C.Scan all container images for known vulnerabilities before deployment

D.Ignore critical CVEs if they are in development environments

E.Sign container images to ensure integrity and authenticity

AnswersC, E

Vulnerability scanning is essential.

Why this answer

Scanning container images for known vulnerabilities (e.g., using Trivy, Clair, or Grype) before deployment is a fundamental supply chain security practice. It ensures that only images free of critical or high-severity CVEs are promoted to production, reducing the attack surface and preventing exploitation of known flaws.

Exam trap

The CKS exam often tests the misconception that 'latest' tags are safe for CI/CD pipelines, but the trap is that they undermine reproducibility and security, and the exam expects you to recognize that immutable, versioned tags (e.g., SHA256 digests) are the correct practice.

Full explanation →

354

MCQmedium

A container runs with the default seccomp profile but the application needs to make a specific syscall that is blocked. Which approach should be taken?

A.Use the RuntimeDefault profile and add capabilities

B.Change the seccomp profile to another runtime default

C.Set seccompProfile to Unconfined

D.Create a custom seccomp profile that allows the syscall and apply it via type: Localhost

AnswerD

Correct. A custom profile allows fine-grained control.

Why this answer

The default seccomp profile (RuntimeDefault) blocks a specific set of syscalls for security. When an application requires a blocked syscall, the proper approach is to create a custom seccomp profile that explicitly allows that syscall, then apply it to the container via `seccompProfile.type: Localhost` and reference the profile file. This maintains security by only relaxing the necessary restriction, rather than disabling the profile entirely.

Exam trap

CNCF often tests the misconception that capabilities can override seccomp restrictions, but in reality, seccomp and capabilities are independent security mechanisms; a blocked syscall cannot be unblocked by adding capabilities.

How to eliminate wrong answers

Option A is wrong because capabilities control privileged operations (e.g., CAP_SYS_ADMIN), not syscall filtering; adding capabilities does not unblock a syscall blocked by seccomp. Option B is wrong because there is only one runtime default profile (RuntimeDefault) in containerd/Docker; changing to another runtime default is not possible as it is the same profile. Option C is wrong because setting seccompProfile to Unconfined disables all seccomp filtering, which is overly permissive and violates the principle of least privilege; it should only be used when absolutely necessary and after careful consideration.

Full explanation →

355

MCQmedium

You have created a ValidatingWebhookConfiguration to reject pods without resource limits. When you try to create a pod without limits, it is created successfully. What is the most likely reason?

A.The webhook is not matching the namespace labels

B.The webhook service is not running or is unreachable

C.The webhook is configured with failurePolicy: Fail

D.The pod is being created by a controller like a Deployment

AnswerB

If the webhook service is down, the API server will fail open (depending on failurePolicy) and allow the pod creation.

Why this answer

The most likely reason a pod without resource limits is created successfully despite a ValidatingWebhookConfiguration is that the webhook service itself is not running or is unreachable. When the API server cannot contact the webhook endpoint, the default behavior (failurePolicy: Ignore) allows the request to proceed, so the pod is created without validation. If the webhook were functioning correctly, it would reject the pod; thus, the failure to reject indicates a connectivity or service issue.

Exam trap

Candidates may incorrectly assume the ValidatingWebhookConfiguration is misconfigured (e.g., missing objectSelector or wrong failurePolicy) when the actual issue is that the webhook backend service is unreachable. In Kubernetes, if the API server cannot reach the webhook server, the failurePolicy (default Ignore) allows the pod creation, so the pod passes through without validation. This is a common pitfall where the webhook service itself is not running or not accessible, rather than a configuration error.

How to eliminate wrong answers

Option A is wrong because the question does not mention namespace labels or any namespaceSelector in the webhook configuration; even if labels were mismatched, the webhook would simply not be invoked for that namespace, but the pod would still be created without limits — however, the most likely reason given the scenario is a service issue, not a label mismatch. Option C is wrong because failurePolicy: Fail would cause the API server to reject the pod if the webhook is unreachable, which contradicts the pod being created successfully; the default failurePolicy is Ignore, which allows the pod through when the webhook is down. Option D is wrong because controllers like Deployments still go through the same admission webhook process; the webhook would reject the pod regardless of whether it is created directly or via a controller.

Full explanation →

356

MCQmedium

An administrator wants to ensure that a service account used by a deployment cannot automatically mount its token. Which field should be set to `false` in the Pod spec?

A.mountServiceAccountToken

B.disableTokenMount

C.automountServiceAccountToken

D.automountToken

AnswerC

Setting `automountServiceAccountToken` to `false` in the Pod spec prevents the kubelet from automatically projecting the service account’s token into the container filesystem at `/var/run/secrets/kubernetes.io/serviceaccount`. This satisfies the administrator’s constraint to disable automatic token mounting for the deployment’s service account, reducing the risk of token exposure if the container is compromised.

Why this answer

The `automountServiceAccountToken` field in the Pod spec controls whether the service account token is automatically mounted into the container. Setting this field to `false` prevents the automatic mounting of the token, which is a security best practice to reduce the attack surface for compromised pods. This field can be set at the Pod level or overridden at the ServiceAccount level.

Exam trap

The trap here is that candidates often confuse the field name with similar-sounding but incorrect options like `automountToken` or `disableTokenMount`, or they mistakenly think `mountServiceAccountToken` is the correct field, when the exact API field is `automountServiceAccountToken`.

How to eliminate wrong answers

Option A is wrong because `mountServiceAccountToken` is not a valid field in the Pod spec; the correct field name is `automountServiceAccountToken`. Option B is wrong because `disableTokenMount` is not a recognized Kubernetes field; no such field exists in the Pod or ServiceAccount API. Option D is wrong because `automountToken` is an incorrect abbreviation; the actual field name is `automountServiceAccountToken`, which must be spelled out exactly as defined in the Kubernetes API.

Full explanation →

357

MCQhard

An organization uses Kubernetes with multiple namespaces and wants to ensure that containers running as non-root cannot escalate to root via setuid binaries. Which combination of security contexts and Pod Security Standards achieves this?

A.Use an AppArmor profile to block setuid syscalls.

B.Apply the 'restricted' Pod Security Standard at the namespace level.

C.Set 'securityContext.runAsUser: 1000' on each pod spec.

D.Apply the 'baseline' Pod Security Standard with 'seccompProfile: RuntimeDefault'.

AnswerB

Restricted enforces runAsNonRoot and disallows privileged escalation.

Why this answer

The 'restricted' Pod Security Standard (PSS) enforces the strongest set of security constraints, including preventing containers from running as root and disallowing privilege escalation. Specifically, it requires `securityContext.allowPrivilegeEscalation: false` and prohibits running as root, which directly blocks escalation via setuid binaries. Applying this standard at the namespace level ensures all pods in that namespace inherit these controls, meeting the requirement.

Exam trap

CNCF often tests the misconception that simply running as a non-root user (e.g., `runAsUser: 1000`) is sufficient to prevent privilege escalation, but without `allowPrivilegeEscalation: false`, setuid binaries can still be exploited to gain root.

How to eliminate wrong answers

Option A is wrong because AppArmor profiles can block specific syscalls, but they are not the standard Kubernetes-native mechanism for preventing privilege escalation via setuid binaries; the question specifically asks for a combination of security contexts and Pod Security Standards, not a third-party tool. Option C is wrong because setting `runAsUser: 1000` only changes the user ID but does not prevent the container from using setuid binaries to escalate to root; it still allows privilege escalation unless `allowPrivilegeEscalation: false` is also set. Option D is wrong because the 'baseline' PSS does not enforce `allowPrivilegeEscalation: false`; it only prevents known privilege escalation paths like host namespaces but allows setuid binaries, and `seccompProfile: RuntimeDefault` alone does not block setuid escalation.

Full explanation →

358

MCQmedium

An administrator wants to run a container that requires the SYS_TIME capability. Which field should be used in the securityContext to add this capability?

A.capabilities.add

B.privileged: true

C.allowPrivilegeEscalation: true

D.capabilities.drop

AnswerA

Correct field to add capabilities.

Why this answer

The `capabilities.add` field in the `securityContext` is specifically designed to add Linux capabilities (such as `SYS_TIME`) to a container without granting full root privileges. This follows the principle of least privilege, allowing only the required capability to modify the system clock.

Exam trap

The trap here is that candidates often confuse `privileged: true` (which grants all capabilities but is overly permissive) with the more precise `capabilities.add` approach, or they mistakenly think `allowPrivilegeEscalation` is related to adding capabilities.

How to eliminate wrong answers

Option B is wrong because `privileged: true` grants all capabilities (including SYS_TIME) but also disables all security restrictions, which is excessive and violates the principle of least privilege. Option C is wrong because `allowPrivilegeEscalation: true` controls whether a process can gain more privileges than its parent (e.g., via setuid binaries), not the addition of specific capabilities. Option D is wrong because `capabilities.drop` is used to remove capabilities from the default set, not to add them.

Full explanation →

359

Multi-Selectmedium

Which TWO of the following are best practices for securing the container supply chain? (Select 2)

Select 2 answers

A.Disable image pull secrets to reduce complexity

B.Scan container images for vulnerabilities

C.Hardcode secrets in the Dockerfile for convenience

D.Use minimal base images like Alpine or distroless

E.Run containers as root to simplify permissions

AnswersB, D

Scanning helps detect known vulnerabilities before deployment.

Why this answer

Using minimal base images reduces the attack surface, and scanning images for vulnerabilities helps identify and fix security issues before deployment.

Full explanation →

360

Multi-Selectmedium

Which TWO of the following are valid ways to restrict access to the Kubernetes API server?

Select 2 answers

A.Use static token file

B.Use webhook token authentication

C.Enable NodeRestriction admission plugin

D.Configure RBAC authorization

E.Enable anonymous access

AnswersB, D

Valid authentication method.

Why this answer

Webhook token authentication (Option B) is a valid method to restrict API server access because it delegates token validation to an external service via a webhook, allowing custom authentication logic. This is a supported authentication strategy in Kubernetes, enabling fine-grained control over who can access the API server.

Exam trap

CNCF often tests the distinction between authentication (who you are) and authorization (what you can do), so candidates may confuse RBAC (authorization) with authentication mechanisms like webhook tokens, but the question asks for ways to 'restrict access,' which includes both authentication and authorization controls.

Full explanation →

361

Multi-Selecteasy

You are auditing a cluster's supply chain security. You find that many pods are running images from public registries without any pinning or verification. Which TWO actions would most effectively reduce the risk of pulling malicious images?

Select 2 answers

A.Configure all deployments to use image digests instead of tags.

B.Set up a private registry proxy that mirrors approved public images and disable direct access to public registries via containerd configuration.

C.Implement RBAC to restrict which users can create pods.

D.Enforce PodSecurityStandard baseline or restricted to block privileged containers.

E.Apply a network policy that blocks egress traffic to public registries.

AnswersA, B

Prevents tag mutation and ensures image integrity.

Why this answer

Using image digests (e.g., `nginx@sha256:abc123...`) pins the image to an immutable content hash, ensuring that the exact same image is pulled every time, even if the tag is updated to a malicious version. This prevents tag-mutation attacks where an attacker replaces a benign image tag with a compromised one. Digests are verified by the container runtime (containerd) against the registry's manifest, providing cryptographic assurance of image integrity.

Exam trap

CNCF often tests the distinction between runtime security controls (PodSecurityStandards, network policies) and supply chain controls (image pinning, registry proxies), and candidates mistakenly think blocking egress or restricting pod creation mitigates the risk of pulling malicious images, when those controls do not affect the image pull process itself.

Full explanation →

362

MCQmedium

Which flag must be set on the API server to enable audit logging?

A.--audit-log-maxage=30

B.--audit-log-format=json

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

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

AnswerC

This flag enables audit logging by specifying the log file path.

Why this answer

The `--audit-log-path` flag is the mandatory parameter that enables audit logging in the kube-apiserver. Without specifying a file path for the audit log, the API server will not write any audit events, even if other audit-related flags are set. This flag tells the API server where to persist the audit log entries, effectively activating the audit logging feature.

Exam trap

The trap here is that candidates often assume setting the audit policy file (`--audit-policy-file`) alone enables auditing, but without `--audit-log-path` the API server does not write any audit logs, making the policy effectively useless.

How to eliminate wrong answers

Option A is wrong because `--audit-log-maxage=30` only controls the maximum number of days to retain old audit log files; it does not enable audit logging itself. Option B is wrong because `--audit-log-format=json` specifies the output format of the audit log (e.g., JSON or legacy format) but does not turn on audit logging. Option D is wrong because `--audit-policy-file` defines the rules for which events to audit, but without `--audit-log-path` the API server will not write any audit log output, making the policy file ineffective.

Full explanation →

363

MCQeasy

Which kubectl command is used to create a Constraint object in OPA/Gatekeeper?

A.kubectl create configmap constraint.yaml

B.kubectl apply -f constraint.yaml

C.kubectl create pod constraint.yaml

D.kubectl create -f constraint.yaml

AnswerB

Correct. 'kubectl apply -f constraint.yaml' creates or updates the Gatekeeper constraint resource defined in the YAML file.

Why this answer

In OPA/Gatekeeper, constraints are custom resources defined by a ConstraintTemplate. The 'kubectl apply -f' command is used to create or update these resources. 'kubectl create -f' can also create resources, but 'apply' is preferred for managing constraints as it handles both creation and updates. Option A attempts to create a ConfigMap, not a constraint.

Option C attempts to create a Pod. Option D uses 'create' which can work but is less common for constraints; 'apply' is the recommended approach.

Full explanation →

364

MCQmedium

An administrator runs 'kubectl auth can-i --list --as=system:serviceaccount:ns1:my-sa' and sees that the service account has 'create pods' permission via a RoleBinding. Which command can be used to delete that RoleBinding?

A.kubectl delete serviceaccount my-sa -n ns1

B.kubectl delete role <role-name> -n ns1

C.kubectl delete rolebinding <binding-name> -n ns1

D.kubectl delete clusterrolebinding <binding-name>

AnswerC

This deletes the RoleBinding in the specified namespace.

Why this answer

The `kubectl auth can-i --list` output shows that the service account `my-sa` has `create pods` permission via a RoleBinding. To remove that permission, you must delete the RoleBinding object itself, not the service account or the role (unless the role is exclusively used by this binding). Option C correctly uses `kubectl delete rolebinding` with the specific binding name and namespace to revoke the RBAC grant.

Exam trap

CNCF often tests the misconception that deleting the role or the service account is equivalent to removing the permission, but the correct action is to delete the RoleBinding that grants the permission.

How to eliminate wrong answers

Option A is wrong because deleting the service account removes the identity but does not directly delete the RoleBinding; the binding would become orphaned, and the permission would still exist in the cluster (though unusable). Option B is wrong because deleting the role removes the permission definition, but the RoleBinding would still reference a non-existent role, potentially causing errors or leaving the binding in an invalid state; the correct approach is to delete the binding itself. Option D is wrong because the permission was granted via a RoleBinding (namespaced), not a ClusterRoleBinding; deleting a ClusterRoleBinding would not affect a namespaced RoleBinding.

Full explanation →

365

Multi-Selectmedium

Which THREE of the following are recommended practices for securing the etcd datastore?

Select 3 answers

A.Disable peer client cert authentication

B.Bind etcd to localhost only if not required to be accessible from other nodes

C.Allow anonymous access to etcd for performance

D.Enable encryption at rest for etcd data

E.Use TLS for all etcd client-to-server communication

AnswersB, D, E

Binding to localhost reduces the attack surface.

Why this answer

Binding etcd to localhost (127.0.0.1) when it does not need to be accessed from other nodes restricts network exposure, reducing the attack surface. This is a fundamental network hardening practice that prevents unauthorized remote access to the etcd datastore, which stores all cluster state and secrets.

Exam trap

The trap here is that candidates may think disabling authentication (Option A) or enabling anonymous access (Option C) improves performance or simplifies setup, but the CKS exam strictly enforces that security controls like mTLS and authentication must never be weakened for any reason.

Full explanation →

366

MCQeasy

You suspect a container is running an unexpected process. Which crictl command can you use to list all running containers on the node?

A.crictl stats

B.crictl pods

C.crictl ps

D.crictl images

AnswerC

crictl ps lists running containers, similar to docker ps.

Why this answer

crictl ps lists all running containers on the node. crictl pods lists pods, not containers. crictl images lists images. crictl stats shows resource usage.

Full explanation →

367

MCQmedium

A DevOps engineer is setting up a CI/CD pipeline to scan container images for vulnerabilities. They want to fail the pipeline if any critical vulnerabilities are found. Which command should they use to scan the image and produce a JSON output that can be parsed?

A.trivy fs --severity CRITICAL --output json .

B.trivy image --severity CRITICAL --output json myimage:tag

C.trivy image --format table myimage:tag

D.trivy image --severity HIGH myimage:tag

AnswerB

This command correctly scans the image, filters for critical severity, and outputs JSON.

Why this answer

`trivy image` scans a container image (not filesystem), and the `--severity CRITICAL` flag filters results to critical vulnerabilities only, while `--output json` produces machine-parseable JSON output. This allows the CI/CD pipeline to parse the JSON and fail the build if any critical vulnerabilities are present, meeting the requirement exactly.

Exam trap

The trap here is that candidates confuse `trivy fs` (filesystem scan) with `trivy image` (container image scan), or they forget that `--output json` is required for machine parsing, not just `--format table` or default output.

How to eliminate wrong answers

Option A is wrong because `trivy fs` scans a filesystem or directory, not a container image, so it would not scan the image layers for vulnerabilities. Option C is wrong because `--format table` produces human-readable table output, not JSON, making it unsuitable for programmatic parsing in a pipeline. Option D is wrong because `--severity HIGH` filters for high-severity vulnerabilities, not critical, and it lacks `--output json` so the output is not in JSON format.

Full explanation →

368

Multi-Selectmedium

Which TWO of the following are valid audit stages in Kubernetes audit logging?

Select 2 answers

A.ResponseStarted

B.Panic

C.ResponseFinished

D.RequestProcessing

E.RequestReceived

AnswersA, E

ResponseStarted is a valid audit stage that fires after the response headers are sent but before the body.

Why this answer

Kubernetes audit logging defines four stages: RequestReceived, ResponseStarted, ResponseComplete, and Panic. Among the options, valid stages are A (ResponseStarted), B (Panic), and E (RequestReceived). Since the question asks for exactly two, the selected correct answers are A and E.

Both are valid. Option B (Panic) is also a valid stage but is not included as a correct answer for this specific question.

Exam trap

The trap is that candidates may not realize that RequestReceived is also a valid stage and might overlook it, assuming only ResponseStarted and Panic are the only two. The question selects A and E as the correct pair, but any two of the three valid stages would be technically correct.

Full explanation →

369

MCQeasy

Which admission plugin should be enabled on the API server to enforce that kubelet cannot modify nodes other than its own?

A.NodeSelector

B.PodSecurity

C.NodeRestriction

D.AlwaysPullImages

AnswerC

Correct. NodeRestriction ensures kubelet can only modify its own node.

Why this answer

The NodeRestriction admission plugin ensures that a kubelet can only modify its own Node object and Pods bound to it. This prevents a compromised or misconfigured kubelet from tampering with other nodes, enforcing the principle of least privilege. Without this plugin, a kubelet could potentially update labels, taints, or status on any node, leading to cluster instability or privilege escalation.

Exam trap

CNCF often tests the distinction between admission plugins that control Pod behavior (like PodSecurity or AlwaysPullImages) versus those that control kubelet authorization (NodeRestriction), leading candidates to confuse Pod-level security with node-level access control.

How to eliminate wrong answers

Option A is wrong because NodeSelector is not an admission plugin; it is a field in Pod specs used to constrain which nodes a Pod can be scheduled on, not a kubelet authorization control. Option B is wrong because PodSecurity is an admission plugin that enforces Pod Security Standards (e.g., privileged, baseline, restricted) on Pods, but it does not restrict kubelet actions on node objects. Option D is wrong because AlwaysPullImages is an admission plugin that forces image pull policy to Always, ensuring images are always pulled from the registry, but it has no effect on kubelet node modification permissions.

Full explanation →

370

Multi-Selecteasy

Which TWO of the following are valid methods to securely manage secrets in Kubernetes?

Select 2 answers

A.Use Kubernetes Secrets with encryption at rest enabled

B.Store secrets in ConfigMaps and use them in pods

C.Commit secrets to a private Git repository

D.Store secrets directly in the application code

E.Use an external secret manager like HashiCorp Vault with a sidecar or CSI driver

AnswersA, E

Kubernetes Secrets can be encrypted using EncryptionConfiguration.

Why this answer

Kubernetes Secrets can be encrypted at rest using a KMS provider (e.g., AWS KMS, Azure Key Vault, or GCP Cloud KMS) configured via the EncryptionConfiguration resource. This ensures that Secret data is encrypted in etcd, protecting it from unauthorized access if the etcd database is compromised. Encryption at rest is a critical security control for secrets in Kubernetes.

Exam trap

A common trap is the misconception that base64 encoding of Secrets provides security, when in fact it is only obfuscation and not encryption, leading candidates to overlook the need for encryption at rest or external secret managers.

Full explanation →

371

Multi-Selecthard

Which THREE are valid methods to verify the integrity and origin of a container image? (Select 3)

Select 3 answers

A.Trivy fs

B.Notary

C.Syft

D.Cosign verify

E.ImagePolicyWebhook

AnswersB, D, E

Notary provides signing and verification of content.

Why this answer

Notary is correct because it is a tool that enables the signing and verification of container images using The Update Framework (TUF), ensuring both integrity (the image has not been tampered with) and origin (the image was signed by a trusted publisher). It works by managing cryptographic signatures and metadata in a trusted collection, allowing clients to verify the signature chain before pulling an image.

Exam trap

The CNCF CKS exam often tests the distinction between tools that scan/inventory images (like Trivy fs and Syft) and tools that cryptographically verify image signatures (like Notary and Cosign), so the trap here is confusing vulnerability scanning or SBOM generation with integrity and origin verification.

Full explanation →

372

MCQhard

You are a security engineer for a large e-commerce company. The Kubernetes cluster runs on-premises and hosts critical payment processing applications. Recently, a security scan revealed that several pods are running with privileged escalation enabled, and some have a writable root filesystem. The cluster uses Kubernetes v1.26 with PodSecurity admission controller enabled but currently set to 'privileged' profile for all namespaces. The development teams require flexibility for some legacy applications that need to run with hostNetwork or hostPID. However, the security team wants to enforce a restricted profile for most namespaces while allowing exceptions. The CISO has mandated that no pod should run as root, and all pods must have read-only root filesystem and privilege escalation disabled. Additionally, any pod that requires hostNetwork or hostPID must be explicitly approved and placed in a separate namespace. You need to design a solution that meets these requirements with minimal operational overhead. What is the best course of action?

A.Deploy OPA Gatekeeper and create constraints to enforce read-only root filesystem, no privilege escalation, and non-root user, with exceptions via label selectors

B.Keep the current 'privileged' profile and rely on runtime security tools like Falco to detect violations

C.Use PodSecurity admission with 'restricted' profile for most namespaces by labeling them with 'pod-security.kubernetes.io/enforce=restricted', and create a separate namespace with 'baseline' profile for legacy apps that require hostNetwork/hostPID, after reviewing and approving each exception

D.Change the PodSecurity profile to 'restricted' cluster-wide and require all legacy apps to be rewritten to not need hostNetwork/hostPID

AnswerC

This uses native Kubernetes features, enforces the mandates, and allows controlled exceptions.

Why this answer

PodSecurity admission (PSA) is the native Kubernetes mechanism for enforcing pod security standards with minimal operational overhead. By labeling most namespaces with 'pod-security.kubernetes.io/enforce=restricted', you enforce the CISO's mandates (non-root, read-only root filesystem, no privilege escalation) automatically. Creating a separate namespace with the 'baseline' profile allows legacy apps requiring hostNetwork/hostPID to run after explicit approval, while still blocking privileged escalation and other dangerous capabilities.

Exam trap

CNCF often tests the misconception that OPA Gatekeeper is always required for fine-grained policy enforcement, when in fact PodSecurity admission with 'baseline' and 'restricted' profiles can handle common exceptions like hostNetwork/hostPID without additional tooling.

How to eliminate wrong answers

Option A is wrong because deploying OPA Gatekeeper introduces significant operational overhead (managing constraint templates, rego policies, and label selectors) when the native PodSecurity admission controller already meets the requirements with simpler namespace labeling. Option B is wrong because keeping the 'privileged' profile and relying on Falco for detection only alerts on violations after they occur, failing the CISO's mandate to prevent pods from running as root or with writable root filesystem. Option D is wrong because changing the profile to 'restricted' cluster-wide would block all legacy apps that need hostNetwork/hostPID, as the 'restricted' profile explicitly denies these settings, and rewriting all legacy apps is not a minimal-overhead solution.

Full explanation →

373

MCQhard

An admin wants to enforce that all pods in a namespace use a read-only root filesystem except for a specific deployment that needs to write to a temporary directory. Which approach best meets this requirement?

A.Use a Gatekeeper Constraint that denies pods with readOnlyRootFilesystem not set to true, but add an exception label on the specific deployment's namespace or pod, and modify the Constraint to skip pods with that label

B.Set a default readOnlyRootFilesystem: true via a mutating webhook, and then manually patch the specific deployment after creation

C.Modify the PodSecurityPolicy to allow readOnlyRootFilesystem: false for the specific deployment's service account

D.Set readOnlyRootFilesystem: true in the deployment's pod template and add an emptyDir volume for the temporary directory

AnswerA

This allows fine-grained, policy-based enforcement with exceptions.

Why this answer

Gatekeeper (OPA/Gatekeeper) allows you to define a Constraint that denies pods without `readOnlyRootFilesystem: true`, and you can add an exception label on the specific deployment's pod template. By modifying the Constraint to skip pods with that label (using a `labelSelector` or `excludedNamespaces` in the Constraint's spec), you enforce the policy for all pods except the exempted deployment, meeting the requirement without manual patching or legacy PSPs.

Exam trap

CNCF often tests the distinction between mutating webhooks (which can set defaults but require careful exception handling) and validating webhooks like Gatekeeper (which can enforce policies with label-based exceptions), leading candidates to choose the simpler but less robust mutating approach.

How to eliminate wrong answers

Option B is wrong because a mutating webhook can set a default `readOnlyRootFilesystem: true`, but manually patching the specific deployment after creation is not a scalable or auditable approach; the webhook would re-mutate the pod on updates unless you also add an exception mechanism, making this fragile. Option C is wrong because PodSecurityPolicy (PSP) is deprecated and removed in Kubernetes 1.25+; even if it were available, PSPs are cluster-scoped and cannot selectively allow `readOnlyRootFilesystem: false` for a specific deployment's service account without affecting other pods using that same service account. Option D is wrong because setting `readOnlyRootFilesystem: true` in the deployment's pod template and adding an emptyDir volume does not allow writing to the root filesystem; the emptyDir is a separate writable volume, but the root filesystem remains read-only, which contradicts the requirement that the deployment needs to write to a temporary directory (which implies writing to the root filesystem, not just a volume).

Full explanation →

374

Multi-Selectmedium

Which two of the following are correct ways to enforce least privilege for service accounts? (Choose two.)

Select 2 answers

A.Set automountServiceAccountToken: false in Pod spec for pods that do not need API access

B.Add multiple ClusterRoleBindings to a single service account to ensure it has access to all resources

C.Use the default service account for all workloads

D.Create a dedicated service account with only the required RBAC permissions

E.Grant cluster-admin ClusterRole to the service account for simplicity

AnswersA, D

This prevents unnecessary token mounting.

Why this answer

Setting `automountServiceAccountToken: false` in the Pod spec prevents the automatic mounting of the service account token into the container. This enforces least privilege by ensuring that pods which do not require API access cannot inadvertently use the token to authenticate to the Kubernetes API server, reducing the attack surface.

Exam trap

CNCF often tests the misconception that the default service account is safe to use for all workloads, when in fact it should be replaced with dedicated service accounts that have minimal, scoped RBAC permissions.

Full explanation →

375

MCQmedium

A pod in namespace 'secure' has the following securityContext: securityContext: runAsNonRoot: true runAsUser: 1000 capabilities: drop: ["ALL"] add: ["NET_BIND_SERVICE"] The pod fails to start. The namespace is enforced with the 'restricted' Pod Security Standard. What is the most likely reason?

A.The pod adds capabilities, which is not allowed by the restricted policy.

B.The runAsUser is set to 1000, which is not allowed by the restricted policy.

C.The pod sets runAsNonRoot to true, which is not allowed by the restricted policy.

D.The pod drops all capabilities, which is not allowed by the restricted policy.

AnswerA

Restricted policy prohibits adding capabilities beyond the default set; NET_BIND_SERVICE is not allowed.

Why this answer

The 'restricted' Pod Security Standard (PSS) explicitly prohibits adding any capabilities beyond the default set, which is empty. Since the pod's securityContext adds the NET_BIND_SERVICE capability, it violates the restricted policy, causing the pod to fail to start.

Exam trap

CNCF often tests the nuance that the restricted policy forbids adding any capabilities, even if they are considered 'safe' or commonly used, and candidates may mistakenly think that dropping all capabilities is the violation or that runAsUser: 1000 is the issue.

How to eliminate wrong answers

Option B is wrong because the restricted policy does allow runAsUser values, provided they are not 0 (root); 1000 is a non-root user and is permitted. Option C is wrong because runAsNonRoot: true is actually required by the restricted policy, not disallowed. Option D is wrong because dropping all capabilities is not only allowed but is a requirement of the restricted policy, which mandates dropping all capabilities and adding none.

Full explanation →

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