Certified Kubernetes Security Specialist CKS CKS Questions 751–825 | Page 11/14

751

MCQeasy

What is the purpose of setting a container's filesystem to read-only in a Pod spec?

A.To prevent an attacker from modifying the container's filesystem after compromise

B.To allow multiple pods to share the same filesystem

C.To prevent the container from being deleted

D.To improve disk I/O performance

AnswerA

Correct. If the filesystem is read-only, an attacker cannot write new files or modify existing ones, limiting the impact of a breach.

Why this answer

Setting readOnlyRootFilesystem to true makes the container's filesystem immutable, preventing attackers from writing malicious files or altering binaries. It is a security best practice.

Full explanation →

752

MCQmedium

A security team wants to enforce that containers in a specific namespace cannot gain new capabilities. Which Pod security context field is used to achieve this?

A.capabilities.drop: ["ALL"]

B.privileged: false

C.allowPrivilegeEscalation: false

D.runAsNonRoot: true

AnswerC

Correct. This prevents privilege escalation.

Why this answer

Setting 'allowPrivilegeEscalation: false' prevents processes from gaining more privileges than their parent.

Full explanation →

753

Multi-Selectmedium

Which TWO of the following are valid AppArmor profile modes?

Select 2 answers

A.complain

B.audit

C.enforce

D.unconfined

E.allow

AnswersA, C

Valid mode.

Why this answer

AppArmor has three modes: enforce (block violations), complain (log violations), and unconfined (no restrictions). Allow and audit are not modes.

Full explanation →

754

MCQmedium

An admin runs 'kubectl run test-pod --image=busybox --command -- sleep 3600' and then executes 'kubectl exec test-pod -- cat /var/run/secrets/kubernetes.io/serviceaccount/token'. The admin wants to prevent such access to the service account token. What is the correct action?

A.Remove the service account from the pod

B.Set securityContext.runAsNonRoot: true

C.Set automountServiceAccountToken: false in the pod spec

D.Use a NetworkPolicy to block access to the API server

AnswerC

Correct. This boolean field controls whether the service account token is automatically mounted.

Why this answer

Setting automountServiceAccountToken to false in the pod spec prevents automatic mounting of the service account token. This is a security best practice for pods that do not need to interact with the API server.

Full explanation →

755

MCQhard

A Falco rule is written to detect when a shell is spawned inside a container. The rule condition is: `spawned_process and container and proc.name = bash`. The rule is not triggering. Which of the following is the most likely reason?

A.The rule is missing `proc.name in (bash, sh, zsh)` because only bash is checked

B.Falco is not running with the required syscall capabilities

C.The `spawned_process` macro may not match because the process was inherited (not spawned), e.g., from an entrypoint

D.The priority is set to `ERROR` but the output is being filtered

AnswerC

`spawned_process` typically checks for newly created processes; inherited processes may not match.

Why this answer

The condition requires both `spawned_process` and `container` macro fields, which are typical. Option B is the most likely because the `spawned_process` macro might not include all shell spawn scenarios (e.g., inherited processes). Option A is correct but less likely.

Options C and D are incorrect.

Full explanation →

756

MCQmedium

A developer creates a Deployment with the following container spec: ```yaml containers: - name: app image: myapp:latest env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password ``` Which of the following is a security concern with this approach?

A.The secret is not encrypted at rest in etcd.

B.The secret is exposed in the container environment variables, which can be accessed via /proc or logs if the container is compromised.

C.The secret name 'db-secret' is too generic.

D.The secret is not base64 encoded.

AnswerB

Environment variables are visible in the container's /proc/self/environ and can be logged by applications. Mounting secrets as volumes is more secure.

Full explanation →

757

Multi-Selectmedium

A security auditor reviews a Kubernetes cluster and finds that several nodes have container runtimes with default configurations. Which TWO of the following actions should be taken to harden the container runtime?

Select 2 answers

A.Set readOnlyRootFilesystem in pod security contexts

B.Enable AppArmor profiles on the nodes

C.Set --no-new-privileges flag in the container runtime configuration

D.Configure Seccomp profiles to allow only necessary syscalls

E.Disable swap on all nodes

AnswersB, D

AppArmor restricts container processes to a minimal set of capabilities.

Why this answer

Option B is correct because enabling AppArmor profiles on nodes enforces mandatory access control (MAC) on container processes, restricting them to only the resources they need. This hardens the container runtime by confining containers beyond the default, often permissive, runtime configuration. AppArmor profiles are a key security mechanism for system hardening in Kubernetes.

Exam trap

CNCF often tests the distinction between pod-level security contexts (like readOnlyRootFilesystem) and node-level runtime hardening (like AppArmor or Seccomp), causing candidates to confuse pod security with runtime security.

Full explanation →

758

MCQhard

A pod is failing to start with: 'Error: container has runAsNonRoot and image will run as root'. The pod spec sets securityContext.runAsNonRoot: true. The container image is 'nginx:latest' which runs as root. Which change allows the pod to run while maintaining security?

A.Remove runAsNonRoot: true

B.Add a PodSecurityPolicy that allows root

C.Set runAsUser: 1000 in the container securityContext

D.Use a mutating webhook to change the image

AnswerC

Runs as non-root user, satisfying runAsNonRoot.

Why this answer

Option C is correct because setting `runAsUser: 1000` in the container's securityContext overrides the default user (root) in the image, ensuring the container process runs as a non-root user (UID 1000). This satisfies the `runAsNonRoot: true` constraint at the pod level, which requires that the container's user ID is non-zero, while still maintaining security by not running as root.

Exam trap

CNCF often tests the distinction between pod-level and container-level securityContext settings, and the trap here is that candidates might think removing `runAsNonRoot` or using a deprecated PSP is acceptable, rather than directly setting a non-root user ID in the container's securityContext.

How to eliminate wrong answers

Option A is wrong because removing `runAsNonRoot: true` would allow the container to run as root, which violates the security requirement of running as non-root. Option B is wrong because PodSecurityPolicy (PSP) is deprecated in Kubernetes 1.21+ and removed in 1.25; even if available, adding a policy that allows root would bypass the security constraint, not maintain it. Option D is wrong because using a mutating webhook to change the image (e.g., to a non-root image) is an indirect and unnecessary workaround; the direct fix is to set `runAsUser` in the container's securityContext, which is simpler and more explicit.

Full explanation →

759

MCQmedium

A pod is stuck in 'Pending' state. You run 'kubectl describe pod mypod' and see the event: '0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate'. What is the most likely solution?

A.Delete the pod and recreate it without any tolerations

B.Remove the taint from the node using 'kubectl taint nodes ...'

C.Add a toleration to the pod spec for the taint 'node-role.kubernetes.io/master'

D.Add a nodeSelector to the pod to match the node's labels

AnswerC

Correct. Adding a toleration allows the pod to be scheduled on the tainted node.

Why this answer

The pod cannot schedule because the node has a taint. To allow the pod to run on that node, add a toleration for that taint in the pod spec.

Full explanation →

760

MCQmedium

An administrator runs `kube-bench` on a Kubernetes node and receives a warning that the kubelet is configured with `--anonymous-auth=true`. Which kubectl command should be used to fix this on the kubelet?

A.kubectl annotate node --all kubelet.kubernetes.io/anonymous-auth=false

B.kubectl edit node <node-name> and set spec.anonymousAuth to false

C.kubectl set env daemonset/kubelet -n kube-system ANONYMOUS_AUTH=false

D.kubectl edit configmap kubelet-config -n kube-system and set authentication.anonymous.enabled to false

AnswerD

The kubelet configuration is often stored in a ConfigMap. Editing it allows changing the anonymous auth setting.

Why this answer

Option D is correct because the kubelet's anonymous authentication is configured via a KubeletConfiguration object, which is typically stored as a ConfigMap in the kube-system namespace. Editing the `kubelet-config` ConfigMap and setting `authentication.anonymous.enabled` to false is the proper kubectl-based method to disable anonymous authentication for the kubelet, as the kubelet reads its configuration from this ConfigMap when the `--config` flag is used.

Exam trap

The trap here is that candidates confuse the kubelet's configuration mechanism with other Kubernetes resources, assuming it can be patched via Node objects or DaemonSets, when in reality it requires modifying the KubeletConfiguration object (often a ConfigMap) and restarting the kubelet.

How to eliminate wrong answers

Option A is wrong because `kubectl annotate` does not affect kubelet authentication settings; annotations are metadata and have no effect on kubelet configuration. Option B is wrong because Node objects do not have a `spec.anonymousAuth` field; kubelet authentication is not configured through the Node API resource. Option C is wrong because the kubelet is not deployed as a DaemonSet; it runs as a static pod or systemd service, and `kubectl set env` cannot modify its configuration.

Full explanation →

761

MCQhard

Which of the following is NOT a valid method to enforce pod security standards in a Kubernetes cluster?

A.Using Pod Security Policy (PSP) if still available in the cluster

B.Using a mutating webhook to apply security contexts

C.Using OPA/Gatekeeper with the built-in PSS templates

D.Using Pod Security Admission (PSA) with labels on namespaces

AnswerC

OPA/Gatekeeper does not include built-in PSS templates; you must write custom Rego policies.

Why this answer

Option D is correct. OPA/Gatekeeper is a policy engine, but it does not natively enforce Pod Security Standards (PSS); it can be used to implement custom policies. The built-in methods are Pod Security Admission (PSA) and PodSecurityPolicy (deprecated).

Options A, B, and C are valid methods.

Full explanation →

762

MCQmedium

Which admission plugin should be enabled to ensure that kubelet only serves pods bound to its node and prevents unauthorized node access?

A.NodeRestriction

B.AlwaysPullImages

C.NodeAffinity

D.PodSecurityPolicy

AnswerA

This plugin restricts kubelet permissions to pods on its own node.

Why this answer

The NodeRestriction admission plugin ensures that the kubelet only serves pods bound to its node by limiting the kubelet's ability to modify labels and taints on its own Node object, and by preventing the kubelet from modifying pods not scheduled to its node. This plugin is a key security control to prevent unauthorized node access and enforce the principle of least privilege for kubelet operations.

Exam trap

CNCF often tests the distinction between admission plugins that control pod-level security (like PodSecurityPolicy) versus those that control node-level authorization (like NodeRestriction), leading candidates to confuse PodSecurityPolicy as the answer for node access control.

How to eliminate wrong answers

Option B (AlwaysPullImages) is wrong because it forces image pull policy to Always for every pod, which prevents use of locally cached images but does not restrict kubelet node access or pod binding. Option C (NodeAffinity) is wrong because it is a scheduling constraint (expressed via nodeSelector or affinity rules) that influences pod placement, not an admission plugin that restricts kubelet behavior after scheduling. Option D (PodSecurityPolicy) is wrong because it enforces security context constraints on pods (e.g., privileged containers, host namespaces) and does not control kubelet node-level access or pod binding.

Full explanation →

763

MCQeasy

You want to ensure that a container's root filesystem is immutable. Which field in the Pod spec should you set?

A.spec.containers[].securityContext.privileged

B.spec.hostNetwork

C.spec.containers[].securityContext.readOnlyRootFilesystem

D.spec.containers[].volumeMounts[].readOnly

AnswerC

Setting this to true makes the filesystem read-only.

Why this answer

The field 'securityContext.readOnlyRootFilesystem' at the container level makes the root filesystem read-only, effectively immutable.

Full explanation →

764

MCQmedium

You are deploying an application that needs to access a database password stored in a Kubernetes Secret. To minimize risk, you should mount the Secret as a volume rather than using environment variables. Which of the following is the primary security benefit of using mounted volumes over environment variables?

A.Environment variables can be leaked through commands like 'env' or 'cat /proc/1/environ', while mounted files are only accessible if the container has a shell and reads the file.

B.Mounted volumes are not visible in /proc, making them inaccessible to other processes.

C.Environment variables are stored in etcd in plaintext, while volumes are encrypted at rest.

D.Mounted volumes automatically rotate the secret when the Secret object is updated.

AnswerA

Environment variables are easily exposed through process listings and debugging tools. Mounted secrets require explicit file reads.

Full explanation →

765

MCQmedium

A pod has the following security context: capabilities: { drop: ['ALL'] } and privileged: false. The pod fails to start because it requires the ability to run iptables commands. Which of the following should be added to the pod's security context?

A.privileged: true

B.capabilities: { add: ['SYS_ADMIN'] }

C.capabilities: { drop: ['NET_ADMIN'] }

D.capabilities: { add: ['NET_ADMIN'] }

AnswerD

NET_ADMIN is the capability required for iptables operations.

Why this answer

The pod needs to run iptables commands, which require the NET_ADMIN capability. Since the security context drops ALL capabilities, you must explicitly add NET_ADMIN back. Option D correctly adds NET_ADMIN, granting the necessary network administration privileges without making the container fully privileged.

Exam trap

The trap here is that candidates often confuse SYS_ADMIN with NET_ADMIN, assuming that broad system administration privileges are needed for network tools, when in fact iptables specifically requires the NET_ADMIN capability.

How to eliminate wrong answers

Option A is wrong because setting privileged: true grants all capabilities and disables most security mechanisms, which is excessive and violates the principle of least privilege. Option B is wrong because SYS_ADMIN is a broad capability that provides many system administration privileges (e.g., mount, namespace operations) but does not specifically include the ability to manipulate network filtering rules via iptables; iptables requires NET_ADMIN, not SYS_ADMIN. Option C is wrong because it drops NET_ADMIN, which is the exact capability needed to run iptables; this would prevent the pod from starting successfully.

Full explanation →

766

Multi-Selectmedium

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

Select 2 answers

A.Use trivy image to check for vulnerabilities

B.Compare the image SHA digest with a known good digest

C.Use cosign verify to check the image signature

D.Use docker history to view layers

E.Use kubectl describe pod to check image details

AnswersB, C

Using SHA digests ensures the image has not been tampered with.

Why this answer

Cosign verify checks signatures, and comparing SHA digests ensures the image content hasn't changed.

Full explanation →

767

MCQhard

An administrator wants to reduce the attack surface of a Kubernetes node by disabling unnecessary system services. Which of the following services is considered unnecessary on a dedicated Kubernetes worker node and can be safely disabled?

A.containerd

B.sshd

C.cups

D.kubelet

AnswerC

CUPS (Common Unix Printing System) is unnecessary on a Kubernetes worker node.

Why this answer

Option C (cups) is correct because CUPS (Common Unix Printing System) is a print service that is unnecessary on a dedicated Kubernetes worker node, which does not require printing capabilities. Disabling it reduces the attack surface by removing a potential vector for privilege escalation or remote exploitation, as CUPS historically has had vulnerabilities like CVE-2024-35235. On a worker node, only essential services for container runtime, orchestration, and system management should run.

Exam trap

The trap here is that candidates may think sshd is unnecessary because Kubernetes nodes are managed via kubectl, but in practice, SSH access is critical for node-level troubleshooting, kernel updates, and emergency recovery, making it a required service unless a secure alternative like a serial console is in place.

How to eliminate wrong answers

Option A is wrong because containerd is the container runtime interface (CRI) implementation that manages container lifecycles on the node; disabling it would prevent the kubelet from running pods, making the node non-functional. Option B is wrong because sshd (SSH daemon) is typically required for secure remote administration, troubleshooting, and compliance auditing; while it can be restricted via firewall or SSH keys, it is not considered unnecessary on a worker node unless a dedicated bastion host or out-of-band management is used. Option D is wrong because kubelet is the primary node agent that communicates with the control plane, manages pod lifecycle, and reports node status; disabling it would effectively remove the node from the cluster.

Full explanation →

768

Multi-Selecteasy

Which TWO of the following are valid Kubernetes RuntimeClass handlers for container sandboxing? (Choose two.)

Select 2 answers

A.docker

B.runc

C.runsc

D.containerd

E.kata

AnswersC, E

gVisor's runtime handler is runsc.

Why this answer

Option A (runsc) is gVisor. Option C (kata) is Kata Containers. Option B (docker) is not a sandboxing runtime.

Option D (runc) is the default OCI runtime, not sandboxed. Option E (containerd) is a container runtime, not a sandboxing handler.

Full explanation →

769

MCQeasy

Which of the following is a best practice for securing container images in a CI/CD pipeline?

A.Using a minimal base image such as Alpine

B.Using the 'latest' tag for all base images to ensure the newest features

C.Running the container as root to avoid permission issues

D.Installing all available packages to ensure the application has all dependencies

AnswerA

Minimal images reduce vulnerabilities and attack surface.

Why this answer

Using a minimal base image like Alpine reduces the attack surface by minimizing the number of installed packages and potential vulnerabilities.

Full explanation →

770

MCQhard

A cluster administrator wants to apply a custom seccomp profile located at '/var/lib/kubelet/seccomp/audit.json' to a pod. Which YAML snippet correctly configures the pod's security context to use this profile?

A.seccompProfile: type: Localhost localhostProfile: audit.json

B.seccompProfile: type: Unconfined localhostProfile: audit.json

C.seccompProfile: type: Localhost localhostProfile: /var/lib/kubelet/seccomp/audit.json

D.seccompProfile: type: RuntimeDefault localhostProfile: audit.json

AnswerA

Correct: type is Localhost and localhostProfile is just the filename.

Why this answer

Option A is correct because when using a custom seccomp profile stored on the node, the `type` must be `Localhost` and the `localhostProfile` must specify only the filename (not the full path). Kubernetes automatically prepends the path `/var/lib/kubelet/seccomp/` to the filename, so `audit.json` resolves to the correct location.

Exam trap

CNCF often tests the misconception that `localhostProfile` requires the full filesystem path, when in fact only the filename is needed because Kubernetes prepends the kubelet's seccomp root directory.

How to eliminate wrong answers

Option B is wrong because `type: Unconfined` disables seccomp entirely and ignores the `localhostProfile` field, so the custom profile would not be applied. Option C is wrong because `localhostProfile` must be just the filename (e.g., `audit.json`), not the full path `/var/lib/kubelet/seccomp/audit.json`; Kubernetes appends the path from the kubelet's `--seccomp-default-profile` directory, and using the full path would cause a lookup failure. Option D is wrong because `type: RuntimeDefault` uses the container runtime's default seccomp profile (e.g., Docker's default), not a custom local profile, and the `localhostProfile` field is ignored when type is not `Localhost`.

Full explanation →

771

MCQeasy

Which crictl command is used to list all running containers managed by the container runtime?

A.crictl images

B.crictl stats

C.crictl ps

D.crictl pods

AnswerC

crictl ps lists containers.

Why this answer

crictl ps lists containers, similar to docker ps.

Full explanation →

772

MCQeasy

Which of the following is a CIS benchmark recommendation for securing the Kubernetes API server?

A.Disable audit logging to reduce overhead

B.Enable anonymous authentication

C.Use RBAC for authorization

D.Allow all service accounts to use cluster-admin

AnswerC

The CIS benchmark recommends using RBAC as the authorization mode to enforce least-privilege access.

Why this answer

C is correct because the CIS Benchmark for Kubernetes recommends using Role-Based Access Control (RBAC) to authorize API requests, ensuring that users and service accounts have only the minimum necessary permissions. RBAC is a core security control that restricts access based on roles, and its use is explicitly required to meet CIS compliance for the API server.

Exam trap

The trap here is that candidates may think disabling audit logging reduces performance overhead and is a valid optimization, but the CIS benchmark explicitly requires audit logging to be enabled for security compliance.

How to eliminate wrong answers

Option A is wrong because disabling audit logging violates the CIS benchmark recommendation to enable audit logging for security monitoring and forensics; audit logs are critical for detecting and investigating suspicious activity. Option B is wrong because enabling anonymous authentication is explicitly discouraged by the CIS benchmark, as it allows unauthenticated requests to the API server, bypassing identity verification. Option D is wrong because allowing all service accounts to use cluster-admin grants unrestricted cluster-wide privileges, which directly contradicts the principle of least privilege and the CIS recommendation to restrict cluster-admin access.

Full explanation →

773

MCQhard

A cluster's API server is configured with --authorization-mode=RBAC,Node. A kubelet attempts to create a ConfigMap. Which authorizer will evaluate the request?

A.Only the RBAC authorizer

B.Neither; the request is denied because Node authorizer does not allow ConfigMap creation

C.Both Node and RBAC authorizers, with Node first

D.Only the Node authorizer

AnswerC

The chain runs Node first; if Node permits, RBAC may not be needed. If Node denies, RBAC grants if permitted by RoleBindings.

Why this answer

When the API server is started with `--authorization-mode=RBAC,Node`, the request is evaluated by each authorizer in the order they are listed. The Node authorizer is designed to authorize kubelet requests, but it only permits specific node-related operations (e.g., reading secrets, creating pods, reporting node status). Creating a ConfigMap is not within the Node authorizer's allowed actions, so it will deny the request.

The request then passes to the RBAC authorizer, which will evaluate it based on the kubelet's RBAC bindings. Therefore, both authorizers are consulted, with Node first.

Exam trap

The trap here is that candidates assume the Node authorizer will automatically allow all kubelet requests, but in reality it only permits a restricted set of node-specific operations, and any request not matching those patterns is passed to the next authorizer in the chain.

How to eliminate wrong answers

Option A is wrong because the Node authorizer is listed before RBAC and will evaluate the request first; it does not skip the Node authorizer. Option B is wrong because the request is not denied outright; if the Node authorizer denies it, the RBAC authorizer still has a chance to allow it. Option D is wrong because the RBAC authorizer is also in the chain and will evaluate the request after the Node authorizer denies it.

Full explanation →

774

Matchingmedium

Match each Kubernetes command to its function related to security.

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

Concepts

Matches

Check whether an action is allowed for a user or service account

Approve a certificate signing request (CSR)

Run a temporary interactive pod for troubleshooting

Create a secret from literals, files, or directories

Apply a PodSecurityPolicy configuration (deprecated)

Why these pairings

These commands are commonly used for security operations and auditing.

Full explanation →

775

MCQmedium

Which of the following YAML snippets correctly configures a ServiceAccount with automountServiceAccountToken set to false?

A.apiVersion: v1 kind: ServiceAccount metadata: name: my-sa token: automount: false

B.apiVersion: v1 kind: ServiceAccount metadata: name: my-sa automountServiceAccountToken: false

C.apiVersion: v1 kind: Pod metadata: name: my-pod spec: serviceAccountName: my-sa automountServiceAccountToken: false

D.apiVersion: v1 kind: ServiceAccount metadata: name: my-sa automountServiceAccountToken: false

AnswerB

This is the correct syntax to disable automounting of the service account token for pods using this service account.

Why this answer

Option B is correct because it uses the correct field name `automountServiceAccountToken` at the top level of the ServiceAccount spec, which is the proper way to disable automatic mounting of the service account token in pods that use this ServiceAccount. This setting prevents the Kubernetes API token from being automatically injected into pods, enhancing security by reducing the attack surface for token theft.

Exam trap

CNCF often tests the distinction between setting `automountServiceAccountToken` on a ServiceAccount versus on a Pod, and the trap here is that candidates may confuse the correct placement (top-level spec vs. metadata) or think that setting it on a Pod is equivalent to configuring the ServiceAccount itself.

How to eliminate wrong answers

Option A is wrong because it uses a non-existent field `token` with a subfield `automount`, which is not a valid Kubernetes API structure for a ServiceAccount. Option C is wrong because it configures `automountServiceAccountToken` on a Pod spec, which is valid for disabling token mounting for that specific pod, but the question asks for a ServiceAccount configuration, not a Pod configuration. Option D is wrong because `automountServiceAccountToken` is placed under `metadata`, which is incorrect; it must be at the top level of the ServiceAccount spec, not nested under metadata.

Full explanation →

776

MCQhard

You are using External Secrets Operator to sync secrets from HashiCorp Vault. The operator is deployed but secrets are not being created. Which resource defines the mapping between Vault secrets and Kubernetes secrets?

A.ClusterSecretStore

B.ExternalSecret

C.VaultSecret

D.SecretStore

AnswerB

Correct. The ExternalSecret resource defines the source (Vault path) and the target Kubernetes secret name.

Why this answer

External Secrets Operator uses a custom resource called ExternalSecret (or sometimes SecretStore depending on the version) to define the mapping. The ExternalSecret resource specifies the backend (Vault) and the secret keys to sync.

Full explanation →

777

MCQmedium

An administrator wants to enforce that only images signed by a trusted key can run in the cluster. They have configured cosign and want to use a Kubernetes admission controller. Which tool should they deploy?

A.Helm

B.Kube-bench

C.Prometheus

D.Kyverno with a verifyImages rule

AnswerD

Kyverno can be configured to verify container image signatures using cosign.

Why this answer

Cosign integrates with Kubernetes via the cosign webhook or through policy engines like Kyverno. Kyverno can verify image signatures using cosign.

Full explanation →

778

MCQeasy

A security team wants to detect attempts to read /etc/shadow inside containers. Which Falco rule condition would trigger on a container reading that file?

A.evt.type=connect and fd.name=/etc/shadow

B.evt.type=execve and proc.name=cat

C.evt.type=open and container.id exists

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

AnswerD

This matches open syscalls on /etc/shadow.

Why this answer

Falco's open_read syscall condition with fd.name=/etc/shadow detects attempts to open the file for reading.

Full explanation →

779

MCQmedium

Which flag must be set on the kubelet to prevent it from using the default namespace for pods and to enforce that pods only use namespaces that match the node's assigned namespace?

A.--protect-kernel-defaults=true

B.--namespace-default=restricted

C.--authentication-token-webhook=true

D.--anonymous-auth=false

AnswerD

This flag disables anonymous access, but the question asks about namespace enforcement. Actually, the correct answer for namespace enforcement is not listed; the stem may be misleading. However, in the context of kubelet security, --anonymous-auth=false is a key CIS recommendation. For namespace enforcement, the NodeRestriction admission plugin is used. Given the options, B is the most relevant kubelet flag.

Why this answer

Option D is correct because setting `--anonymous-auth=false` on the kubelet prevents unauthenticated (anonymous) requests from being accepted. This forces all requests to the kubelet to be authenticated, and when combined with the `--authentication-token-webhook=true` flag (which is not the answer here), the kubelet can verify that the pod's service account token belongs to a namespace that matches the node's assigned namespace. Without this flag, anonymous users could bypass namespace enforcement and access pods in the default namespace.

Exam trap

CNCF often tests the misconception that `--authentication-token-webhook=true` alone enforces namespace restrictions, but the trap is that without disabling anonymous auth, unauthenticated requests can still bypass token validation entirely.

How to eliminate wrong answers

Option A is wrong because `--protect-kernel-defaults=true` is a security flag that ensures the kubelet does not modify kernel parameters (like sysctl settings) that could affect the host, but it has nothing to do with namespace enforcement or preventing the use of the default namespace. Option B is wrong because `--namespace-default=restricted` is not a valid kubelet flag; the kubelet does not have a flag to set a default namespace for pods, and namespace enforcement is handled via authentication and authorization, not a default namespace setting. Option C is wrong because `--authentication-token-webhook=true` enables the kubelet to use the Kubernetes API server's TokenReview API to validate bearer tokens (e.g., service account tokens), but by itself it does not prevent anonymous access or enforce namespace matching; it must be combined with `--anonymous-auth=false` to block unauthenticated requests.

Full explanation →

780

MCQmedium

An administrator wants to verify that an image was signed by a specific key before deploying. Which Cosign command should be used?

A.cosign verify --key mykey.pub myimage

B.cosign sign --key mykey.pub myimage

C.cosign download myimage

D.cosign attest --predicate mypredicate myimage

AnswerA

This verifies the image signature using the public key.

Why this answer

The 'cosign verify' command checks the signature against a public key and verifies the image.

Full explanation →

781

MCQmedium

A developer created a ClusterRole 'pod-reader' with rules to get, list, and watch pods. They bound it to a user via ClusterRoleBinding. The user reports they cannot list pods in namespace 'test'. What is the most likely cause?

A.The ClusterRole must be bound with a RoleBinding

B.The user needs a ServiceAccount

C.The ClusterRoleBinding might have a namespace set

D.The pod-reader ClusterRole is missing 'list' verb

AnswerC

If namespace is set, it becomes namespace-scoped, breaking access.

Why this answer

Option C is correct because a ClusterRoleBinding is cluster-scoped and does not have a namespace field, but if a RoleBinding is used instead, it can restrict permissions to a specific namespace. The most likely cause is that the user inadvertently created a RoleBinding in the 'test' namespace (or the ClusterRoleBinding was misconfigured with a namespace selector), which would limit the binding's effect to that namespace. Since the user cannot list pods in 'test', the binding likely has a namespace constraint, preventing the cluster-wide permissions from applying.

Exam trap

CNCF often tests the distinction between ClusterRoleBinding (cluster-wide) and RoleBinding (namespace-scoped), and the trap here is that candidates assume a ClusterRole always grants cluster-wide access, forgetting that the binding type (RoleBinding) can restrict it to a specific namespace.

How to eliminate wrong answers

Option A is wrong because a ClusterRole can be bound with either a ClusterRoleBinding (cluster-wide) or a RoleBinding (namespace-scoped); the issue is not about the binding type but about namespace restriction. Option B is wrong because a ServiceAccount is not required for a user to use a ClusterRoleBinding; users (like those authenticated via certificates or OIDC) can be bound directly without a ServiceAccount. Option D is wrong because the question states the ClusterRole 'pod-reader' has rules to get, list, and watch pods, so the 'list' verb is present; the problem is not a missing verb.

Full explanation →

782

MCQmedium

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

A.ConfigMap

B.EncryptionConfiguration

C.Secret

D.CustomResourceDefinition

AnswerB

EncryptionConfiguration is the custom resource used to configure encryption at rest for Kubernetes secrets and other resources.

Why this answer

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

Exam trap

CNCF often tests the misconception that creating a Secret resource itself enables encryption at rest, when in fact you must explicitly configure the EncryptionConfiguration and restart the API server to protect secrets stored in etcd.

How to eliminate wrong answers

Option A is wrong because a ConfigMap is used to store non-confidential configuration data as key-value pairs and does not provide encryption capabilities for secrets at rest. Option C is wrong because a Secret is the resource that stores sensitive data, but it is not the resource that configures encryption at rest; you need an EncryptionConfiguration to define how secrets are encrypted in etcd. Option D is wrong because a CustomResourceDefinition (CRD) extends the Kubernetes API with custom resources and has no role in enabling encryption at rest for existing built-in resources like secrets.

Full explanation →

783

MCQeasy

Which Linux capability must be added to a container to allow it to change the system time (e.g., using the 'date' command)?

A.CAP_SYS_NICE

B.CAP_SYS_RESOURCE

C.CAP_SYS_ADMIN

D.CAP_SYS_TIME

AnswerD

CAP_SYS_TIME allows setting the system clock and real-time clock.

Why this answer

The `CAP_SYS_TIME` capability is specifically required for a container to modify the system clock, including using the `date` command to set the time. Without this capability, the container's process will receive an EPERM error when attempting to change the system time, as the kernel enforces this restriction at the system call level (e.g., `settimeofday`, `clock_settime`).

Exam trap

CNCF often tests the distinction between `CAP_SYS_ADMIN` (a catch-all for many privileged operations) and `CAP_SYS_TIME` (the specific capability for clock manipulation), leading candidates to incorrectly select `CAP_SYS_ADMIN` because they assume it covers all system administration tasks.

How to eliminate wrong answers

Option A is wrong because `CAP_SYS_NICE` allows a process to raise or lower the nice value of other processes and set real-time scheduling priorities, but it does not grant permission to modify the system clock. Option B is wrong because `CAP_SYS_RESOURCE` controls resource limits (e.g., `setrlimit`, `setpriority`) and disk quota overrides, not time-setting operations. Option C is wrong because `CAP_SYS_ADMIN` is a broad capability that includes many privileged operations (e.g., `mount`, `swapon`, `setdomainname`), but changing the system time is specifically gated by `CAP_SYS_TIME`, not `CAP_SYS_ADMIN`; using `CAP_SYS_ADMIN` for this purpose would be an overprivilege and is not the correct capability.

Full explanation →

784

MCQmedium

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

A.crictl ps

B.crictl exec

C.crictl logs

D.crictl inspect

AnswerC

crictl logs <container-id> retrieves container logs.

Why this answer

crictl logs <container-id> displays logs from a container. crictl ps lists containers, crictl exec runs a command in a container, and crictl inspect shows detailed container information.

Full explanation →

785

MCQhard

You are a platform engineer at a financial services company. The production cluster runs a set of microservices that handle sensitive customer data. The cluster has been configured with Pod Security Standards (PSS) enforced via OPA/Gatekeeper. Recently, the security team identified that a new deployment of the `payment-processing` microservice is running with the `seccomp` profile set to `Unconfined`. This violates the company policy that requires all containers to use a runtime default seccomp profile. The deployment YAML does not explicitly set any security context for seccomp. The cluster's nodes are running containerd 1.6 with default seccomp profile enabled. The OPA constraint template checks that `securityContext.seccompProfile.type` is set to `RuntimeDefault` or `Localhost`. However, the deployment passes the OPA validation. What is the most likely reason the deployment is not being rejected by OPA, and how should you fix it?

A.The seccomp profile must be set via an admission controller, not OPA.

B.OPA/Gatekeeper is not properly installed or the constraint is not active.

C.The cluster's nodes do not support seccomp, so the profile is ignored.

D.The OPA constraint only checks pod-level `securityContext`, but the deployment uses container-level settings.

AnswerD

The constraint should iterate over containers in the pod spec to enforce seccomp at the container level.

Why this answer

Option D is correct because the OPA constraint template checks `securityContext.seccompProfile.type` at the pod level, but the deployment does not set any security context at the pod level. The seccomp profile is only set at the container level (or defaults to `Unconfined` by the runtime), and the OPA constraint does not inspect container-level `securityContext`. This mismatch allows the deployment to pass validation even though the container is running with an unconfined seccomp profile.

Exam trap

The trap here is that candidates assume OPA constraints automatically check all levels of securityContext, but they must be explicitly written to inspect container-level settings, and the default behavior of the runtime can lead to a false sense of security.

How to eliminate wrong answers

Option A is wrong because OPA/Gatekeeper can enforce seccomp profiles via constraints; admission controllers are not required for seccomp enforcement. Option B is wrong because the scenario states the cluster is configured with PSS enforced via OPA/Gatekeeper, and the constraint is active (it checks pod-level securityContext), so the issue is not installation or activation. Option C is wrong because the nodes run containerd 1.6 with default seccomp profile enabled, so seccomp is supported and the profile is not ignored.

Full explanation →

786

MCQmedium

An administrator deploys a Gatekeeper ConstraintTemplate with the following Rego policy: package k8srequiredlabels deny[{"msg": msg}] { input.request.kind.kind == "Pod" not input.request.object.metadata.labels["security-tier"] msg := "Pod must have label 'security-tier'" } After creating the Constraint, a user creates a Pod without the 'security-tier' label. What is the expected behavior?

A.The pod is created and the label is automatically added

B.The pod creation is denied with a message

C.Only the first pod without the label is denied; subsequent ones are allowed

D.The pod is created but logged as a violation

AnswerB

Correct. The deny rule blocks admission and returns the message.

Why this answer

Gatekeeper denies the request because the Rego policy denies pods missing the required label.

Full explanation →

787

MCQmedium

You need to detect when a container attempts to mount the host's Docker socket. Which Falco macro or condition would you use?

A.fd.name=/var/run/docker.sock

B.fd.name=/var/run/containerd.sock

C.fd.name=/var/run/docker

D.fd.name=/run/docker.sock

AnswerA

Why this answer

Falco has a default macro 'docker_socket' that matches the path '/var/run/docker.sock'. Using fd.name=/var/run/docker.sock in a condition will detect access to the socket. Option A is correct.

Option B is a valid path but not the standard. Option C is a directory. Option D is a different socket.

Full explanation →

788

MCQeasy

A DevOps team wants to ensure that only signed images from a trusted registry are deployed in the cluster. They plan to use a webhook to intercept pod creation. Which tool is best suited for this task?

A.kubectl with --validate flag

B.Helm with signed charts

C.etcd with encryption at rest

D.Kyverno with a verifyImages rule

E.Prometheus with alerting rules

AnswerD

Kyverno supports image signature verification via cosign.

Why this answer

Kyverno is a Kubernetes-native policy engine that can enforce image signature verification via its `verifyImages` rule. It intercepts pod creation through a dynamic admission webhook, checking that container images are signed with a trusted key (e.g., using Sigstore/Cosign) before the pod is admitted. This directly meets the requirement to only allow signed images from a trusted registry.

Exam trap

The trap here is that candidates confuse Helm chart signing (which verifies chart provenance) with container image signing, leading them to select Option B, even though Helm does not verify the images inside the chart at pod creation time.

How to eliminate wrong answers

Option A is wrong because `kubectl --validate` only performs client-side schema validation on the manifest, not image signature verification. Option B is wrong because Helm with signed charts ensures the Helm chart itself is signed, but does not verify the container images referenced within the chart at deployment time. Option C is wrong because etcd encryption at rest protects data stored in etcd (e.g., Secrets) but does not intercept pod creation or verify image signatures.

Option E is wrong because Prometheus with alerting rules monitors metrics and triggers alerts, but cannot enforce admission control or block pod creation based on image signatures.

Full explanation →

789

Multi-Selecthard

Which THREE of the following are true about Istio PeerAuthentication? (Select THREE.)

Select 3 answers

A.It can be used to enable mTLS for all workloads in a namespace

B.It configures how traffic is routed between services

C.It can specify TLS mode as STRICT, PERMISSIVE, or DISABLE

D.It requires a DestinationRule to define the TLS settings

E.It can be applied to specific workloads using label selectors

AnswersA, C, E

Correct.

Why this answer

PeerAuthentication defines mTLS mode at namespace or workload level, can be set to STRICT to require mTLS, and can override mesh-wide settings.

Full explanation →

790

MCQmedium

A service account 'monitor' needs to list pods in all namespaces. Which minimal RBAC configuration should you use?

A.ClusterRole with get pods, then ClusterRoleBinding

B.Role with get pods in kube-system, then RoleBinding

C.ClusterRole with get pods, then RoleBinding in default namespace

D.Role in each namespace with get pods, then RoleBinding

AnswerA

This grants the permission across all namespaces.

Why this answer

Option A is correct because a ClusterRole with 'get pods' permission grants access to pods across all namespaces, and a ClusterRoleBinding binds that ClusterRole to the 'monitor' service account cluster-wide. This is the minimal RBAC configuration for listing pods in all namespaces, as a Role and RoleBinding are namespace-scoped and cannot grant cross-namespace access.

Exam trap

The trap here is that candidates often confuse RoleBinding with ClusterRoleBinding, thinking a ClusterRole can be bound to a namespace via a RoleBinding to grant cluster-wide access, but RoleBinding only applies the permissions within that specific namespace.

How to eliminate wrong answers

Option B is wrong because a Role in kube-system with a RoleBinding only grants access to pods in the kube-system namespace, not all namespaces. Option C is wrong because a RoleBinding in the default namespace binds the ClusterRole only to that namespace, not cluster-wide, so the service account cannot list pods in other namespaces. Option D is wrong because creating a Role in each namespace with a RoleBinding is not minimal—it requires manual duplication and maintenance across all namespaces, whereas a single ClusterRoleBinding achieves the same goal more efficiently.

Full explanation →

791

MCQhard

You have deployed a DaemonSet to run a logging agent on every node. After an update, the new pods are stuck in 'Pending' state. You run 'kubectl describe pod ds-pod-xxxxx' and see '0/3 nodes are available: 3 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate'. What is the MOST likely cause?

A.The DaemonSet has a nodeSelector that doesn't match any nodes

B.The DaemonSet uses hostNetwork which conflicts with existing pods

C.The DaemonSet does not have tolerations for the node taints

D.The nodes are cordoned

AnswerC

The taint prevents scheduling unless the pod has a matching toleration.

Why this answer

The message indicates that the nodes have a taint that the pod does not tolerate. The DaemonSet likely does not have a toleration for the master taint, and if the cluster only has master nodes (or the DaemonSet is scheduled on masters), the pods cannot be scheduled.

Full explanation →

792

MCQhard

A pod is in a Pending state with the event: 'failed to generate spec: failed to validate seccomp profile: seccomp profile not found'. The profile is stored at /var/lib/kubelet/seccomp/custom.json on the node. Which of the following is the MOST likely cause?

A.The profile name is misspelled in the pod specification

B.The localhostProfile field contains an absolute path instead of a relative one

C.The node does not have seccomp enabled in the kubelet

D.The seccomp profile JSON is malformed

AnswerB

Correct. Kubernetes expects a relative path. Using an absolute path causes it to look for the file in an incorrect location.

Why this answer

The error 'seccomp profile not found' indicates the kubelet cannot locate the profile file. In Kubernetes, when using a seccomp profile stored on the node, the `localhostProfile` field must specify a relative path from the kubelet's seccomp root directory (default `/var/lib/kubelet/seccomp`). An absolute path like `/var/lib/kubelet/seccomp/custom.json` causes the kubelet to look for the file at that exact absolute path, but the seccomp validation logic expects a relative path and prepends the root, leading to a 'not found' error.

Exam trap

CNCF often tests the nuance that `localhostProfile` requires a relative path, not an absolute one, and candidates mistakenly think any valid filesystem path works or confuse this with container runtime seccomp paths.

How to eliminate wrong answers

Option A is wrong because a misspelled profile name would cause a different error (e.g., 'no such file or directory') but the error message explicitly says 'profile not found', not 'invalid name' or 'no such file'. Option C is wrong because if seccomp were not enabled in the kubelet, the pod would fail with a different error like 'seccomp is not enabled' or the pod would be rejected at admission, not with a 'profile not found' event. Option D is wrong because a malformed JSON would produce a 'failed to validate seccomp profile' error with details about parsing failure, not a 'not found' error.

Full explanation →

793

MCQeasy

Which tool is specifically designed to generate a Software Bill of Materials (SBOM) for container images?

A.Checkov

B.Cosign

C.Syft

D.Trivy

AnswerC

Syft is a CLI tool for generating SBOMs from container images and filesystems.

Why this answer

Syft is an open-source tool that generates SBOMs from container images and filesystems.

Full explanation →

794

MCQmedium

A cluster administrator wants to audit all pod creations and modifications using an admission webhook. Which resource type should be created to register the webhook?

A.ValidatingWebhookConfiguration

B.WebhookConfiguration

C.MutatingWebhookConfiguration

D.AdmissionWebhook

AnswerA

ValidatingWebhookConfiguration is used to register admission webhooks that can validate requests (allow/deny) based on custom logic.

Why this answer

ValidatingWebhookConfiguration is used for admission webhooks that validate (allow/deny) requests without modifying them.

Full explanation →

795

MCQmedium

A security audit reveals that etcd does not encrypt data at rest. Which resource must be created to enable encryption?

A.Secret with encryption key

B.Deployment for etcd with encryption flag

C.ConfigMap with encryption key

D.EncryptionConfiguration YAML file and pass it to the API server via --encryption-provider-config

AnswerD

The EncryptionConfiguration resource defines the encryption configuration.

Why this answer

Option D is correct because Kubernetes enables etcd data-at-rest encryption through an EncryptionConfiguration YAML file, which defines how to encrypt resources at the API server level. This file is passed to the kube-apiserver via the `--encryption-provider-config` flag, allowing providers like `aescbc` or `secretbox` to encrypt etcd data transparently.

Exam trap

The trap here is that candidates often confuse etcd encryption with TLS or secret management, assuming a Secret or ConfigMap alone enables encryption, when in fact the EncryptionConfiguration YAML is the mandatory resource that the API server reads to apply encryption at rest.

How to eliminate wrong answers

Option A is wrong because a Secret with an encryption key is not a resource that Kubernetes directly consumes for etcd encryption; the key must be referenced within an EncryptionConfiguration. Option B is wrong because etcd does not have a deployment or encryption flag in Kubernetes; encryption is configured on the API server, not etcd itself. Option C is wrong because a ConfigMap is not used for encryption keys; the EncryptionConfiguration is a dedicated YAML resource, and keys are typically stored in Secrets or files, not ConfigMaps.

Full explanation →

796

MCQmedium

You need to enable audit logging for the Kubernetes API server. Which three flags must be set?

A.--audit-log-path, --audit-policy-file, --audit-log-maxage

B.--audit-log-path, --audit-log-format, --audit-log-maxsize

C.--audit-log-path, --audit-log-maxage, --audit-log-maxsize

D.--audit-policy-file, --audit-log-maxage, --audit-log-maxbackup

AnswerA

These three flags enable audit logging, define the policy, and set log retention.

Why this answer

To enable audit logging in the Kubernetes API server, you must specify the path for the audit log file (`--audit-log-path`), the path to the audit policy file that defines which events to log (`--audit-policy-file`), and the maximum number of days to retain old audit log files (`--audit-log-maxage`). These three flags are the minimum required to activate and control basic audit logging, as the API server will not generate audit logs without a policy file and a log destination.

Exam trap

The trap here is that candidates assume `--audit-log-maxsize` or `--audit-log-maxbackup` are mandatory for rotation, but the CKS exam tests that `--audit-log-maxage` is the only rotation flag required alongside the path and policy file to enable basic audit logging.

How to eliminate wrong answers

Option B is wrong because `--audit-log-format` is optional (defaults to JSON) and not required to enable audit logging; the core requirement is the policy file and log path. Option C is wrong because it omits the mandatory `--audit-policy-file`, without which the API server will not apply any audit rules and will not log events. Option D is wrong because it lacks `--audit-log-path`, which is essential to specify where the log file is written; without it, no audit log file is created.

Full explanation →

797

MCQmedium

A pod named 'busybox-pod' is compromised. You want to isolate it from all other pods using a NetworkPolicy. Which YAML snippet correctly denies all ingress and egress traffic to/from the pod?

A.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate spec: podSelector: matchLabels: app: busybox egress: - to: - podSelector: {}

B.apiVersion: v1 kind: NetworkPolicy metadata: name: isolate spec: podSelector: {} policyTypes: - Ingress

C.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate spec: podSelector: matchLabels: app: busybox ingress: - from: - podSelector: {}

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

AnswerD

This policy selects the pod and specifies both policyTypes with no rules, which defaults to deny all ingress and egress.

Why this answer

A NetworkPolicy with podSelector matching the pod, empty ingress and egress rules (or policyTypes set to both and no rules) will deny all traffic. Option A uses the correct structure: podSelector to target the pod, policyTypes including both, and empty ingress/egress lists.

Full explanation →

798

MCQmedium

An administrator creates a custom seccomp profile and wants to apply it to a pod. The profile file is named 'audit.json' and is placed in the default seccomp directory on the node. Which securityContext field should be used?

A.securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.file: audit.json

B.securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.profile: audit.json

C.securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.localhostProfile: audit.json

D.seccomp.security.alpha.kubernetes.io/pod: localhost/audit.json

AnswerC

This is the correct way to specify a custom localhost seccomp profile in v1.29+.

Why this answer

In Kubernetes v1.29+, the seccomp profile is specified via 'securityContext.seccompProfile.type: Localhost' and 'securityContext.seccompProfile.localhostProfile: "audit.json"'. The default directory for localhost profiles is /var/lib/kubelet/seccomp/. Options A and B are incorrect because they use the old annotation-based approach or wrong field names.

Full explanation →

799

MCQmedium

A Falco rule has the condition: 'evt.type=open and fd.name contains /etc/shadow and container.id != host'. What is being detected?

A.Any process opening /etc/shadow on the host

B.A container process writing to /etc/shadow

C.A process reading /etc/passwd

D.A container process opening /etc/shadow

AnswerD

The condition matches open syscalls on /etc/shadow from processes in containers.

Why this answer

The rule detects open syscalls on files whose name contains '/etc/shadow', occurring outside the host (i.e., inside containers). This indicates a container process is opening the shadow file.

Full explanation →

800

MCQmedium

A company uses kube-bench to scan their cluster. The report shows a warning: 'Ensure that the --authorization-mode argument is set to Node,RBAC'. What is the best way to fix this?

A.Add --authorization-mode=AlwaysDeny to the API server

B.Restart the API server with --authorization-webhook-config-file

C.Set --authorization-mode=RBAC only

D.Edit the kube-apiserver manifest to add --authorization-mode=Node,RBAC

AnswerD

Sets both Node and RBAC as required.

Why this answer

Option D is correct because kube-bench checks that the API server's `--authorization-mode` includes both `Node` and `RBAC` in that order. The `Node` authorizer must come first to handle node-specific requests efficiently, followed by `RBAC` for user and service account authorization. Editing the kube-apiserver manifest (typically `/etc/kubernetes/manifests/kube-apiserver.yaml`) to add `--authorization-mode=Node,RBAC` ensures the static pod is automatically restarted by the kubelet with the correct configuration.

Exam trap

The trap here is that candidates may think setting only `RBAC` is sufficient because it is the most common authorization mode, but the CKS exam specifically tests the requirement that `Node` must precede `RBAC` to handle node-level authorization correctly.

How to eliminate wrong answers

Option A is wrong because `--authorization-mode=AlwaysDeny` is a deprecated mode that denies all requests, which would break the cluster entirely and does not satisfy the requirement for Node and RBAC. Option B is wrong because `--authorization-webhook-config-file` configures an external webhook authorizer, but the warning specifically requires Node and RBAC modes, not a webhook; adding a webhook without Node and RBAC would still fail the kube-bench check. Option C is wrong because setting `--authorization-mode=RBAC` only omits the `Node` authorizer, which is necessary for kubelet and node identity authorization; this would cause node-related requests to be incorrectly handled and fail the kube-bench check.

Full explanation →

801

MCQeasy

Which of the following fields in a PodSecurityPolicy (or Pod Security Standards) prevents a container from running as root?

A.runAsUser: RunAsAny

B.runAsGroup: MustRunAsNonRoot

C.runAsUser: MustRunAsNonRoot

D.seLinuxContext: MustRunAsNonRoot

AnswerC

This rule requires containers to run as non-root user.

Why this answer

Option C is correct because `runAsUser: MustRunAsNonRoot` in a PodSecurityPolicy (or the equivalent Pod Security Standard `restricted` profile) enforces that the container's user ID (UID) must not be 0 (root). This directly prevents the container from running as root, as the security context will reject any pod that specifies `runAsUser: 0` or omits the field when the policy requires a non-root user.

Exam trap

CNCF often tests the distinction between `runAsUser` and `runAsGroup`, where candidates mistakenly think setting `runAsGroup: MustRunAsNonRoot` prevents root execution, but it only restricts the group ID, not the user ID.

How to eliminate wrong answers

Option A is wrong because `runAsUser: RunAsAny` allows any user ID, including root (UID 0), so it does not prevent running as root. Option B is wrong because `runAsGroup: MustRunAsNonRoot` controls the group ID (GID), not the user ID; a container can still run as root (UID 0) even if its group is non-root. Option D is wrong because `seLinuxContext: MustRunAsNonRoot` is not a valid SELinux context option; SELinux contexts use `MustRunAs`, `RunAsAny`, or `MustRunAs` with a range, and `MustRunAsNonRoot` does not exist in the SELinux context field.

Full explanation →

802

Multi-Selecteasy

Which TWO of the following are valid audit stages in Kubernetes? (Choose two.)

Select 2 answers

A.ResponseFull

B.ResponseComplete

C.RequestReceived

D.RequestProcessing

E.RequestComplete

AnswersB, C

Valid stage.

Why this answer

Valid audit stages: RequestReceived, ResponseStarted, ResponseComplete, Panic. Options A and D are valid.

Full explanation →

803

Multi-Selecteasy

Which TWO of the following are recommended settings for the Kubernetes API server according to the CIS Kubernetes Benchmark? (Select TWO)

Select 2 answers

A.--authorization-mode=AlwaysAllow

B.--anonymous-auth=false

C.--authorization-mode=RBAC

D.--anonymous-auth=true

E.--enable-admission-plugins=AlwaysAdmit

AnswersB, C

Disables anonymous requests to the API server.

Why this answer

Option B is correct because the CIS Kubernetes Benchmark recommends disabling anonymous authentication by setting `--anonymous-auth=false` on the API server. This ensures that all requests must be authenticated, preventing unauthenticated access to the cluster's control plane.

Exam trap

CNCF often tests the distinction between authentication and authorization, so candidates may incorrectly think disabling anonymous auth is unnecessary if RBAC is enabled, but anonymous users can still bypass RBAC if anonymous auth is left on.

Full explanation →

804

MCQhard

A ClusterRole named 'secret-reader' is defined with rules to get, list, and watch secrets. A RoleBinding in namespace 'app' binds this ClusterRole to a service account. Which of the following best describes the permissions of the service account?

A.The service account has no permissions because ClusterRole cannot be used with RoleBinding.

B.The service account can only get secrets in the 'app' namespace.

C.The service account can get, list, and watch secrets in all namespaces.

D.The service account can get, list, and watch secrets only in the 'app' namespace.

AnswerD

RoleBinding grants permissions only in its namespace.

Why this answer

A RoleBinding in a specific namespace grants the permissions defined in the referenced ClusterRole, but only within that namespace. Since the RoleBinding is in the 'app' namespace, the service account receives the get, list, and watch permissions for secrets only within the 'app' namespace, not cluster-wide. This is the standard behavior of RoleBinding when binding to a ClusterRole.

Exam trap

The trap here is that candidates often confuse RoleBinding with ClusterRoleBinding, assuming that using a ClusterRole automatically grants cluster-wide permissions, when in fact the binding type determines the scope.

How to eliminate wrong answers

Option A is wrong because a ClusterRole can be used with a RoleBinding; the RoleBinding scopes the ClusterRole's permissions to the RoleBinding's namespace. Option B is wrong because the ClusterRole grants get, list, and watch permissions, not just get. Option C is wrong because a RoleBinding does not grant cluster-wide permissions; only a ClusterRoleBinding would grant permissions across all namespaces.

Full explanation →

805

MCQeasy

In the context of service mesh (e.g., Istio), which resource is used to enforce mutual TLS (mTLS) between services in a specific namespace?

A.PeerAuthentication

B.VirtualService

C.DestinationRule

D.ServiceEntry

AnswerA

Defines mTLS settings for workloads.

Why this answer

Option A is correct. PeerAuthentication is the Istio resource that defines the mTLS mode for workloads. DestinationRule is for traffic policies, not mTLS enforcement.

VirtualService is for routing. ServiceEntry is for external services.

Full explanation →

806

Multi-Selectmedium

Which TWO of the following are valid arguments for the kubectl command to create a secret from a file? (Select TWO)

Select 2 answers

A.--dry-run

B.--from-literal

C.--from-yaml

D.--from-file

E.--from-env-file

AnswersB, D

Creates secret from literal key-value pairs.

Why this answer

Options A and C are correct. '--from-file' creates a secret from a file; '--from-literal' from a literal string. Option B is for ConfigMaps. Option D is not a valid flag.

Option E is for a different purpose.

Full explanation →

807

Multi-Selectmedium

Which TWO actions are part of the CIS Kubernetes Benchmark recommendations?

Select 2 answers

A.Enable audit logging on the API server

B.Allow all service accounts to list secrets

C.Expose the API server on port 8080

D.Disable anonymous authentication on the API server

E.Use HTTP for kubelet communication

AnswersA, D

Audit logging is recommended for security monitoring.

Why this answer

Option A is correct because the CIS Kubernetes Benchmark recommends enabling audit logging on the API server to record all requests and responses, which is essential for security monitoring, forensics, and compliance. Audit logs capture the sequence of activities, including who performed an action, what resource was accessed, and the outcome, enabling detection of unauthorized or suspicious behavior.

Exam trap

CNCF often tests the misconception that disabling anonymous authentication is optional or that audit logging is only for debugging, when in fact both are mandatory hardening steps per the CIS Benchmark to prevent unauthorized access and ensure accountability.

Full explanation →

808

Multi-Selecthard

Which THREE of the following are valid ways to secure etcd in a Kubernetes cluster? (Select THREE)

Select 3 answers

A.Allow anonymous access to etcd for ease of management

B.Enable encryption at rest for etcd data

C.Expose etcd on a public IP for external monitoring

D.Use etcd RBAC to restrict access to the etcd datastore

E.Enable TLS client-to-server authentication

AnswersB, D, E

Encryption at rest protects data if etcd storage is compromised.

Why this answer

Option B is correct because enabling encryption at rest for etcd data ensures that the stored Kubernetes secrets and cluster state are encrypted on disk using a provider like AES-CBC or AES-GCM. This protects sensitive data if the underlying storage is compromised, and is a required hardening step for compliance with standards like PCI-DSS or SOC 2.

Exam trap

The trap here is that candidates may confuse 'encryption at rest' with 'encryption in transit' (which is TLS), or mistakenly think that etcd RBAC (Option D) is not a valid security measure, when in fact etcd supports its own RBAC via `etcdctl` commands to restrict access to keys and users.

Full explanation →

809

MCQhard

You are the lead security engineer for a large financial institution. The organization runs a Kubernetes cluster with 500+ microservices. The supply chain security team has implemented the following measures: (1) All images are built from a minimal base image (distroless) and scanned with Trivy before being pushed to a private registry. (2) Images are signed using cosign with a key stored in a hardware security module (HSM). (3) Kyverno policies enforce that only signed images from the private registry can run, and also enforce that containers run as non-root. (4) A binary authorization (binauthz) style admission controller verifies attestations. Recently, a critical vulnerability (CVE-2024-0001) was discovered in a popular open-source library used by several microservices. The library is included as a dependency in the base image. The vulnerability is remotely exploitable and has a CVSS score of 9.8. The security team needs to remediate this quickly. They have already patched the library and updated the base image. What is the BEST course of action to ensure all running pods use the new image?

A.Update the image tag in each Deployment's spec to point to the new patched image, then perform a rolling update. The admission controller will verify signatures and attestations for the new image.

B.SSH into each node, pull the new image, and use kubectl exec to update the library inside running containers.

C.Temporarily disable the admission controller that verifies signatures and then update the image tags.

D.Delete all running pods and let the ReplicaSets recreate them from the existing image.

AnswerA

This ensures all pods are updated with a verified, patched image in a controlled manner.

Why this answer

Option A is correct because updating the image tag in each Deployment triggers a rolling update, which creates new pods with the patched image. The admission controller (Kyverno) will verify the cosign signature and binary authorization attestation for the new image, ensuring supply chain security is maintained. This approach is the standard Kubernetes method for deploying image updates while preserving security controls.

Exam trap

CNCF often tests the misconception that manual intervention (SSH, exec) or disabling security controls is acceptable for urgent fixes, when in fact the correct path is to update the deployment manifest and let Kubernetes orchestrate the change while keeping all security checks active.

How to eliminate wrong answers

Option B is wrong because SSHing into nodes and using kubectl exec to update libraries inside running containers violates the immutable infrastructure principle; changes are ephemeral and lost on pod restart, and this bypasses admission controls, leaving pods unsigned and unverified. Option C is wrong because temporarily disabling the admission controller that verifies signatures creates a window where unsigned or malicious images could be deployed, undermining the entire supply chain security posture. Option D is wrong because deleting pods without updating the image tag causes ReplicaSets to recreate pods from the existing (vulnerable) image, failing to remediate the CVE.

Full explanation →

810

MCQeasy

Which of the following is a recommended practice for securing Kubernetes Dashboard?

A.Deploy Dashboard with minimal RBAC permissions and access it via kubectl proxy.

B.Expose Dashboard using a NodePort service with a ClusterRole binding to cluster-admin.

C.Use a LoadBalancer service without authentication.

D.Disable HTTPS and expose Dashboard on port 80.

AnswerA

Minimal permissions and kubectl proxy provide secure access without public exposure.

Why this answer

Option A is correct because deploying the Kubernetes Dashboard with minimal RBAC permissions and accessing it via `kubectl proxy` follows the principle of least privilege and avoids exposing the Dashboard to the network. `kubectl proxy` creates a local HTTP proxy to the Kubernetes API server, which authenticates the user's kubeconfig credentials, ensuring that only authorized users can reach the Dashboard and that the Dashboard itself has no direct network exposure.

Exam trap

The trap here is that candidates often think exposing the Dashboard via NodePort or LoadBalancer is acceptable for convenience, but the CKS exam emphasizes that any direct network exposure of the Dashboard without strong authentication and TLS is a critical security violation.

How to eliminate wrong answers

Option B is wrong because exposing the Dashboard via a NodePort service with a ClusterRole binding to `cluster-admin` grants unrestricted superuser access to anyone who can reach the NodePort, bypassing authentication and authorization controls. Option C is wrong because using a LoadBalancer service without authentication exposes the Dashboard to the internet or internal network without any credential check, allowing unauthorized access to the cluster. Option D is wrong because disabling HTTPS and exposing the Dashboard on port 80 transmits all traffic in cleartext, violating TLS encryption requirements and making the Dashboard vulnerable to man-in-the-middle attacks.

Full explanation →

811

MCQeasy

Which field must be set in a Pod's security context to prevent the container from running as the root user?

A.runAsUser: 1000

B.readOnlyRootFilesystem: true

C.allowPrivilegeEscalation: false

D.runAsNonRoot: true

AnswerD

Correct. This ensures the container is not running as root.

Why this answer

The 'runAsNonRoot: true' field in the Pod's security context enforces that the container cannot run as UID 0 (root).

Full explanation →

812

MCQhard

An OPA/Gatekeeper ConstraintTemplate is written to enforce that all Deployments have the label 'app.kubernetes.io/name'. However, the Constraint does not deny Deployments without the label. What is the most likely cause?

A.The Rego rule does not set 'violation' to true when the label is missing

B.The Constraint is not bound to any namespaces

C.The Deployment has the label set but with a different value

D.Gatekeeper is not installed in the cluster

AnswerA

Correct. The ConstraintTemplate must have a Rego rule named 'violation' that evaluates to true when the resource violates the policy.

Why this answer

Gatekeeper ConstraintTemplates use Rego to define violation rules. A common mistake is to use 'violation' with a generic message but not actually deny the request. The Rego must contain a 'deny' rule or use the 'violation' keyword correctly.

In Gatekeeper, the default Rego rule name is 'violation' and it must be set to true when a violation occurs. If the rule is empty or incorrectly written, it will not deny.

Full explanation →

813

MCQeasy

A developer runs 'trivy image myapp:latest' and gets a report with several CRITICAL CVEs. Which action would BEST address the supply chain security risk?

A.Ignore the report because the container is running in a sandboxed environment

B.Run 'trivy image myapp:latest --severity CRITICAL' to filter out lower severity findings

C.Rebuild the image using a minimal base image like distroless or alpine with no CVEs

D.Add a network policy to block outbound traffic from the container

AnswerC

Using a minimal base image reduces the attack surface and eliminates many CVEs.

Why this answer

The best practice is to rebuild the image using a minimal base image with no known vulnerabilities, reducing the attack surface.

Full explanation →

814

MCQeasy

Which of the following flags should be set to `false` to disable anonymous authentication to the Kubernetes API server?

A.--disable-anonymous=true

B.--auth-mode=RBAC

C.--anonymous-auth=false

D.--enable-anonymous-auth=false

AnswerC

This flag disables anonymous authentication.

Why this answer

Option C is correct because setting `--anonymous-auth=false` on the kube-apiserver disables anonymous requests. By default, anonymous authentication is enabled (set to `true`), allowing unauthenticated users to access the API server. Disabling it is a critical hardening step to prevent unauthorized access.

Exam trap

CNCF often tests the exact flag name and syntax, so the trap here is confusing `--anonymous-auth` with non-existent flags like `--disable-anonymous` or `--enable-anonymous-auth`, or mixing up authentication with authorization flags like `--authorization-mode`.

How to eliminate wrong answers

Option A is wrong because `--disable-anonymous=true` is not a valid kube-apiserver flag; the correct flag is `--anonymous-auth`. Option B is wrong because `--auth-mode=RBAC` is not a valid flag (the correct flag is `--authorization-mode=RBAC`) and it controls authorization, not authentication. Option D is wrong because `--enable-anonymous-auth=false` is not a valid flag; the correct flag is `--anonymous-auth` which takes a boolean value directly.

Full explanation →

815

MCQhard

A custom seccomp profile is defined as follows: { "defaultAction": "SCMP_ACT_ALLOW", "architectures": ["SCMP_ARCH_X86_64"], "syscalls": [ { "names": ["mkdir", "chmod"], "action": "SCMP_ACT_ERRNO" } ] } The profile is placed at /var/lib/kubelet/seccomp/deny-mkdir.json. Which pod securityContext configuration correctly applies this profile?

A.annotations: seccomp.security.alpha.kubernetes.io/pod: "localhost/deny-mkdir"

B.seccompProfile: type: Localhost localhostProfile: "deny-mkdir.json"

C.seccompProfile: type: localhost localhostProfile: "deny-mkdir.json"

D.seccompProfile: type: RuntimeDefault

AnswerB

This correctly references the local profile file.

Why this answer

Option B is correct because in Kubernetes, the `seccompProfile` field in the pod or container security context uses the `type: Localhost` (case-sensitive) and `localhostProfile` specifies the filename relative to the kubelet's seccomp root directory (`/var/lib/kubelet/seccomp/`). The profile file `deny-mkdir.json` is placed at that path, so `localhostProfile: "deny-mkdir.json"` correctly references it. This configuration blocks `mkdir` and `chmod` syscalls while allowing all others, as defined by the custom profile.

Exam trap

CNCF often tests the case-sensitivity of `type: Localhost` (capital 'L') versus the incorrect lowercase `localhost`, and the distinction between the deprecated annotation-based approach and the current `seccompProfile` field in the security context.

How to eliminate wrong answers

Option A is wrong because it uses the legacy annotation `seccomp.security.alpha.kubernetes.io/pod`, which was deprecated in Kubernetes v1.19 and removed in v1.25; the current stable API uses the `seccompProfile` field in the security context. Option C is wrong because `type: localhost` is not valid — the correct value is `type: Localhost` with a capital 'L' (case-sensitive). Option D is wrong because `type: RuntimeDefault` applies the container runtime's default seccomp profile (e.g., Docker's default), not the custom `deny-mkdir.json` profile stored on the node.

Full explanation →

816

MCQmedium

You are responding to a security incident where a pod named `compromised-pod` in namespace `default` is suspected of being used for cryptocurrency mining. You need to immediately isolate the pod from the network while preserving evidence. Which command sequence should you use?

A.kubectl cordon <node-of-compromised-pod>

B.kubectl run temp-pod --image=busybox --restart=Never -- /bin/sh -c 'kubectl label pod compromised-pod isolated=true' && kubectl apply -f networkpolicy.yaml that selects pod with label isolated=true and denies all traffic

C.kubectl delete pod compromised-pod && kubectl describe pod compromised-pod

D.kubectl exec compromised-pod -- killall miner-process

AnswerB

This creates a network policy that isolates the pod by denying all ingress/egress. The pod remains running for forensics.

Why this answer

Option B is correct: `kubectl run` creates a temporary network policy that denies all ingress and egress traffic to the pod, effectively isolating it. Option A deletes the pod, losing evidence. Option C labels the node, which does not isolate the pod.

Option D uses `kubectl exec` to stop the process, which may not work and is not isolation.

Full explanation →

817

Multi-Selecthard

Which THREE of the following are valid methods to restrict access to etcd in a Kubernetes cluster? (Select THREE)

Select 3 answers

A.Use TLS certificates for client and server authentication

B.Enable RBAC authorization in etcd

C.Use simple username and password authentication

D.Put etcd on the same network as the API server without firewall

E.Encrypt etcd data at rest

AnswersA, B, E

Mutual TLS ensures only authenticated clients can connect.

Why this answer

Option A is correct because etcd supports mutual TLS (mTLS) authentication, where both the client (e.g., kube-apiserver) and the etcd server present TLS certificates to verify each other's identity. This is the standard and recommended method for securing communication between the API server and etcd, as it prevents unauthorized clients from accessing the key-value store and ensures data-in-transit encryption.

Exam trap

CNCF often tests the misconception that etcd can use simple username/password authentication or that network placement alone is sufficient for security, when in fact TLS mutual authentication and encryption at rest are the required hardening measures.

Full explanation →

818

MCQmedium

A security team deploys the above pod and profile. The pod runs but a security scan reports that mount-related syscalls are being allowed instead of logged. What is the most likely reason?

A.The SYS_ADMIN capability overrides the seccomp policy.

B.The seccomp profile is not stored in the correct location, so the container runs without seccomp.

C.The defaultAction SCMP_ACT_ALLOW overrides the specific syscalls.

D.The profile uses SCMP_ACT_LOG which does not block syscalls; it only logs them.

AnswerB

The path is relative; profile must be in /var/lib/kubelet/seccomp/.

Why this answer

Option B is correct because the seccomp profile must be stored in `/var/lib/kubelet/seccomp/` for the `localhost` source to work. If the profile is placed elsewhere, the kubelet cannot read it, and the container runs without any seccomp restriction, allowing mount-related syscalls to proceed instead of being logged or blocked.

Exam trap

CNCF often tests the requirement that seccomp profiles must reside in `/var/lib/kubelet/seccomp/` for `localhost` profiles to be applied, and candidates mistakenly assume any valid path works or that the profile is silently ignored rather than causing a runtime failure.

How to eliminate wrong answers

Option A is wrong because SYS_ADMIN capability does not override seccomp; seccomp filters are enforced independently of capabilities, and capabilities cannot disable a seccomp profile. Option C is wrong because `defaultAction: SCMP_ACT_ALLOW` only sets the default action for syscalls not explicitly listed; it does not override the specific syscalls listed in the profile — those specific syscalls would still be handled by their own actions. Option D is wrong because `SCMP_ACT_LOG` does log syscalls without blocking them, but the question states syscalls are being allowed instead of logged, meaning the profile is not applied at all, not that it is applied with LOG action.

Full explanation →

819

MCQhard

A cluster administrator wants to ensure that all Secrets are encrypted at rest using AES-CBC with a key managed by the local Kubernetes API server. Which configuration is required?

A.Enable etcd encryption by setting --experimental-encryption-provider-config

B.Use Secret resource's 'data' field with base64 encoding

C.Set --encryption-provider-config flag to a file containing EncryptionConfiguration with 'aescbc' provider

D.Set --encryption-provider-config flag to a file containing EncryptionConfiguration with 'identity' provider

AnswerC

Correct. This enables AES-CBC encryption at rest.

Why this answer

EncryptionConfiguration with a provider of type 'aescbc' is used for AES-CBC encryption at rest.

Full explanation →

820

MCQmedium

Which Kubernetes admission controller is responsible for mutating and validating pod requests based on policies defined by OPA Gatekeeper?

A.PodSecurityPolicy

B.ValidatingAdmissionWebhook

C.ServiceAccount

D.NodeRestriction

AnswerB

Gatekeeper registers a ValidatingWebhookConfiguration to intercept and validate pod requests.

Why this answer

Gatekeeper uses the `ValidatingAdmissionWebhook` and `MutatingAdmissionWebhook` admission controllers. The question asks for the admission controller itself, which is `ValidatingAdmissionWebhook` for validation and `MutatingAdmissionWebhook` for mutation. Since OPA Gatekeeper primarily validates (though it can also mutate), the most directly involved admission controller for policy enforcement is ValidatingAdmissionWebhook.

Full explanation →

821

MCQeasy

A DevOps engineer needs to restrict the outbound network traffic from pods running in namespace 'secure-ns'. Which NetworkPolicy configuration achieves this by default?

A.Apply a NetworkPolicy that selects pods in 'secure-ns' and has an empty egress section.

B.Apply a NetworkPolicy that selects pods in 'secure-ns' and has an egress rule allowing all traffic.

C.No NetworkPolicy is needed because egress is denied by default.

D.Apply a NetworkPolicy that selects pods in 'secure-ns' and has an egress rule allowing traffic to port 53.

AnswerA

An empty egress rule blocks all egress traffic.

Why this answer

By default, Kubernetes NetworkPolicies are additive and deny-all unless explicitly allowed. Applying a NetworkPolicy with an empty egress section (no egress rules) to pods in 'secure-ns' effectively denies all outbound traffic from those pods, because the policy's egress field defaults to an empty list, which matches no traffic. This is the standard Kubernetes behavior for restricting egress.

Exam trap

The trap here is that candidates often assume egress is denied by default (Option C), but Kubernetes allows all egress until a NetworkPolicy explicitly restricts it, and an empty egress section in a policy is the correct way to achieve a deny-all for outbound traffic.

How to eliminate wrong answers

Option B is wrong because an egress rule allowing all traffic (e.g., an empty `to` and `ports` block) would permit all outbound traffic, not restrict it. Option C is wrong because egress is not denied by default; Kubernetes allows all egress traffic unless a NetworkPolicy explicitly restricts it. Option D is wrong because allowing traffic only to port 53 (DNS) would permit DNS queries but still deny all other outbound traffic, which is more permissive than the required full restriction.

Full explanation →

822

MCQmedium

An administrator wants to ensure that only signed container images are deployed in the cluster. Which admission controller can be used to enforce this policy?

A.ServiceAccount

B.AlwaysPullImages

C.ImagePolicyWebhook

D.NodeRestriction

AnswerC

ImagePolicyWebhook allows an external webhook to validate images, such as verifying Cosign signatures.

Why this answer

The ImagePolicyWebhook admission controller allows external webhooks to validate image signatures before accepting a pod. It can be configured to reject unsigned images.

Full explanation →

823

MCQmedium

An administrator wants to enforce mutual TLS (mTLS) between all services in an Istio service mesh. Which resource should be configured?

A.AuthorizationPolicy

B.ServiceEntry

C.VirtualService

D.PeerAuthentication

AnswerD

PeerAuthentication is used to configure mTLS mode (STRICT, PERMISSIVE, DISABLE) for workloads.

Why this answer

Option A is correct. PeerAuthentication defines the traffic policy for mTLS within a namespace or mesh. Option B is for routing to external services.

Option C is for traffic routing. Option D is for authorization, not mTLS enforcement.

Full explanation →

824

MCQmedium

An administrator wants to enforce the Pod Security Standard 'restricted' for all pods in the 'secure' namespace. Which kubectl command correctly enables the PodSecurity admission controller for that namespace?

A.kubectl annotate ns secure pod-security.kubernetes.io/enforce=restricted

B.kubectl label ns secure pod-security.kubernetes.io/enforce=restricted

C.kubectl label ns secure pod-security.kubernetes.io/enforce-version=restricted

D.kubectl label ns secure pod-security.kubernetes.io/audit=restricted

AnswerB

This sets the enforce level to restricted on the namespace, causing admission to reject pods that violate the restricted policy.

Why this answer

Option B is correct because the Pod Security Standards are enforced on namespaces using the `pod-security.kubernetes.io/enforce` label set to the desired policy level (e.g., `restricted`). The `kubectl label` command applies this label to the namespace, which triggers the PodSecurity admission controller to enforce the restricted policy on all pods created in that namespace.

Exam trap

The trap here is confusing labels with annotations or mixing up the `enforce`, `audit`, and `warn` modes, leading candidates to choose an annotation or the wrong label key for enforcement.

How to eliminate wrong answers

Option A is wrong because Pod Security Standards are configured via labels, not annotations; the `pod-security.kubernetes.io/enforce` key must be a label for the admission controller to recognize it. Option C is wrong because `enforce-version` is a separate label used to pin a specific version of the policy (e.g., `v1.24`), not to set the enforcement level; setting it to `restricted` is invalid. Option D is wrong because the `audit` label only enables audit-level logging of policy violations without enforcing them; the question specifically asks to enforce the restricted standard.

Full explanation →

825

MCQeasy

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

A.--anonymous-auth-enabled=false

B.--enable-anonymous-auth=false

C.--anonymous-auth=false

D.--disable-anonymous

AnswerC

This flag disables anonymous authentication as required by CIS benchmarks.

Why this answer

Option C is correct because the `--anonymous-auth=false` flag on the kube-apiserver disables anonymous authentication. When this flag is set to false, the API server rejects requests from unauthenticated users, enforcing that all requests must present valid credentials. This is a critical hardening measure to prevent unauthorized access to the cluster control plane.

Exam trap

The trap here is that candidates confuse the kube-apiserver flag syntax with similar flags from other Kubernetes components (e.g., kubelet's `--anonymous-auth-enabled`), leading them to pick the incorrect `--anonymous-auth-enabled=false` option.

How to eliminate wrong answers

Option A is wrong because `--anonymous-auth-enabled=false` is not a valid kube-apiserver flag; the correct flag is `--anonymous-auth` without the `-enabled` suffix. Option B is wrong because `--enable-anonymous-auth=false` is also not a valid flag; the kube-apiserver uses `--anonymous-auth` to control anonymous access, not `--enable-anonymous-auth`. Option D is wrong because `--disable-anonymous` is not a recognized flag; the kube-apiserver does not have a `--disable-anonymous` option, and the correct approach is to set `--anonymous-auth=false`.

Full explanation →

Certified Kubernetes Security Specialist CKS (CKS) — Questions 751–825