Certified Kubernetes Security Specialist CKS CKS Questions 676–750 | Page 10/12

676

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

This is correct: DaemonSet pods, like all pods, are subject to taints and tolerations. If a node has a taint, the DaemonSet pod template must include the matching toleration; otherwise, the scheduler will leave the pod Pending with an event like '0/N nodes are available: N node(s) had taint {key=value:NoSchedule}, that the pod didn't tolerate.' The DaemonSet controller can only create pods; it cannot bypass the scheduler's taint rules.

Why this answer

The error message indicates that the pod cannot be scheduled because all three nodes have a taint (specifically `node-role.kubernetes.io/master`), and the DaemonSet's pod template does not include a corresponding toleration. By default, control-plane nodes are tainted to prevent general workloads from running on them, so a DaemonSet intended to run on all nodes must include tolerations for these taints. Without tolerations, the scheduler will not place the pod on tainted nodes, leaving it in Pending state.

Exam trap

The trap here is that candidates often assume DaemonSets automatically run on all nodes regardless of taints, but in reality, DaemonSets respect taints and tolerations just like any other workload, and failing to add tolerations for control-plane taints is a common misconfiguration.

How to eliminate wrong answers

Option A is wrong because a nodeSelector mismatch would produce a different error (e.g., '0/3 nodes are available: 3 node(s) didn't match node selector'), not a taint-related message. Option B is wrong because hostNetwork conflicts would cause pod startup failures (e.g., port collisions) or CrashLoopBackOff, not a scheduling failure due to taints. Option D is wrong because cordoned nodes would show a specific condition like 'node(s) cordoned' in the describe output, not a taint-based message; cordoning prevents new pods from being scheduled but does not produce a taint-related error.

Full explanation →

677

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 scans container image layers and filesystem contents to produce an SBOM listing installed packages and their versions, satisfying the requirement to catalogue image components. Unlike general vulnerability scanners, its purpose is SBOM generation itself, outputting SPDX or CycloneDX formats directly from image references.

Why this answer

Syft is an open-source CLI tool developed by Anchore specifically for generating Software Bill of Materials (SBOMs) from container images and filesystems. It uses static analysis to catalog packages, libraries, and dependencies in formats such as CycloneDX and SPDX, making it the correct choice for this purpose.

Exam trap

CNCF-CKS often tests the distinction between tools that generate SBOMs (Syft) and tools that scan for vulnerabilities (Trivy) or sign images (Cosign), leading candidates to confuse Trivy's vulnerability scanning capability with SBOM generation.

How to eliminate wrong answers

Option A is wrong because Checkov is a static analysis tool for infrastructure as code (IaC) security scanning, not an SBOM generator. Option B is wrong because Cosign is a tool for signing and verifying container image signatures using Sigstore, not for generating SBOMs. Option D is wrong because Trivy is a vulnerability scanner for containers and filesystems, and while it can produce SBOM-like output, it is not specifically designed as a dedicated SBOM generator like Syft.

Full explanation →

678

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

A ValidatingWebhookConfiguration is the correct admissionregistration.k8s.io resource for registering a webhook that checks any matching API request. When a Pod creation is attempted, the API server serializes an AdmissionReview object and the webhook can return allowed:false to deny it. This enables custom, cluster-wide audit or validation policies without altering the submitted Pod spec.

Why this answer

A ValidatingWebhookConfiguration is the correct resource type to register an admission webhook that audits pod creations and modifications. This resource tells the API server which external HTTP callbacks to invoke during the admission process, specifically for validation (non-mutating) purposes. It defines the rules for matching API requests (e.g., operations like CREATE and UPDATE on pods) and the webhook endpoint that receives AdmissionReview requests.

Exam trap

The CKS exam often tests the distinction between ValidatingWebhookConfiguration and MutatingWebhookConfiguration, trapping candidates who assume any admission webhook uses a generic 'WebhookConfiguration' or that auditing requires mutation.

How to eliminate wrong answers

Option B (WebhookConfiguration) is wrong because no such top-level API resource exists in Kubernetes; the correct terms are ValidatingWebhookConfiguration and MutatingWebhookConfiguration. Option C (MutatingWebhookConfiguration) is wrong because it is used for webhooks that modify objects before they are persisted, not for auditing (read-only validation). Option D (AdmissionWebhook) is wrong because it is not a Kubernetes API resource; it is a generic concept referring to the admission webhook mechanism, not a specific configuration object.

Full explanation →

679

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

This is the standard and correct method: you define an EncryptionConfiguration YAML file that lists the encryption providers (e.g., aescbc, aesgcm, secretbox, identity) and the resources to encrypt (e.g., secrets, configmaps), then pass the file path to the kube-apiserver using the --encryption-provider-config flag. The API server uses the first non-identity provider to encrypt data before writing to etcd, and all listed providers are tried for decryption, enabling key rotation. The file must be readable by the kube-apiserver process and protected with restrictive permissions.

Why this answer

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 →

680

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 is the correct isolation policy because it selects only the compromised pod using its `app: busybox` label and declares both `Ingress` and `Egress` in `policyTypes` while omitting any allow rules. According to NetworkPolicy semantics, when a policy isolates a traffic direction and contains no rules for that direction, all traffic of that type is denied. Therefore this policy enforces a complete default-deny on both inbound and outbound traffic for the busybox pod, cutting off all network communication with it.

Why this answer

It uses the correct apiVersion (networking.k8s.io/v1) and explicitly specifies both Ingress and Egress in policyTypes with an empty rules array, which denies all ingress and egress traffic to/from the selected pod. Without any rules, the policy defaults to denying all traffic of the specified types, effectively isolating the pod.

Exam trap

A common mistake is omitting 'policyTypes' or only specifying one direction, thinking that an empty rules block alone denies all traffic. You must explicitly list both Ingress and Egress in policyTypes to block both directions.

How to eliminate wrong answers

Option A is wrong because it only defines an egress rule allowing traffic to all pods (empty podSelector matches all pods), which permits egress traffic instead of denying it, and it omits policyTypes, so ingress traffic is not restricted. Option B is wrong because it uses apiVersion v1 (which is incorrect for NetworkPolicy; the correct group is networking.k8s.io/v1), and it only specifies Ingress in policyTypes with no rules, so egress traffic is not denied. Option C is wrong because it only defines an ingress rule allowing traffic from all pods (empty podSelector matches all pods), which permits ingress traffic instead of denying it, and it omits policyTypes, so egress traffic is not restricted.

Full explanation →

681

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 syntax in v1.29 and later: type: Localhost tells the kubelet to load a profile from the node's seccomp profile directory, and localhostProfile: audit.json specifies the exact file name. The file must be present on the node under the kubelet's seccomp root (commonly /var/lib/kubelet/seccomp) before the Pod can start. This field was added to replace the old annotation, and it is the stable, validated API for custom profiles.

Why this answer

In Kubernetes, when using a custom seccomp profile stored on the node's default seccomp directory, the `securityContext.seccompProfile.type` must be set to `Localhost` and the profile filename is specified via the `localhostProfile` field. This field expects the filename (e.g., `audit.json`) relative to the node's default seccomp path (`/var/lib/kubelet/seccomp`). The `type: Localhost` instructs kubelet to load the profile from the node's filesystem.

Exam trap

The CKS exam often tests the distinction between the deprecated annotation-based approach and the current `securityContext.seccompProfile` fields, and the trap here is that candidates confuse the field name `localhostProfile` with `file` or `profile`, or mistakenly think the annotation is still the standard method.

How to eliminate wrong answers

Option A is wrong because `securityContext.seccompProfile.file` is not a valid field; the correct field name is `localhostProfile`. Option B is wrong because `securityContext.seccompProfile.profile` is not a valid field; the correct field is `localhostProfile`. Option D is wrong because the annotation `seccomp.security.alpha.kubernetes.io/pod` is a deprecated alpha API that was used in older Kubernetes versions (pre-1.19) and is not the current recommended way; the modern approach uses the `securityContext.seccompProfile` field.

Full explanation →

682

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

Editing the kube-apiserver static manifest under /etc/kubernetes/manifests to add --authorization-mode=Node,RBAC is exactly what the CIS benchmark expects. This enables the Node authorizer for kubelet requests and the RBAC authorizer for all other identities, covering the two essential authorization paths. The kubelet will detect the manifest change and restart the API server as a static pod. This is the recommended configuration identified by kube-bench.

Why this answer

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 →

683

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

MustRunAsNonRoot for runAsUser validates the container's effective user ID: if the image's USER directive is root or the pod explicitly sets securityContext.runAsUser: 0, admission rejects the pod. This is the standard control for enforcing non-root execution because it directly governs the UID that determines privilege in Linux. This is the correct answer.

Why this answer

`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 →

684

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

ResponseComplete is one of the four valid Kubernetes audit stages. It fires after the HTTP response has been fully transmitted to the client, meaning the audit event can include the complete response body, status code, and headers. This stage is essential for capturing full-response data for forensic analysis, though it may produce larger audit logs than earlier stages.

Why this answer

In Kubernetes auditing, the audit policy defines stages that determine at which points in the request lifecycle an audit event is recorded. Option B, ResponseComplete, is a valid stage that logs an event after the API server has finished sending the response to the client, capturing the final outcome. Option C, RequestReceived, is a valid stage that logs an event as soon as the API server receives the request, before any processing occurs.

The other options are not valid Kubernetes audit stages: ResponseFull, RequestProcessing, and RequestComplete do not exist in the audit.k8s.io API; the actual stages are RequestReceived, ResponseStarted, ResponseComplete, and Panic.

Exam trap

The trap is confusing the exact names of audit stages; candidates might recall 'RequestComplete' or 'ResponseFull' instead of the correct 'ResponseComplete' and 'RequestReceived'.

Full explanation →

685

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

Configuring --anonymous-auth=false ensures that requests that do not present valid client certificates, bearer tokens, or other accepted credentials are rejected with an HTTP 401 response before they reach authorization. This eliminates the anonymous user and the system:unauthenticated group from the API server's identity model. Disabling anonymous authentication is a core hardening measure recommended by the CIS Kubernetes Benchmark because it prevents unauthenticated network attackers from even attempting to access the cluster. In combination with RBAC, it enforces that every request is attributable to a real identity.

Why this answer

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 →

686

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

A RoleBinding always confines the granted permissions to the namespace in which it is created, regardless of whether the referenced role is a Role or ClusterRole. Here, the RoleBinding resides in the app namespace and references the 'secret reader' ClusterRole, which permits get, list, and watch on secrets. Therefore, the service account receives exactly those verbs on secrets exclusively within the app namespace, making this statement correct.

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 →

687

Multi-Selectmedium

A platform team is hardening a namespace that runs tenant workloads. They want runtime detection that flags container escapes and unexpected privilege changes. Which TWO Falco rule fields or conditions are most appropriate to detect these behaviors? (Choose two.)

Select 2 answers

A.evt.type in (mount, umount2) with proc.name = runc or a condition on the mount source

B.evt.type in (setuid, setgid) with a condition on the container image or user

C.evt.type = execve and proc.name = kubectl

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

E.evt.type = open and fd.name contains /etc/passwd

AnswersA, B

Unexpected mount or umount2 activity attributed to a runtime helper or a container process often accompanies container escape techniques that remount host paths or pivot into the host filesystem. Alerting on these syscalls with a source or process constraint highlights tampering that is rare in normal tenant workload operation.

Why this answer

Detecting container escapes and privilege changes calls for syscall-level signals tied to confinement boundaries. Watching setuid and setgid transitions catches attempts to gain effective privileges, while monitoring mount and umount2 activity with a runtime or source constraint surfaces tampering with the filesystem namespace. Both are low-noise, high-signal conditions for tenant workloads compared with generic shell or file-read detections.

Exam trap

The trap here is choosing familiar file-read or shell-spawn detections for escape scenarios, when escapes and privilege changes are better surfaced by setuid, setgid, mount, and umount2 syscall activity.

Full explanation →

688

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

The PeerAuthentication custom resource defines the mTLS mode that workloads must adopt when receiving connections from other services in the mesh. It supports modes like STRICT, PERMISSIVE, and DISABLE, and is enforced by the sidecar Envoy proxies on the server side. This is the security policy resource that directly governs mTLS settings, making it the correct answer.

Why this answer

PeerAuthentication is the correct resource because it defines the mutual TLS (mTLS) mode for workloads within a namespace or mesh. In Istio, PeerAuthentication allows you to enforce STRICT mTLS, which requires all traffic between services in the specified namespace to use TLS certificates for both client and server authentication, preventing plaintext or unauthenticated communication.

Exam trap

The CKS exam often tests the distinction between PeerAuthentication (for mTLS enforcement on incoming traffic) and DestinationRule (for TLS settings on outgoing traffic), causing candidates to confuse the two resources.

How to eliminate wrong answers

Option B (VirtualService) is wrong because it is used for traffic routing, such as canary deployments or A/B testing, not for enforcing mTLS policies. Option C (DestinationRule) is wrong because it defines traffic policies like load balancing or connection pool settings, and while it can configure TLS settings for outgoing traffic, it does not enforce mTLS on incoming requests at the namespace level. Option D (ServiceEntry) is wrong because it is used to add external services to the mesh for traffic management, not to enforce authentication policies between internal services.

Full explanation →

689

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

AnswersD, E

--from-file reads a file's content and creates a secret entry with the filename as the key and the file content as the value. This is a valid method to create a secret from a file.

Why this answer

Options D and E are correct because both --from-file and --from-env-file are valid arguments for the kubectl create secret command when creating a secret from a file. --from-file reads the entire file content and uses the filename as the key. --from-env-file reads a file containing key=value lines, which is suitable for environment variable-style secrets. Option B (--from-literal) is incorrect because it specifies key-value pairs directly on the command line, not from a file. Option A (--dry-run) is a flag, not an argument for specifying secret data.

Option C (--from-yaml) is not a valid argument for kubectl create secret.

Exam trap

The exam may trick candidates into selecting --from-literal (B) because they misinterpret 'from a file' as including inline data, or they may dismiss --from-env-file (E) believing it is only for ConfigMaps. Actually, --from-env-file works for both ConfigMaps and Secrets, so it is a valid method to create a secret from a file.

Full explanation →

690

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 on the API server creates a chronological, tamper-evident record of every request, including the user, source IP, verb, resource, and response status. The CIS benchmark mandates this so that security teams can detect brute-force attacks, unauthorized privilege escalation, or policy violations after the fact and support forensic analysis in an incident. Without audit logs, cluster actions are effectively unobservable, making compliance audits and postmortems nearly impossible.

Why this answer

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 →

691

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

Enabling encryption at rest for etcd data ensures that if the etcd data directory is exfiltrated, stolen, or accessed at the filesystem level, the stored objects remain unreadable without the encryption keys. In Kubernetes, the API server performs this encryption before writing to etcd, using options like AES-GCM or a KMS provider. This protects sensitive resources such as Secrets from exposure via disk compromise. However, it does not secure data in transit, which is handled separately by TLS.

Why this answer

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 →

692

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

Updating the image tag in each Deployment's PodTemplateSpec is the correct declarative approach: it triggers a rolling replacement of the underlying ReplicaSets, so old pods are terminated only after new ones become Ready. During pod creation, the cluster's validating/mutating admission controller (e.g., Kyverno or OPA via cosign) checks the image's cryptographic signature and attestations; if the patched image is signed and passes policy, the update proceeds. This ensures every pod runs a verified, patched image with zero downtime.

Why this answer

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 →

693

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

Running the Dashboard through kubectl proxy leverages the Kubernetes API server's authentication and authorization, so the Dashboard never binds to a publicly reachable address and all requests are tunneled over the proxy using your kubeconfig credentials. Assigning minimal RBAC permissions, such as a namespace-scoped or read-only role, ensures that even if a session is compromised, the attacker's blast radius is limited to the least privileges required. This combination prevents public exposure and enforces the principle of least privilege without sacrificing usability.

Why this answer

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 →

694

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

Setting runAsNonRoot: true makes the kubelet reject any container whose image or configuration would start as UID 0, satisfying the stem's prevention requirement. It enforces non-root execution at admission and runtime rather than merely documenting intent.

Why this answer

The `runAsNonRoot: true` field in a Pod's security context enforces that the container's entrypoint cannot run as UID 0 (root). If the container image attempts to run as root, the container runtime (e.g., containerd) will reject the container from starting, ensuring compliance with the principle of least privilege and mitigating root-based container escapes.

Exam trap

The CKS exam often tests the distinction between `runAsUser` (which sets the user but does not enforce non-root) and `runAsNonRoot` (which enforces non-root), leading candidates to mistakenly choose `runAsUser: 1000` thinking it prevents root execution.

How to eliminate wrong answers

Option A is wrong because `runAsUser: 1000` sets a specific user ID (1000) for the container process, but it does not prevent running as root; if the image is configured to run as root, this field can be overridden or ignored unless combined with `runAsNonRoot: true`. Option B is wrong because `readOnlyRootFilesystem: true` makes the container's root filesystem read-only, which protects against writes to the filesystem but does not restrict the user ID of the process; the container could still run as root. Option C is wrong because `allowPrivilegeEscalation: false` prevents the process from gaining more privileges than its parent (e.g., via setuid binaries), but it does not prevent the container from initially running as root; a root process with no escalation is still root.

Full explanation →

695

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

Rebuilding the image with a minimal base image such as distroless or a slim alpine variant is the correct remediation because these bases contain only the runtime dependencies needed for the application, eliminating the package manager, shell, and other tools that often carry CVEs. By reducing the number of installed packages, the attack surface is significantly minimized, and many reported vulnerabilities are directly removed from the image. This approach addresses the root cause of the vulnerabilities rather than masking them, and aligns with the security principle of least privilege applied to container images.

Why this answer

Rebuilding the image using a minimal base image like distroless or Alpine directly eliminates the vulnerable packages that cause the CRITICAL CVEs. This addresses the root cause of the supply chain risk by ensuring the container image contains only the necessary runtime dependencies, reducing the attack surface and removing known vulnerabilities at the source.

Exam trap

This exam often tests the misconception that security controls like sandboxing or network policies are sufficient to fix vulnerabilities, when in fact supply chain security requires eliminating the vulnerable components at the image build stage.

How to eliminate wrong answers

Option A is wrong because a sandboxed environment (e.g., gVisor, Kata Containers) does not eliminate the underlying vulnerable code; it only adds a layer of isolation, and a CRITICAL CVE could still be exploited if the sandbox is bypassed or if the vulnerability allows privilege escalation. Option B is wrong because filtering the report with '--severity CRITICAL' only hides lower-severity findings from the output; it does not fix or remove the actual vulnerabilities, leaving the supply chain risk unaddressed. Option D is wrong because a network policy blocking outbound traffic (e.g., Kubernetes NetworkPolicy) mitigates data exfiltration but does not remove or patch the vulnerable packages; the CRITICAL CVE could still be exploited locally or via inbound attacks.

Full explanation →

696

MCQhard

A security engineer is configuring a Kubernetes cluster to enforce that all container images are signed by a trusted key before deployment. They deploy the Cosign admission controller and configure it with a public key. However, they notice that some pods are still being admitted with unsigned images. What is the most likely cause?

A.The Cosign admission controller is configured with a failure policy of Ignore, so if the webhook is unavailable, pods are admitted.

B.The container runtime is configured to skip signature verification for images from certain registries.

C.The admission controller's namespaceSelector or objectSelector excludes the namespaces where these pods are being created.

D.The public key used by the admission controller is incorrect, causing it to fail open and admit all images.

AnswerC

Admission webhooks can be scoped using namespaceSelector or objectSelector. If the namespaces where unsigned pods are deployed are excluded, the webhook will not be invoked for those pods. This would allow unsigned images to be admitted without verification. This is a common misconfiguration that can silently bypass enforcement.

Why this answer

Admission webhooks can be selectively applied based on namespace or object labels. If the namespaceSelector in the webhook configuration does not match the namespaces where pods are created, the webhook is bypassed. This allows unsigned images to be admitted.

Checking the webhook's scope is essential to ensure it applies cluster-wide or to all relevant namespaces.

Exam trap

The trap here is overlooking the scope of admission webhooks, assuming that deploying the webhook automatically enforces the policy everywhere without checking selectors.

Full explanation →

697

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

--anonymous-auth=false is the correct flag to disable anonymous authentication in the Kubernetes API server. This boolean flag defaults to true, allowing unauthenticated requests to be associated with the `system:anonymous` user and `system:unauthenticated` group. Setting it to false causes requests without valid credentials to be rejected with a 401 Unauthorized before any authorization checks are performed.

Why this answer

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 →

698

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 is the correct approach. The field seccompProfile is part of the Pod securityContext, and type: Localhost tells kubelet to load a custom profile file from the kubelet's seccomp localhost directory (typically /var/lib/kubelet/seccomp/). The localhostProfile field must contain the exact filename (e.g., deny-mkdir.json) that exists on the node, and the profile file must be valid JSON defining syscall rules, such as returning EPERM for mkdir and mkdirat. This configuration precisely applies the custom deny-mkdir profile to the pod's containers.

Why this answer

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 →

699

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 label pod compromised-pod isolated=true && kubectl apply -f networkpolicy.yaml

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

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

AnswerB

Ly identifies the need to label the pod and apply a deny-all NetworkPolicy. The command sequence is impractical (busybox lacks kubectl), but the concept is what the exam tests. In a real scenario, you would label the pod directly and then apply the policy.

Why this answer

The correct approach is to label the pod and apply a deny-all NetworkPolicy that selects pods with that label. This immediately isolates the pod from all network traffic while preserving the pod for forensic analysis. The command sequence is: kubectl label pod compromised-pod isolated=true && kubectl apply -f networkpolicy.yaml where the networkpolicy.yaml defines an ingress/egress deny-all policy for pods with label isolated=true.

Exam trap

In the CKS exam, a common trap is confusing node-level controls (cordon, drain) with pod-level network isolation (NetworkPolicy). Candidates may think cordoning a node isolates the pod, or that deleting the pod is sufficient containment, but deleting destroys forensic evidence.

How to eliminate wrong answers

Option A is wrong because `kubectl cordon` marks a node as unschedulable, preventing new pods from being scheduled on it, but it does not affect network traffic to or from existing pods on that node; the compromised pod remains fully connected. Option C is wrong because deleting the pod destroys the running container and its ephemeral storage, losing volatile evidence (e.g., running processes, open file handles, memory dumps) that is critical for incident response. Option D is wrong because `kubectl exec` to kill a specific process assumes you know the exact process name and does not guarantee the mining process is stopped (it may respawn), and it does not isolate the pod from network egress, allowing continued communication with external mining infrastructure.

Full explanation →

700

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

This is correct because --encryption-provider-config points to an EncryptionConfiguration file that defines the 'aescbc' provider, which encrypts Secret data with AES in CBC mode before it is written to etcd. The kube-apiserver uses the first non-identity provider in the list to encrypt new secrets and tries all listed providers for decryption, enabling smooth key rotation without rewriting existing data. With this configuration, etcd stores only ciphertext, protecting secrets from anyone who gains direct access to the underlying etcd database.

Why this answer

The `--encryption-provider-config` flag on the kube-apiserver points to a YAML file containing an `EncryptionConfiguration` resource. Within that configuration, specifying the `aescbc` provider enables AES-CBC encryption for Secrets at rest, with the encryption key managed locally by the API server. This is the only option that satisfies the requirement for AES-CBC encryption with a locally managed key.

Exam trap

A common trap in Kubernetes exams is confusing the deprecated `--experimental-encryption-provider-config` flag with the current `--encryption-provider-config` flag. Also, remember that base64 encoding is not encryption; it only obfuscates data.

How to eliminate wrong answers

Option A is wrong because `--experimental-encryption-provider-config` is a deprecated flag (removed in Kubernetes 1.13+); the current stable flag is `--encryption-provider-config`. Option B is wrong because base64 encoding is not encryption—it is a reversible encoding that provides no confidentiality protection, and Secrets stored with base64 in etcd are still in plaintext. Option D is wrong because the `identity` provider stores data in plaintext (no encryption), which does not meet the requirement for encryption at rest.

Full explanation →

701

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

A NetworkPolicy that selects pods in 'secure-ns' and has an empty egress section (i.e., an empty `egress: []` list) with `policyTypes` including `Egress` enforces a default-deny on all outbound traffic from those pods. When a pod matches a NetworkPolicy that includes an Egress policy type but provides no egress rules, the Kubernetes network policy implementation denies every outbound connection not explicitly allowed, effectively restricting all egress. This is the standard pattern for blocking outbound traffic while leaving ingress behavior unchanged if ingress rules are absent and Ingress is not listed in policyTypes.

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 →

702

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 is a built-in Kubernetes admission controller that forwards pod creation requests to an external HTTPS endpoint for image policy evaluation. That webhook can verify signatures against a trusted key, rejecting unsigned images before they are admitted to the cluster.

Why this answer

The ImagePolicyWebhook admission controller allows a cluster to enforce a policy that only signed container images are deployed by intercepting image creation requests and validating them against an external webhook. This webhook can check image signatures (e.g., using Notary or Cosign) before admitting the pod, making it the correct choice for enforcing signed image policies.

Exam trap

The exam often tests the distinction between admission controllers that enforce image pull behavior (AlwaysPullImages) versus those that enforce image content validation (ImagePolicyWebhook), leading candidates to confuse pull policies with signature verification.

How to eliminate wrong answers

Option A is wrong because ServiceAccount admission controller manages service account tokens and automounting, not image validation or signature enforcement. Option B is wrong because AlwaysPullImages forces image pulls on every pod creation but does not verify image signatures or enforce signing policies. Option D is wrong because NodeRestriction limits node kubelet permissions to prevent privilege escalation, not image content or signature checks.

Full explanation →

703

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 the Istio resource specifically designed to enforce mutual TLS between workloads. It can be applied at the mesh, namespace, or workload level, and its mTLS mode field (STRICT, PERMISSIVE, or DISABLE) directly controls whether client certificates are required. When set to STRICT, the sidecar proxy rejects requests without valid mTLS, thereby enforcing encryption and mutual authentication. This makes it the correct choice for the administrator's goal of enforcing mTLS.

Why this answer

PeerAuthentication is the correct resource because it defines the TLS mode for traffic between services within the Istio mesh. By setting the mode to STRICT, mTLS is enforced, requiring all service-to-service communication to use mutual TLS. This is the Istio-native way to enable mTLS at the mesh or namespace level.

Exam trap

A common pitfall in CNCF exams is confusing PeerAuthentication (mTLS enforcement) with AuthorizationPolicy (access control after mTLS). PeerAuthentication sets the TLS mode for service-to-service communication, while AuthorizationPolicy governs which requests are allowed.

How to eliminate wrong answers

Option A is wrong because AuthorizationPolicy controls access to services based on roles and identities (RBAC), not the TLS mode of the connection; it works on top of mTLS but does not enforce it. Option B is wrong because ServiceEntry is used to add external services to the mesh, not to configure mTLS between internal services. Option C is wrong because VirtualService manages traffic routing rules (e.g., weight-based routing, retries), not the security or encryption of the connection.

Full explanation →

704

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 is the correct command because `kubectl label` sets the `pod-security.kubernetes.io/enforce` label on the namespace, which is exactly what the Pod Security Admission plug-in reads to decide the policy level and mode. Setting its value to `restricted` puts the namespace in enforce mode with the most stringent policy standard, so any pod that does not meet the restricted profile's security requirements will be rejected by the admission controller. Labels are the designated API mechanism for namespace-level PSA configuration, and this key is case-sensitive and must be spelled exactly as shown.

Why this answer

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 →

705

MCQhard

A CI pipeline fails with the error 'cosign: error: unable to verify image: no matching signatures' when running 'cosign verify --key pubkey.pem myregistry/myapp:latest'. The image was previously signed with a private key. What is the MOST likely cause?

A.The public key is incorrect

B.The registry requires authentication

C.Cosign is not installed correctly

D.The image tag was overwritten without signing

AnswerD

Cosign stores the signature for an image in a separate tag derived from the image digest (e.g., `sha256-<digest>.sig`) and does not use mutable tags like `latest` for signature lookup. When a CI pipeline overwrites a tag with a newly built image, the new image digest does not yet have a corresponding signature tag, so `cosign verify` finds no signatures for that digest. The old signature is still present but only applies to the previous digest, so verification fails with a "missing signature" error until the new image is explicitly signed after the push.

Why this answer

If the image tag was overwritten (e.g., pushed again without signing), the old signatures are lost and the new image is unsigned.

Full explanation →

706

MCQhard

A pod in namespace 'ns1' has automountServiceAccountToken: false. However, the container still has a mounted service account token at /var/run/secrets/kubernetes.io/serviceaccount. What is the most likely cause?

A.The automountServiceAccountToken field is set in the container spec instead of the pod spec

B.The kubelet is configured to always mount tokens

C.The namespace has a default automountServiceAccountToken: true

D.The pod is using a custom service account with automountServiceAccountToken: true

AnswerA

The `automountServiceAccountToken` field is a valid field only in the pod spec (via `PodSpec`); it is not part of the container spec. When placed under a container entry, Kubernetes ignores it or rejects it as an unknown field depending on the API server's validation strictness, so the pod-level field remains unset and defaults to `true`. Consequently, the kubelet mounts the service account token into all containers because the pod itself never disabled automounting.

Why this answer

The `automountServiceAccountToken` field is a pod-level setting. If it is set to `false` in the pod spec, the kubelet will not automatically mount the service account token. However, if the field is mistakenly set inside a container spec (which is not a valid field for containers), the pod-level setting is ignored, and the default behavior (mounting the token) applies.

This is why the token still appears mounted despite the intention to disable it.

Exam trap

The trap here is that candidates assume setting `automountServiceAccountToken: false` anywhere in the pod YAML will work, but they overlook that it must be at the pod spec level, not inside a container definition.

How to eliminate wrong answers

Option B is wrong because the kubelet does not have a global configuration to always mount tokens; the decision is controlled by the pod or namespace-level `automountServiceAccountToken` field. Option C is wrong because a namespace-level default only applies if the pod spec does not explicitly set `automountServiceAccountToken`; here the pod spec explicitly sets it to `false`, which overrides the namespace default. Option D is wrong because a custom service account's `automountServiceAccountToken` field only affects pods that use that service account; the pod's own `automountServiceAccountToken: false` in the pod spec takes precedence over the service account's setting.

Full explanation →

707

MCQeasy

You need to enforce that all containers in a namespace run with a read-only root filesystem. Which OPA Gatekeeper resource would you use to define the policy?

A.Constraint

B.ValidatingWebhookConfiguration

C.ConstraintTemplate

D.ConfigMap

AnswerC

A ConstraintTemplate is the correct place to define the policy logic itself. It is a CRD that produces a new Constraint CRD and contains a `spec.targets[].rego` field holding the OPA Rego rules that inspect admission requests, for example checking `spec.containers[].securityContext`. This is the only option among the choices that directly provides the rules (the 'what containers must run with' requirements) evaluated at admission time.

Why this answer

A ConstraintTemplate in OPA Gatekeeper defines the reusable policy logic (Rego rules) that enforces a specific constraint, such as requiring containers to run with a read-only root filesystem. The ConstraintTemplate is then instantiated by a Constraint resource to apply the policy to a namespace. Without the ConstraintTemplate, there is no policy definition to enforce.

Exam trap

The trap here is that candidates confuse the Constraint (which applies the policy) with the ConstraintTemplate (which defines the policy logic), leading them to select Option A instead of C.

How to eliminate wrong answers

Option A is wrong because a Constraint is an instance of a policy that references a ConstraintTemplate, but it does not define the policy logic itself; it only applies the template to specific resources. Option B is wrong because a ValidatingWebhookConfiguration is a Kubernetes resource that registers a webhook endpoint with the API server, but it is not an OPA Gatekeeper resource for defining policy; Gatekeeper uses its own webhook under the hood, but the policy definition is done via ConstraintTemplates. Option D is wrong because a ConfigMap is a generic Kubernetes resource for storing configuration data, not for defining OPA Gatekeeper policies; it lacks the Rego language and schema enforcement capabilities of a ConstraintTemplate.

Full explanation →

708

MCQmedium

Which command is used to sign a container image with Cosign and store the signature in an OCI registry?

A.cosign docker-sign myimage:latest

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

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

D.cosign attach signature --key cosign.key myimage:latest

AnswerC

Cosign's sign subcommand with --key uses the supplied private key to create a signature, then uploads it to the same OCI registry as the image, attaching it as a referrer artefact. This satisfies the requirement to store the signature in the registry itself.

Why this answer

`cosign sign --key cosign.key myimage:latest` is the standard Cosign command to sign a container image using a private key and store the resulting signature in the OCI registry as an attached artifact (e.g., a `.sig` layer). This command generates a signature that is automatically pushed to the same registry alongside the image, enabling verification without external storage.

Exam trap

CNCF-CKS often tests the distinction between signing (`cosign sign`) and verifying (`cosign verify`), and the trap here is that candidates may confuse the `attach` subcommand (used for non-signature artifacts) with the signing process, or assume a non-existent `docker-sign` subcommand is valid.

How to eliminate wrong answers

Option A is wrong because `cosign docker-sign` is not a valid Cosign subcommand; the correct command for signing is `cosign sign`. Option B is wrong because `cosign verify --key cosign.pub myimage:latest` is used to verify an existing signature, not to create one. Option D is wrong because `cosign attach signature` is not a real Cosign command; Cosign uses `cosign sign` to generate and attach the signature, and `cosign attach` is used for attaching other artifacts (like SBOMs), not signatures.

Full explanation →

709

MCQeasy

Which flag disables anonymous authentication on the Kubernetes API server?

A.--disable-anonymous-auth

B.--anonymous-auth=false

C.--anonymous-auth=true

D.--no-anonymous-auth

AnswerB

This is the correct way to turn off anonymous requests. Setting --anonymous-auth=false tells the apiserver to reject all requests that lack client credentials, returning HTTP 401 Unauthorized. This closes the 'system:anonymous' access path and is a fundamental hardening step for production clusters. Note that this flag alone does not protect service account tokens; it only disables unauthenticated access.

Why this answer

The `--anonymous-auth=false` flag explicitly disables anonymous authentication on the Kubernetes API server. By default, anonymous requests are allowed (equivalent to `--anonymous-auth=true`), so setting this flag to `false` prevents unauthenticated users from accessing the API server, which is a key hardening requirement for the CKS exam.

Exam trap

CNCF often tests the exact flag syntax, and the trap here is that candidates may misremember the flag as `--disable-anonymous-auth` or `--no-anonymous-auth` instead of the correct `--anonymous-auth=false` boolean pattern.

How to eliminate wrong answers

Option A is wrong because `--disable-anonymous-auth` is not a valid kube-apiserver flag; the correct flag uses a boolean value with `--anonymous-auth`. Option C is wrong because `--anonymous-auth=true` enables anonymous authentication, which is the default and does not disable it. Option D is wrong because `--no-anonymous-auth` is not a recognized flag; the Kubernetes API server uses `--anonymous-auth` with a boolean argument, not a negated prefix.

Full explanation →

710

MCQmedium

A security admin wants to ensure that only images signed with a specific key can run in the cluster. Which admission controller should be enabled?

A.PodSecurityPolicy

B.MutatingAdmissionWebhook

C.ImagePolicyWebhook

D.ValidatingAdmissionWebhook

AnswerC

ImagePolicyWebhook is the correct choice because it is a specialized admission controller that delegates image policy decisions to an external webhook service. The kubelet sends the image name, pull spec, and associated metadata to the configured webhook, which can then validate cryptographic signatures or enforce a deny-list/allow-list before the image is used. This design is the native Kubernetes mechanism for ensuring that only signed or pre-approved images enter the cluster, and it operates at the point of image resolution rather than at pod creation.

Why this answer

The ImagePolicyWebhook admission controller allows a cluster to enforce that only container images signed with a specific key can run. It intercepts pod creation requests and queries an external webhook to verify the image signature before admitting the pod. This directly meets the requirement of restricting execution to signed images.

Exam trap

The distinction between generic webhook controllers (MutatingAdmissionWebhook and ValidatingAdmissionWebhook) and the purpose-built ImagePolicyWebhook is a common point of confusion. Candidates often mistakenly choose a generic webhook when the question explicitly asks for the admission controller designed for image signature enforcement.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) enforces security context constraints (e.g., privilege escalation, host namespaces) but does not verify image signatures. Option B is wrong because MutatingAdmissionWebhook can modify objects (e.g., inject sidecars) but does not inherently validate image signatures; it could be used to call an external service, but the question asks for the admission controller that should be enabled, and ImagePolicyWebhook is the dedicated built-in controller for image signature verification. Option D is wrong because ValidatingAdmissionWebhook validates objects against custom logic but, like MutatingAdmissionWebhook, is a generic webhook mechanism; the specific built-in controller for image signature enforcement is ImagePolicyWebhook.

Full explanation →

711

MCQeasy

Which flag is used when starting kube-apiserver to enable audit logging?

A.--audit-log-path

B.--audit-webhook-config-file

C.--feature-gates=Audit=true

D.--audit-policy-file

AnswerD

This is the correct flag that actually enables audit logging. It specifies the path to a YAML file containing a list of rules that define, in order, which requests (based on user, verb, resource, and phase) should be logged and at which level (None, Metadata, Request, RequestResponse). Only when this flag is present does the kube-apiserver generate audit events; simultaneously configured backends like --audit-log-path or --audit-webhook-config-file become active and receive those events.

Why this answer

The --audit-policy-file flag specifies the path to the audit policy file, which is required to enable audit logging.

Full explanation →

712

MCQeasy

Which of the following is the recommended method to enable encryption at rest for secrets in etcd using the EncryptionConfiguration?

A.Use provider: aescbc

B.Use provider: encryption

C.Use provider: secretbox

D.Use provider: aesgcm

AnswerA

The aescbc provider is a valid and recommended encryption provider for Kubernetes Secrets at rest. It uses AES in CBC mode with PKCS#7 padding and includes an HMAC-SHA256 integrity check over the ciphertext, providing both confidentiality and integrity, and it is the standard provider for enabling encryption at rest in a cluster.

Why this answer

The recommended encryption provider for Kubernetes secrets at rest is `aescbc` (AES-CBC), as per the official documentation. While `secretbox` is a valid provider, it is less commonly used and not the default recommendation. Options 'encryption' and 'aesgcm' are invalid or deprecated.

Exam trap

Candidates might assume `secretbox` is also correct, but this question specifically asks for the recommended method, making only `aescbc` the correct answer.

How to eliminate wrong answers

Option B is wrong because `encryption` is not a valid provider name in the Kubernetes EncryptionConfiguration; valid providers include `aescbc`, `secretbox`, `aesgcm`, and `identity`. Option C is wrong because `secretbox` is a valid provider (using XSalsa20-Poly1305) but it is not the correct answer for this question, which asks for a correct method; however, the question implies selecting the one that is correct among the options, and `aescbc` is the most commonly recommended and correct one. Option D is wrong because `aesgcm` (AES-GCM) is a valid provider but requires careful nonce management and is not recommended for general use due to the risk of nonce reuse; it is not the correct answer here.

Full explanation →

713

MCQmedium

A security engineer needs to verify that a container image stored in a private OCI registry has not been tampered with before allowing it to run in a production cluster. The image was signed using Cosign with a key pair. The engineer has the public key. Which command should the engineer use to verify the signature?

A.cosign verify --key cosign.pub --registry-token $(cat token) registry.example.com/app:1.0

B.cosign verify --key cosign.pub --insecure registry.example.com/app:1.0

C.cosign verify-blob --key cosign.pub registry.example.com/app:1.0

D.cosign verify --key cosign.pub registry.example.com/app:1.0

AnswerD

This command uses Cosign to verify the signature of the specified image against the provided public key. It checks that the image was signed with the corresponding private key and that the signature is valid, ensuring integrity and authenticity. This is the correct approach for verifying a Cosign signature when the public key is available.

Why this answer

To verify a Cosign signature on a container image, the cosign verify command is used with the public key and the image reference. This checks the signature against the image digest. The other options either use the wrong subcommand, an invalid flag, or an unnecessary insecure flag that does not contribute to signature verification.

Exam trap

The trap here is confusing cosign verify with cosign verify-blob, which is meant for verifying signatures on arbitrary blobs rather than container images in a registry.

Full explanation →

714

MCQeasy

A developer wants to run a container that reads a secret from a mounted volume, not as an environment variable. Which volume type should they use?

A.secret

B.emptyDir

C.hostPath

D.configMap

AnswerA

A Secret volume is the native Kubernetes resource for exposing sensitive data, such as passwords or API tokens, to a container. It mounts the secret as files in the container's filesystem, backed by an in-memory tmpfs to avoid writing to disk, and respects RBAC permissions. This is exactly what the developer needs to securely read the secret.

Why this answer

The `secret` volume type in Kubernetes is specifically designed to inject sensitive data (e.g., passwords, tokens) into pods as files mounted from a tmpfs-backed in-memory filesystem, avoiding exposure as environment variables. This ensures the secret is never written to disk on the node and is only accessible via the container's filesystem at the specified mount path, aligning with the developer's requirement to read from a mounted volume.

Exam trap

The CKS exam often tests the misconception that `configMap` can be used for secrets because both can mount data as files, but the trap is that `configMap` lacks encryption and security features (e.g., no encryption at rest, no support for `encryptionConfiguration`), making it unsuitable for sensitive data in a CKS context.

How to eliminate wrong answers

Option B (emptyDir) is wrong because it creates an empty, ephemeral directory that is shared between containers in a pod but does not provide any mechanism to inject secret data; it is intended for scratch space or caching, not for reading pre-existing secrets. Option C (hostPath) is wrong because it mounts a file or directory from the host node's filesystem into the pod, which bypasses Kubernetes secret management and introduces security risks (e.g., node-level access, no encryption at rest), and it does not use the Kubernetes Secret API. Option D (configMap) is wrong because it is designed for non-sensitive configuration data (e.g., plaintext config files) and does not support encryption or the same security guarantees as secrets; using it for secrets would expose sensitive data in plaintext.

Full explanation →

715

Matchingmedium

Match each Kubernetes certificate type to its usage.

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

Concepts

Matches

Used by kubelet to serve the kubelet API (e.g., exec, logs)

Used by kubelet to authenticate to the API server

Used by the API server to serve HTTPS endpoints

Used to sign service account tokens so they can be verified

Used by an administrator to authenticate to the cluster with full privileges

Why these pairings

Two common certificate types in Kubernetes are the API server serving certificate (used for HTTPS encryption) and the kubelet client certificate (used for kubelet authentication to the API server). A common confusion is swapping their purposes: the API server serving certificate does not authenticate the API server to the kubelet, and the kubelet client certificate does not encrypt inter-node communication.

Full explanation →

716

MCQmedium

An administrator wants to enable RBAC authorization and disable anonymous authentication on the API server. Which set of flags should be added to the kube-apiserver configuration?

A.--enable-admission-plugins=NodeRestriction --anonymous-auth=false

B.--authorization-mode=AlwaysAllow --anonymous-auth=false

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

D.--authorization-mode=Node --anonymous-auth=true

AnswerC

Setting --authorization-mode=RBAC forces the API server to evaluate every request against Role, ClusterRole, RoleBinding, and ClusterRoleBinding rules before the requested operation is executed. Adding --anonymous-auth=false rejects requests that fail identity verification, closing the door to the system:anonymous user, which could otherwise be inadvertently bound to permissive roles. Together these flags enable the required authorization enforcement and align with the CIS Kubernetes Benchmark recommendation for the kube-apiserver.

Why this answer

To enable RBAC authorization on the API server, you must set `--authorization-mode=RBAC`. Disabling anonymous authentication is achieved with `--anonymous-auth=false`, which prevents unauthenticated requests from being processed. Together, these flags enforce role-based access control and block anonymous access, meeting the administrator's requirements.

Exam trap

The trap here is confusing admission controllers (like NodeRestriction) with authorization modes, or thinking that `--authorization-mode=Node` alone provides full RBAC, when it only handles node-specific authorization and must be combined with RBAC in a chain (e.g., `--authorization-mode=Node,RBAC`).

How to eliminate wrong answers

Option A is wrong because `--enable-admission-plugins=NodeRestriction` is an admission controller flag, not an authorization mode; it restricts node self-updates but does not enable RBAC or disable anonymous auth. Option B is wrong because `--authorization-mode=AlwaysAllow` permits all requests without any authorization checks, which directly contradicts the goal of enabling RBAC. Option D is wrong because `--authorization-mode=Node` only authorizes node-specific requests (e.g., kubelet API calls) and `--anonymous-auth=true` leaves anonymous authentication enabled, failing both requirements.

Full explanation →

717

Multi-Selecthard

Which THREE of the following are recommended practices for minimizing microservice vulnerabilities related to container security?

Select 3 answers

A.Set securityContext.runAsNonRoot: true

B.Drop all capabilities via securityContext.capabilities.drop: ["ALL"]

C.Set high CPU requests to ensure performance

D.Set securityContext.readOnlyRootFilesystem: true

E.Expose secrets as environment variables for convenience

AnswersA, B, D

Setting securityContext.runAsNonRoot: true forces Kubernetes to reject the container if the image runs as UID 0, ensuring the process executes with a non-root user ID. This prevents an attacker from obtaining root privileges inside the container after exploiting a vulnerability, which massively reduces the ability to modify system files, install tooling, or leverage kernel-level privilege escalation. It also helps satisfy Pod Security Standards restricted profile requirements.

Why this answer

Setting `securityContext.runAsNonRoot: true` forces the container to run with a user ID (UID) other than 0 (root). This is a critical defense-in-depth measure because if an attacker exploits a vulnerability in the application or runtime, they will not gain root privileges on the host, limiting the blast radius. It enforces the principle of least privilege at the container level, and Kubernetes will reject the pod if the container image attempts to run as root.

Exam trap

Kubernetes CKS exams often test the misconception that resource limits (CPU/memory) are security controls, but they are only for resource isolation and DoS prevention, not for mitigating container escape or privilege escalation vulnerabilities.

Full explanation →

718

MCQhard

A pod is failing with status 'CrashLoopBackOff'. The pod manifest includes a liveness probe that runs every 10 seconds. You suspect the probe is causing the crash. Which command would you use to verify the liveness probe configuration?

A.kubectl logs <pod>

B.kubectl exec <pod> -- cat /etc/kubernetes/manifests/pod.yaml

C.kubectl describe pod <pod>

D.kubectl get pod <pod> -o yaml

AnswerC

kubectl describe pod <pode> is the correct troubleshooting command because it consolidates the pod's live configuration, status, and recent events in a human-readable format. Under the Containers section, it explicitly shows the livenessProbe block, including exec command, initialDelaySeconds, periodSeconds, timeoutSeconds, and failureThreshold, along with the container's current state and restart count. It also surfaces events such as 'Unhealthy' or 'Killing' with timestamps, making it easy to see whether the probe is causing the CrashLoopBackOff and what specific probe parameters are misconfigured.

Why this answer

`kubectl describe pod <pod>` displays the pod's full configuration, including the liveness probe's exact parameters (e.g., initialDelaySeconds, periodSeconds, failureThreshold, and the probe action like HTTP GET, TCP socket, or exec command). This allows you to verify if the probe is misconfigured (e.g., too aggressive or pointing to a non-existent endpoint) and causing the CrashLoopBackOff.

Exam trap

CNCF often tests the distinction between `kubectl describe` (human-readable, includes probe status and events) and `kubectl get -o yaml` (full API object, more verbose but less immediate for troubleshooting), leading candidates to pick the latter when the former is more efficient for verifying probe configuration.

How to eliminate wrong answers

Option A is wrong because `kubectl logs <pod>` shows the container's stdout/stderr output, which may reveal crash reasons but does not show the liveness probe configuration. Option B is wrong because `kubectl exec <pod> -- cat /etc/kubernetes/manifests/pod.yaml` attempts to read a static pod manifest from inside the container, which typically does not exist (static manifests are on the node's filesystem, not inside the container), and even if it did, it would not reflect the live probe configuration from the API. Option D is wrong because `kubectl get pod <pod> -o yaml` outputs the pod's full YAML manifest from the API server, which includes the liveness probe, but `kubectl describe pod` is more concise and human-readable for quickly verifying probe details like periodSeconds and failureThreshold.

Full explanation →

719

MCQeasy

Which of the following is a best practice for securing a Dockerfile?

A.Hardcode API keys as environment variables

B.Use a minimal base image like alpine

C.Run the container as root to avoid permission issues

D.Use the latest tag for all images

AnswerB

Alpine's musl libc and BusyBox base provide a far smaller package set than Debian or Ubuntu images, removing compilers, shells and unused daemons. Fewer installed packages mean fewer exploitable CVEs, satisfying the stem's Dockerfile hardening requirement.

Why this answer

Using a minimal base image like Alpine reduces the attack surface by including only essential packages and libraries, minimizing the number of potential vulnerabilities. This aligns with the principle of least functionality and is a key supply chain security practice for container images.

Exam trap

CKS often tests the misconception that running as root is simpler or more reliable, but the CKS emphasizes that containers should never run as root unless absolutely necessary, and even then, capabilities should be dropped.

How to eliminate wrong answers

Option A is wrong because hardcoding API keys as environment variables in a Dockerfile exposes secrets in plaintext within the image layers, making them accessible to anyone with image access; secrets should be injected at runtime via Kubernetes Secrets or a secrets manager. Option C is wrong because running the container as root violates the principle of least privilege, increasing the risk of host compromise if the container is breached; containers should run with a non-root user (e.g., via USER directive). Option D is wrong because using the 'latest' tag introduces unpredictability and potential supply chain risks, as it can silently pull a different, possibly vulnerable, version of the image; pinned digests or version tags should be used for reproducibility and security.

Full explanation →

720

MCQmedium

A security audit reveals that a service account 'monitor' is bound to the cluster-admin ClusterRole, which violates least-privilege. What is the best remediation?

A.Delete the service account and recreate it without any role binding

B.Keep the binding but add a Deny policy for write actions

C.Set automountServiceAccountToken: false in the pod spec

D.Create a new ClusterRoleBinding that binds 'monitor' to a less privileged role (e.g., view) and delete the cluster-admin binding

AnswerD

This is the correct least-privilege remediation because it revokes the unnecessary cluster-admin permissions while preserving the monitoring workload's functional read-only access. Binding 'monitor' to the built-in 'view' ClusterRole gives the service account the ability to inspect most resources, which is the typical need for monitoring, and deleting the old cluster-admin binding ensures the elevated privileges are actually removed. Verifying that no other RoleBinding or ClusterRoleBinding grants cluster-admin to this service account is a prudent follow-up step to confirm the attack surface is eliminated.

Why this answer

It directly addresses the violation of least-privilege by replacing the overly permissive cluster-admin ClusterRoleBinding with a binding to a more restrictive role like 'view'. This ensures the 'monitor' service account retains only the necessary read permissions, adhering to the principle of least privilege without disrupting its functionality.

Exam trap

The trap here is that candidates may think setting automountServiceAccountToken to false (Option C) is sufficient to revoke permissions, but it only prevents token mounting in pods, not the underlying RBAC permissions that remain active for the service account.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the service account without any role binding would remove all permissions, potentially breaking the monitoring functionality that requires some level of access. Option B is wrong because Kubernetes does not support a native 'Deny policy' for write actions on a ClusterRoleBinding; access control is managed via RBAC roles, not deny policies, and keeping the binding still violates least-privilege. Option C is wrong because setting automountServiceAccountToken: false in the pod spec only prevents automatic mounting of the service account token, but does not revoke the excessive permissions granted by the cluster-admin binding; the service account still has full cluster access if used elsewhere.

Full explanation →

721

MCQeasy

Which of the following is a valid way to drop all capabilities from a container?

A.securityContext: dropCapabilities: true

B.securityContext: privileged: false

C.securityContext: capabilities: remove: ["ALL"]

D.securityContext: capabilities: drop: ["ALL"]

AnswerD

Placing capabilities.drop: ["ALL"] inside the container's securityContext instructs the container runtime to remove every Linux capability from the process. This is the documented Kubernetes mechanism for dropping all capabilities, applied per container rather than cluster-wide.

Why this answer

In Kubernetes, the `securityContext.capabilities.drop` field is used to explicitly remove Linux capabilities from a container. Dropping `ALL` removes every capability, ensuring the container runs with the least privilege possible, which is a key security best practice for minimizing microservice vulnerabilities.

Exam trap

The CKS exam often tests the exact YAML syntax for capability management, and the trap here is that candidates confuse `drop` with `remove` or invent non-existent fields like `dropCapabilities`, leading them to pick incorrect options that look plausible but are syntactically invalid.

How to eliminate wrong answers

Option A is wrong because `dropCapabilities` is not a valid field in the Kubernetes securityContext; the correct field is `capabilities.drop`. Option B is wrong because setting `privileged: false` does not drop all capabilities; it simply prevents the container from running with elevated privileges, but default capabilities (as defined by the container runtime) remain. Option C is wrong because `remove` is not a valid key under `capabilities`; the correct key is `drop`.

Full explanation →

722

MCQeasy

An administrator wants to monitor runtime security events in Kubernetes using Falco. Which component must be deployed as a DaemonSet to capture system calls from containers?

A.Falco driver

B.Kube-bench

C.Falcoctl

D.Falco

AnswerD

Falco is the CNCF-graduated runtime security tool that runs as a DaemonSet on every node, with each replica using a kernel driver (eBPF or kernel module) to capture syscalls. It continuously evaluates those syscalls against a comprehensive ruleset—detecting behaviors like shell access, privilege escalation, or suspicious file reads—and produces real-time security alerts. This combination of kernel instrumentation and rule evaluation is exactly what is required to monitor runtime security events in a Kubernetes cluster.

Why this answer

Falco is the core userspace component that processes system calls and enforces runtime security rules. It must be deployed as a DaemonSet on each Kubernetes node to capture system calls from all containers running on that node, as it relies on a kernel module or eBPF probe to intercept syscalls at the host level.

Exam trap

Candidates often confuse the Falco driver (kernel module) with the Falco userspace daemon. The driver captures syscalls, but the daemon processes them and must run on each node via a DaemonSet to monitor all containers.

How to eliminate wrong answers

Option A is wrong because the Falco driver (e.g., kernel module or eBPF probe) is a kernel-level component that is loaded into the kernel, not deployed as a DaemonSet; it is typically installed via a container init or as part of the Falco pod's setup. Option B is wrong because Kube-bench is a tool for checking Kubernetes clusters against CIS benchmarks, not for runtime security monitoring or capturing system calls. Option C is wrong because Falcoctl is a command-line utility for managing Falco configurations and rules, not a component that captures syscalls or runs as a DaemonSet.

Full explanation →

723

MCQmedium

A developer wants to ensure that all containers in a pod run with a read-only root filesystem except for a specific volume mounted for writing logs. Which container-level security context field should be set to true?

A.allowPrivilegeEscalation

B.readOnlyRootFilesystem

C.privileged

D.runAsNonRoot

AnswerB

readOnlyRootFilesystem mounts the container's root filesystem as read-only, blocking writes outside explicitly mounted volumes. Setting it true satisfies the stem's constraint: the pod stays immutable while the designated log volume remains writable, since volume mounts override the read-only root.

Why this answer

Setting `readOnlyRootFilesystem: true` in the container-level security context forces the container's root filesystem to be read-only, preventing any writes to the root filesystem. This is exactly what the developer needs to enforce immutability for the root filesystem while allowing writes only to a specific volume (e.g., for logs) mounted with write access. The field is a boolean in the `securityContext` of a container specification in Kubernetes.

Exam trap

The trap here is that candidates confuse `readOnlyRootFilesystem` with `runAsNonRoot` or `allowPrivilegeEscalation`, mistakenly thinking those options also restrict filesystem writes, when in fact they address entirely different security concerns (user identity and privilege escalation).

How to eliminate wrong answers

Option A is wrong because `allowPrivilegeEscalation` controls whether a process can gain more privileges than its parent (e.g., via setuid binaries), not whether the root filesystem is read-only. Option C is wrong because `privileged` runs the container with elevated host capabilities and disables most security restrictions, which is the opposite of enforcing a read-only root filesystem. Option D is wrong because `runAsNonRoot` ensures the container does not run as the root user but does not affect the writability of the root filesystem.

Full explanation →

724

Multi-Selecthard

Which THREE of the following are best practices for RBAC hardening in Kubernetes? (Select THREE)

Select 3 answers

A.Avoid using the cluster-admin ClusterRole for service accounts

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

C.Apply the principle of least privilege when creating Roles and ClusterRoles

D.Use the default namespace for all service accounts

E.Regularly audit ClusterRoleBindings for excessive permissions

AnswersA, C, E

Avoid binding service accounts to cluster-admin: that ClusterRole grants wildcard permissions on every resource and subresource across all API groups, including RBAC itself. A service account holding it lets a compromised workload install mutating webhooks, exfiltrate secrets, or delete nodes without any additional authorization. Always bind service accounts to the most narrowly scoped Role or ClusterRole that only permits their required verbs and resources.

Why this answer

The cluster-admin ClusterRole grants unrestricted access to all Kubernetes resources across all namespaces, which violates the principle of least privilege. Service accounts should be assigned only the specific permissions required for their function, not full administrative access. Using cluster-admin for service accounts increases the blast radius of a potential compromise and is a common misconfiguration that the CKS exam penalizes.

Exam trap

CNCF often tests the misconception that 'simplicity' (Option B) or 'using the default namespace' (Option D) are acceptable shortcuts, when in fact the CKS exam strictly enforces least privilege and namespace isolation as core hardening principles.

Full explanation →

725

Multi-Selectmedium

Which TWO of the following are valid methods to detect a container spawning a shell (e.g., /bin/bash) using Falco? (Select two.)

Select 2 answers

A.Use the rule 'Launch Sensitive Mount'

B.Check if proc.name is 'bash' and container is true

C.Use the macro 'spawned_process' combined with a container filter

D.Check if the process's parent is 'sshd'

E.Check if evt.type is 'execve' and fd.name contains 'bash'

AnswersB, C

Falco rules match process attributes from the kernel; checking proc.name equals bash while container is true detects an interactive shell spawned inside a container. This distinguishes container shell execution from host-level bash processes, which is the behaviour being hunted.

Why this answer

Option B is correct because Falco rules can directly match the process name field proc.name against 'bash' (or other shell binaries) while also requiring container=true, which scopes the detection to containerized workloads and reliably flags a shell being launched inside a container. Option C is correct because Falco ships a 'spawned_process' macro that encapsulates the execve/execveat event conditions for process creation, and combining it with a container filter (e.g., container.id != host or container=true) is the idiomatic way to detect any process, including a shell, spawned inside a container. Option A is not a shell-spawning detection method; 'Launch Sensitive Mount' targets mount-related activity such as sensitive host paths being mounted, not process execution.

Option D is wrong because checking for a parent of 'sshd' detects remote login sessions, not a container spawning a shell, and misses container-internal shell launches. Option E is incorrect because fd.name refers to file descriptor names (files, sockets), not the executable being run, so it would not properly identify a shell being executed via execve.

Exam trap

Falco often tests the distinction between process name fields (proc.name) and file descriptor fields (fd.name), leading candidates to incorrectly select option E, which uses fd.name instead of proc.name for process detection.

Full explanation →

726

MCQhard

A pod is using a RuntimeClass that specifies gVisor (runsc). Which of the following scenarios is most likely to cause the pod to fail?

A.The pod runs a web server listening on port 8080.

B.The pod attempts to mount a hostPath directory with privileged access.

C.The pod mounts a ConfigMap as a volume.

D.The pod uses a PersistentVolumeClaim for storage.

AnswerB

This is the only option that would realistically fail because gVisor's design goal is to prevent pods from accessing host resources directly. A hostPath volume bypasses the VFS layer and requests a raw directory from the host, and while gVisor can theoretically mount hostPath volumes if explicitly configured, combining it with privileged: true is contradictory — gVisor explicitly rejects giving the app direct host access. Even a privileged container inside runsc runs with gVisor's restricted kernel, so the mount attempt either fails at volume setup or the app cannot perform privileged operations on the host path, causing the pod to misbehave or not start.

Why this answer

GVisor (runsc) operates as a sandboxed kernel that intercepts system calls, and it does not support privileged operations such as mounting hostPath directories with privileged access. The `privileged: true` flag attempts to bypass the sandbox, which gVisor explicitly denies, causing the pod to fail. This is a core security constraint of gVisor, which aims to minimize microservice vulnerabilities by restricting host-level interactions.

Exam trap

The CKS exam often tests the misconception that gVisor is a lightweight container runtime that allows all standard operations, but the trap here is that `privileged: true` and hostPath mounts are fundamentally incompatible with gVisor's sandboxing model, leading to pod failure.

How to eliminate wrong answers

Option A is wrong because gVisor supports standard networking operations, including listening on port 8080, as it implements a user-space network stack that handles TCP/IP connections without requiring host kernel access. Option C is wrong because ConfigMap mounts are handled via tmpfs or volume mounts within the sandbox, and gVisor fully supports these operations through its virtual filesystem layer. Option D is wrong because PersistentVolumeClaims are supported by gVisor as long as the underlying storage driver (e.g., CSI) does not require privileged syscalls; gVisor can handle block or filesystem mounts through its seccomp-filtered syscall interface.

Full explanation →

727

MCQeasy

You are a Kubernetes administrator for a fintech company that runs a payment processing service in a production cluster. The service consists of multiple microservices that communicate over the network. Recently, a security audit revealed that a compromised pod could potentially send malicious requests to other services because there are no network restrictions between pods. The security team has mandated that all inter-service traffic must be encrypted and authenticated, and that only necessary traffic should be allowed. You need to implement a solution that meets these requirements with minimal changes to the application code and minimal operational overhead. Which approach should you take?

A.Encrypt traffic by configuring TLS certificates in each pod's environment variables and updating the application code to use HTTPS.

B.Use Kubernetes NetworkPolicies to restrict pod-to-pod communication based on labels and namespaces, and enable TLS in each service's code.

C.Deploy Istio as a service mesh with mutual TLS enabled and configure AuthorizationPolicy resources to allow only required traffic between services.

D.Move all services to a separate overlay network using Weave Net and enforce egress rules with iptables on each node.

AnswerC

Istio injects a sidecar Envoy proxy into each pod, transparently redirecting all service traffic to enforce mutual TLS using per-pod SPIFFE identities, with no changes to application code. Combined with AuthorizationPolicy resources, it allows only explicitly permitted traffic between authenticated services, providing both encryption and fine-grained, identity-aware authorization in one consistent layer.

Why this answer

Deploying Istio as a service mesh with mutual TLS (mTLS) provides transparent encryption and authentication of all inter-service traffic without modifying application code. Istio's AuthorizationPolicy resources allow fine-grained, label-based access control to enforce the principle of least privilege, meeting the security mandate with minimal operational overhead through sidecar proxy injection.

Exam trap

The trap here is that candidates may think NetworkPolicies alone satisfy the encryption requirement, but NetworkPolicies only filter traffic at L3/L4 and do not provide any encryption or authentication, which is explicitly required by the security audit.

How to eliminate wrong answers

Option A is wrong because configuring TLS certificates via environment variables and updating application code to use HTTPS requires significant code changes and does not address network-level restrictions; it also lacks centralized policy enforcement. Option B is wrong because while NetworkPolicies restrict traffic at the network layer, they do not provide encryption or authentication; enabling TLS in each service's code still requires application modifications and does not offer mutual authentication by default. Option D is wrong because moving services to a separate overlay network with Weave Net and enforcing egress rules via iptables adds complexity, does not encrypt traffic, and requires manual per-node configuration, failing to meet the minimal operational overhead requirement.

Full explanation →

728

MCQeasy

An administrator wants to prevent pods from running as root. Which SecurityContext field should be set at the pod level?

A.fsGroup: 2000

B.runAsGroup: 3000

C.runAsUser: 1000

D.runAsNonRoot: true

AnswerD

When set to true, this securityContext field enforces at admission and runtime that the container's UID is non-zero. If the image's configured user or an explicit runAsUser is 0, Kubernetes will refuse to start the pod, producing a CreateContainerConfigError or validation failure. This directly meets the requirement to prevent pods from running as root, making it the correct choice.

Why this answer

Setting `runAsNonRoot: true` at the pod-level SecurityContext enforces that all containers in the pod must run with a non-root user (UID > 0). If a container image specifies a user with UID 0 (root) or does not specify a user, the container will fail to start, preventing privilege escalation from root access.

Exam trap

CNCF often tests the distinction between setting a specific user ID (runAsUser) and enforcing a non-root requirement (runAsNonRoot), where candidates mistakenly think that setting runAsUser to a non-zero value alone prevents root execution, but it does not block an image that runs as root by default if runAsUser is omitted or set to 0.

How to eliminate wrong answers

Option A is wrong because `fsGroup: 2000` sets the group ID for volume ownership, not the user identity, and does not prevent running as root. Option B is wrong because `runAsGroup: 3000` sets the primary group ID for the container process but does not restrict the user to a non-root UID. Option C is wrong because `runAsUser: 1000` sets a specific user ID (1000) for the container process, but it does not enforce that the container cannot run as root; if the image runs as root by default, this field overrides it, but the pod could still be configured with a root UID, and the field itself does not block root execution.

Full explanation →

729

MCQmedium

Which admission plugin should be enabled to prevent kubelets from modifying Node objects they should not have access to?

A.NamespaceLifecycle

B.NodeRestriction

C.PodSecurity

D.ServiceAccount

AnswerB

NodeRestriction is the admission plugin specifically designed to constrain kubelet permissions. It enforces that a kubelet identified by its credentials (e.g., user system:kubelet:<nodeName>) can only update its own node object, and even then, it can only modify allowed fields such as status, pods, and specific annotations, while blocking changes to labels, taints, or other critical scheduling fields. This plugin directly prevents a kubelet from tampering with node objects to influence scheduling or evade security controls. Enabling NodeRestriction is a mandatory hardening step and works alongside RBAC to provide defense-in-depth for kubelet access.

Why this answer

The NodeRestriction admission plugin limits the kubelet's ability to modify Node and Pod objects to only those it is authorized to manage based on its credentials. It ensures a kubelet can only label, taint, or update status on its own Node object and cannot modify other Nodes, preventing privilege escalation or misconfiguration.

Exam trap

CNCF often tests the distinction between admission plugins that control Pod security (PodSecurity) versus those that control Node-level access (NodeRestriction), leading candidates to confuse PodSecurity with Node-level restrictions.

How to eliminate wrong answers

Option A is wrong because NamespaceLifecycle ensures namespaces exist and prevents deletion of system namespaces, but it does not restrict kubelet actions on Node objects. Option C is wrong because PodSecurity enforces Pod Security Standards (e.g., privileged, baseline, restricted) on Pods, not Node-level modifications. Option D is wrong because ServiceAccount manages automatic creation and mounting of service account tokens, but it has no role in controlling kubelet access to Node objects.

Full explanation →

730

Multi-Selectmedium

Which TWO are recommended practices for securing a CI/CD pipeline that builds container images? (Select two.)

Select 2 answers

A.Run containers as root for compatibility

B.Scan images for vulnerabilities before pushing

C.Store secrets in the image as environment variables

D.Sign images after building

E.Use the 'latest' tag for simplicity

AnswersB, D

Scanning images for vulnerabilities before pushing catches known CVEs in dependencies and base layers while the artefact is still inside the pipeline, preventing flawed images from reaching the registry. This satisfies the requirement to gate builds on security findings before publication.

Why this answer

Option B is correct because scanning images for vulnerabilities before pushing them to a registry catches known CVEs in OS packages and application dependencies early, preventing flawed artifacts from ever entering the pipeline's downstream stages or production. Option D is correct because signing images after building (e.g., with Docker Content Trust/Notary or Sigstore cosign) provides cryptographic provenance and integrity, letting admission controllers verify that only trusted, unmodified images are deployed. Option A is wrong because running containers as root violates least-privilege and dramatically increases the impact of a container escape; images should use a non-root USER.

Option C is wrong because baking secrets into image layers as environment variables exposes them to anyone who can pull or inspect the image; secrets belong in a vault or secret manager injected at runtime. Option E is wrong because the mutable 'latest' tag makes builds non-reproducible and can silently pull a different, potentially compromised image; immutable, versioned tags or digests should be used.

Exam trap

The CKS exam often tests the distinction between build-time security (scanning, signing) and runtime security (least privilege, secret injection), and the trap here is that candidates may think storing secrets as environment variables is acceptable because it works, ignoring that they persist in image layers and are accessible via `docker history`.

Full explanation →

731

MCQeasy

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

A.Store secrets directly in the Dockerfile for convenience

B.Run containers as root to have full access to system resources

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

D.Use minimal base images such as distroless or Alpine to reduce attack surface

AnswerD

Minimal images like distroless or Alpine strip out package managers, shells, and extraneous system utilities, removing the tools an attacker would need to pivot, write files, or download additional binaries after breaking into a process. Distroless images provide a root filesystem with only the application and its runtime libraries, offering no interactive shell; Alpine achieves small size and a lower CVE count through BusyBox and musl libc. For maximum benefit, pair minimal images with non-root execution, read-only root filesystems, and regular scanning, since even minimal images still require patching for vulnerabilities in their included libraries.

Why this answer

Minimal base images like distroless or Alpine contain only the application and its runtime dependencies, drastically reducing the number of packages, libraries, and utilities that could contain vulnerabilities or be exploited post-compromise. Fewer components mean a smaller attack surface, faster pulls, and easier vulnerability management. This is a foundational CKS best practice for supply chain and runtime security.

Exam trap

CKS often tests the misconception that convenience (secrets in Dockerfile, root, latest tag) is acceptable; the exam expects minimal base images and least-privilege principles.

How to eliminate wrong answers

Option A is wrong because storing secrets in a Dockerfile embeds them in image layers, where they persist in the image history and can be extracted by anyone with pull access; secrets should be injected at runtime via Kubernetes Secrets or external vaults. Option B is wrong because running as root violates least privilege and allows container escape exploits to gain host-level access; CKS recommends non-root users and read-only root filesystems. Option C is wrong because the 'latest' tag is mutable and non-deterministic, breaking reproducibility and potentially pulling a vulnerable or incompatible version; images should be pinned by digest or immutable tag.

Full explanation →

732

MCQmedium

Which kubelet flag prevents the kubelet from serving anonymous requests?

A.--authentication-anonymous=false

B.--anonymous-auth=false

C.--enable-anonymous=false

D.--anonymous-requests=false

AnswerB

--anonymous-auth=false is the correct kubelet flag. It disables anonymous authentication to the kubelet's HTTPS endpoints on port 10250. When set to false, requests that do not have valid client certificates, bearer tokens, or other accepted credentials are rejected before any authorization checks occur, preventing unauthenticated access to kubelet APIs such as /pods, /exec, and /logs.

Why this answer

The kubelet flag `--anonymous-auth=false` disables anonymous authentication, preventing unauthenticated requests from being served. By default, anonymous requests are enabled (`--anonymous-auth=true`), which allows any user without credentials to access the kubelet API. Setting this flag to `false` enforces authentication for all requests, a critical hardening step for cluster security.

Exam trap

CNCF often tests the exact flag name `--anonymous-auth` versus similar-sounding alternatives like `--authentication-anonymous` or `--enable-anonymous`, exploiting candidates' tendency to guess based on generic naming patterns rather than precise Kubernetes documentation.

How to eliminate wrong answers

Option A is wrong because `--authentication-anonymous=false` is not a valid kubelet flag; the correct flag uses `anonymous-auth`, not `authentication-anonymous`. Option C is wrong because `--enable-anonymous=false` does not exist; the kubelet uses `--anonymous-auth` to control anonymous access. Option D is wrong because `--anonymous-requests=false` is not a recognized kubelet flag; the correct parameter is `--anonymous-auth`.

Full explanation →

733

MCQeasy

Which of the following is a valid approach to enforce that containers cannot escalate privileges?

A.Set securityContext.readOnlyRootFilesystem: true

B.Set securityContext.privileged: false

C.Set securityContext.capabilities.drop: ["ALL"]

D.Set securityContext.allowPrivilegeEscalation: false

AnswerD

Setting allowPrivilegeEscalation: false instructs the runtime to set the no_new_privs attribute on the container process, which prevents any child process from gaining more privileges than the parent, including via setuid binaries or file capabilities. This is the direct and supported method to enforce that containers cannot escalate privileges, and it works at the kernel level. It is also required by many security policies and is a key control in pod security standards.

Why this answer

Setting `securityContext.allowPrivilegeEscalation: false` directly prevents a container from gaining more privileges than its parent process, such as through setuid binaries or `NO_NEW_PRIVS` flag. This is a key control to block privilege escalation attacks even if the container runs with some capabilities. It is enforced at the kernel level via the `no_new_privs` attribute, which disables privilege-gaining operations like `setuid` and `setgid`.

Exam trap

CNCF often tests the misconception that dropping all capabilities or setting `privileged: false` is sufficient to prevent privilege escalation, but the key is that `allowPrivilegeEscalation: false` is required to block setuid-based escalation, which is a separate kernel mechanism from capabilities.

How to eliminate wrong answers

Option A is wrong because `readOnlyRootFilesystem: true` only makes the container's root filesystem read-only, which protects against file tampering but does not prevent privilege escalation. Option B is wrong because `privileged: false` is the default and does not actively block privilege escalation; it only disables the privileged mode, but a container can still escalate via setuid binaries or added capabilities. Option C is wrong because dropping all capabilities with `capabilities.drop: ["ALL"]` removes kernel capabilities but does not disable the `no_new_privs` mechanism; a container can still escalate privileges through setuid binaries unless `allowPrivilegeEscalation` is explicitly set to false.

Full explanation →

734

MCQmedium

A cluster administrator wants to enforce that all pods in the 'restricted' namespace use the Restricted Pod Security Standard. Which command achieves this?

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

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

C.kubectl create podsecuritypolicy restricted --namespace restricted

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

AnswerD

This is the correct command because it labels the namespace with the enforce label that Pod Security Admission reads, and sets it to the 'restricted' Pod Security Standard. As a result, any pod created in that namespace that does not satisfy the restricted profile—such as those without seccomp profiles or with added capabilities—is rejected at admission time. The label format is exactly pod-security.kubernetes.io/enforce=restricted.

Why this answer

The `kubectl label` command with the key `pod-security.kubernetes.io/enforce` and value `restricted` applies the Restricted Pod Security Standard to the namespace. This label instructs the Pod Security Admission controller to enforce the most restrictive policy, rejecting any pod that violates the standard. The command targets the namespace 'restricted' as required.

Exam trap

The trap here is that candidates confuse the deprecated PodSecurityPolicy (PSP) with the newer Pod Security Standards (PSS) and try to use `kubectl create podsecuritypolicy` or incorrect annotation syntax, when the correct approach is to label the namespace with the `pod-security.kubernetes.io/enforce` key.

How to eliminate wrong answers

Option A is wrong because `kubectl annotate` does not trigger Pod Security Standards; it uses annotations, not labels, and the syntax `pod-security.kubernetes.io/restricted=restricted` is invalid (the correct label key is `pod-security.kubernetes.io/enforce`). Option B is wrong because it sets the value to `privileged`, which enforces the least restrictive standard, not the Restricted standard. Option C is wrong because `PodSecurityPolicy` (PSP) is deprecated and removed in Kubernetes 1.25+; the question refers to Pod Security Standards (PSS) which are configured via labels on namespaces, not via PSP objects.

Full explanation →

735

MCQeasy

Which admission plugin is recommended by the CIS Benchmark to restrict what nodes can modify?

A.PodSecurity

B.AlwaysPullImages

C.ServiceAccount

D.NodeRestriction

AnswerD

NodeRestriction limits each kubelet to modifying only its own Node object and Pods bound to it, preventing a compromised node from altering other nodes' resources. The CIS Benchmark recommends enabling this admission plugin specifically to constrain node-level write permissions.

Why this answer

The NodeRestriction admission plugin is recommended by the CIS Benchmark for Kubernetes to restrict what nodes can modify. It limits the Node and Pod objects a kubelet can modify, ensuring that a node can only modify its own Node object and Pods bound to it. This prevents a compromised node from affecting other nodes or pods in the cluster.

Exam trap

CNCF often tests the distinction between admission plugins that enforce security at the pod level (like PodSecurity) versus those that restrict node-level actions (like NodeRestriction), causing candidates to confuse the scope of each plugin.

How to eliminate wrong answers

Option A is wrong because PodSecurity is a deprecated admission plugin (replaced by Pod Security Admission) that enforces pod security standards, not node modification restrictions. Option B is wrong because AlwaysPullImages forces image pull policy to Always, ensuring images are always pulled from the registry, but does not restrict node-level modifications. Option C is wrong because ServiceAccount is an admission plugin that manages service account automounting and token projection, not node modification controls.

Full explanation →

736

MCQeasy

Which command can be used to view the logs of a container using the container runtime interface (crictl)?

A.crictl status <container-id>

B.crictl logs <container-id>

C.crictl inspect <container-id>

D.crictl log <container-id>

AnswerB

crictl logs <container-id> correctly invokes the CRI's ContainerLogs method, which fetches the log stream generated by the container's primary process. It supports common flags like --follow, --tail, and --timestamps, making it the direct equivalent to 'docker logs' for node-level troubleshooting when you have a container ID rather than a pod.

Why this answer

crictl logs is the command to fetch logs of a container, similar to 'docker logs'.

Full explanation →

737

MCQmedium

During a security audit, it was found that some pods have access to the host network. How can an administrator restrict host network access for all pods in the cluster?

A.Set --allow-privileged=false in kubelet configuration

B.Enable PodSecurity admission controller with baseline or restricted profile

C.Enable PodSecurityPolicy with 'hostNetwork: false'

D.Create NetworkPolicies that deny traffic to host network

AnswerB

Pod Security Admission (PSA) is the built-in admission controller that enforces the Pod Security Standards, and both the `baseline` and `restricted` policies require `hostNetwork` to be set to `false` (with `restricted` also forbidding other host namespaces). By applying a PSA level of `baseline` or `restricted` at the cluster, namespace, or label-based level, the API server will reject any new pod that tries to use host networking. This is the recommended, current replacement for the removed PodSecurityPolicy, and it directly blocks the offending capability. Note that PSA only applies to newly created pods, so existing pods must be recreated or patched to bring them into compliance.

Why this answer

The PodSecurity admission controller (GA in Kubernetes v1.25+) enforces predefined security standards (baseline or restricted) that, among other restrictions, prevent pods from using `hostNetwork: true`. This is the recommended replacement for the deprecated PodSecurityPolicy and provides a built-in, cluster-wide mechanism to restrict host network access without requiring external tools.

Exam trap

CNCF often tests the deprecation of PodSecurityPolicy (PSP) and expects candidates to know that the PodSecurity admission controller is the current and correct replacement, not the legacy PSP or network-level controls like NetworkPolicies.

How to eliminate wrong answers

Option A is wrong because `--allow-privileged=false` in kubelet configuration only prevents privileged containers on that specific node, but does not restrict the `hostNetwork` setting; a pod can still set `hostNetwork: true` without being privileged. Option C is wrong because PodSecurityPolicy (PSP) has been deprecated since Kubernetes v1.21 and removed in v1.25; while a PSP with `hostNetwork: false` would work in older clusters, it is no longer a viable solution for current CKS exam contexts. Option D is wrong because NetworkPolicies operate at Layer 3/4 and cannot block a pod from binding to the host's network stack; `hostNetwork: true` bypasses the pod network entirely, making NetworkPolicies ineffective.

Full explanation →

738

MCQeasy

Which kube-apiserver flag enables encryption at rest for secrets?

A.--encryption-provider-config

B.--encryption-key-file

C.--secret-encryption

D.--enable-encryption

AnswerA

The --encryption-provider-config flag is the only option that exists on the kube-apiserver for enabling encryption at rest. It accepts the path to an EncryptionConfiguration YAML file, which defines the secret (or other resource) types to encrypt and the ordered list of providers (identity, aescbc, aesgcm, secretbox) along with their keys. When the API server starts, it reads this file and uses it to encrypt data before writing to etcd and to decrypt it on read, making this the correct mechanism.

Why this answer

The `--encryption-provider-config` flag is the correct answer because it is the kube-apiserver flag that specifies the path to a configuration file containing the encryption providers (like `aescbc`, `secretbox`, or `aesgcm`) and the associated keys for encrypting Kubernetes secrets at rest. This flag enables the encryption at rest feature for secrets and other resources, as defined in the encryption configuration file.

Exam trap

The trap here is that candidates may confuse the `--encryption-provider-config` flag with a non-existent flag like `--enable-encryption` or `--secret-encryption`, assuming encryption at rest is enabled by a simple boolean flag rather than a configuration file reference.

How to eliminate wrong answers

Option B is wrong because `--encryption-key-file` is not a valid kube-apiserver flag; encryption keys are defined within the encryption provider configuration file, not via a separate key file flag. Option C is wrong because `--secret-encryption` is not a real kube-apiserver flag; the encryption at rest feature is configured through the encryption provider configuration, not a dedicated secret encryption flag. Option D is wrong because `--enable-encryption` is not a valid kube-apiserver flag; the encryption at rest feature is enabled by providing the `--encryption-provider-config` flag, not a boolean enable flag.

Full explanation →

739

Multi-Selectmedium

Which TWO of the following are valid Pod Security Standard levels? (Select 2)

Select 2 answers

A.medium

B.high

C.default

D.privileged

E.restricted

AnswersD, E

Privileged is one of the three valid Pod Security Standard levels and is the most permissive. It disables nearly every security restriction, allowing privileged containers, host namespace sharing, hostPath volumes, and unrestricted capabilities. This level is intended for system-critical workloads such as cluster add-ons or monitoring agents that require broad host access, but it provides no hardening; because it is an actual PSS level, it is correct.

Why this answer

The Pod Security Standards (PSS) define three levels: privileged, baseline, and restricted. The privileged level is the most permissive, allowing known privilege escalations and is intended for system-level workloads that require unrestricted access to host resources. It is explicitly listed in the Kubernetes documentation as one of the three valid PSS levels.

Exam trap

CNCF often tests the exact three Pod Security Standard levels (privileged, baseline, restricted) and expects candidates to recognize that 'medium', 'high', and 'default' are distractors that sound plausible but are not part of the official Kubernetes specification.

Full explanation →

740

MCQmedium

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

A.Delete the namespace and redeploy all workloads

B.Increase the memory limit in the pod's container resource specification

C.Delete and recreate the pod to clear the crash loop

D.Increase the CPU request for the container

AnswerB

Raising the container's memory limit directly addresses the OOMKilled termination, which occurs when the container exceeds its configured memory limit and the kernel kills the process. Since the pod ran successfully for days before failing, the workload's memory demand has grown beyond the current ceiling, so increasing the limit satisfies that constraint.

Why this answer

The pod is in CrashLoopBackOff due to OOMKilled, meaning the container is being terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it exceeds its memory limit. Increasing the memory limit in the container's resource specification allows the container to allocate more memory without being killed, directly addressing the root cause.

Exam trap

Many candidates mistakenly think that restarting the pod (Option C) will fix transient issues, but here the OOMKilled state is a persistent resource constraint, not a transient failure.

How to eliminate wrong answers

Option A is wrong because deleting the namespace and redeploying all workloads is an extreme, disruptive action that does not fix the underlying memory limit issue and would cause unnecessary downtime. Option C is wrong because deleting and recreating the pod will not resolve the OOMKilled condition; the new pod will still hit the same memory limit and crash again. Option D is wrong because increasing the CPU request does not affect memory allocation; the OOM killer is triggered by memory exhaustion, not CPU pressure.

Full explanation →

741

MCQmedium

You need to enforce that all pods in the 'production' namespace run with read-only root filesystems. Which OPA Gatekeeper resource do you create first?

A.A ConfigMap containing the Rego policy, then reference it in a custom admission controller

B.A ConstraintTemplate containing a Rego policy that checks for readOnlyRootFilesystem: true

C.A Constraint resource that enforces the readOnlyRootFilesystem rule

D.A ValidatingWebhookConfiguration that points to the Gatekeeper service

AnswerB

A ConstraintTemplate is the correct and mandatory first step for defining Gatekeeper policy because it wraps the Rego logic in a custom resource definition (CRD) that the Gatekeeper controller can process. The `spec.targets[].rego` field in the template contains the actual OPA policy, which evaluates `input.review.object.spec.containers` to enforce `readOnlyRootFilesystem: true`. Creating the ConstraintTemplate before instantiating a Constraint ensures the policy logic exists and is compiled, because the Constraint merely references the template and supplies matching rules and parameters — without the template, no enforcement can occur.

Why this answer

OPA Gatekeeper requires a ConstraintTemplate first to define the Rego policy logic that checks for `readOnlyRootFilesystem: true`. The ConstraintTemplate is a custom resource that tells Gatekeeper what rule to enforce; without it, you cannot create a Constraint to apply the policy to the 'production' namespace. This follows the Gatekeeper workflow: template → constraint → enforcement via admission webhooks.

Exam trap

The exam often tests the order of Gatekeeper resources: candidates mistakenly think a Constraint (option C) is created first, but the ConstraintTemplate must exist first to define the Rego logic, as the Constraint only applies the rule.

How to eliminate wrong answers

Option A is wrong because a ConfigMap containing Rego policy is not a native Gatekeeper resource; Gatekeeper uses ConstraintTemplates and Constraints, not ConfigMaps, and referencing it in a custom admission controller bypasses Gatekeeper's framework. Option C is wrong because a Constraint resource cannot be created without first defining the ConstraintTemplate that provides the Rego policy; the Constraint only instantiates the rule for specific scopes like namespaces. Option D is wrong because a ValidatingWebhookConfiguration is created automatically by Gatekeeper's installation (or manually if deploying from scratch), but it is not the first resource you create to define a policy; it is an infrastructure component that points to the Gatekeeper service, not a policy definition.

Full explanation →

742

Multi-Selecthard

Which TWO of the following are valid approaches to restrict which nodes a pod can run on?

Select 2 answers

A.Use nodeSelector in pod spec

B.Define NetworkPolicy to allow only certain nodes

C.Enable PodSecurity with baseline profile

D.Use tolerations in pod spec

E.Use nodeAffinity in pod spec

AnswersA, E

A nodeSelector is a hard scheduling constraint defined in the pod spec that restricts the pod to nodes carrying a specific label. It uses simple equality-based matching: the pod's key-value pair must exactly match a label on the node, and if no node matches, the pod remains Pending. Unlike nodeAffinity, nodeSelector supports only the 'equals' operation with no logical operators or preferences, making it a concise but less expressive tool for selecting nodes with static labels such as disktype=ssd.

Why this answer

`nodeSelector` is a simple field in the Pod spec that constrains which nodes a Pod can be scheduled on by matching against node labels. This is a native Kubernetes scheduling mechanism that directly restricts node placement based on key-value pairs defined on nodes.

Exam trap

CNCF often tests the distinction between scheduling constraints (`nodeSelector`, `nodeAffinity`) and scheduling permissions (`tolerations`), where candidates mistakenly think tolerations restrict placement when they actually only allow scheduling on tainted nodes.

Full explanation →

743

MCQmedium

An administrator wants to ensure that only images from a trusted registry 'myregistry.io' can run in the cluster. Which admission controller should be configured?

A.NodeRestriction

B.MutatingAdmissionWebhook

C.ImagePolicyWebhook

D.PodSecurity

AnswerC

ImagePolicyWebhook forwards image admission requests to an external HTTPS endpoint that approves or rejects them. Configuring it to permit only myregistry.io images enforces the trusted-registry constraint at admission time, blocking pods referencing any other registry.

Why this answer

The ImagePolicyWebhook admission controller enforces that only images from a trusted registry (e.g., 'myregistry.io') can run. It does this by querying an external webhook to validate the image source against a policy. Options A, B, and D are incorrect: NodeRestriction restricts node API access, MutatingAdmissionWebhook can mutate pods but is not specifically designed for image registry control, and PodSecurity handles pod security contexts, not image source validation.

Exam trap

The trap here is that candidates often confuse PodSecurity (or deprecated PodSecurityPolicy) with image registry control, but PodSecurity only handles pod-level security contexts, not image source validation. ImagePolicyWebhook is the correct admission controller for this purpose.

How to eliminate wrong answers

Option A is wrong because NodeRestriction limits the kubelet's ability to modify node and pod objects, not image source validation. Option B is wrong because MutatingAdmissionWebhook can modify resources but is not specifically designed for image policy enforcement; it would require custom logic and does not natively provide registry whitelisting. Option D is wrong because PodSecurity (formerly PodSecurityPolicy) enforces security context constraints (e.g., privilege escalation, SELinux) but does not validate the registry from which images are pulled.

Full explanation →

744

MCQhard

Which of the following is NOT a valid priority level in a Falco rule?

A.NOTICE

B.HIGH

C.CRITICAL

D.WARNING

AnswerB

HIGH is not a valid priority level in this context. Falco's predefined priority levels are EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFO, and DEBUG; there is no HIGH level. A rule that needs to indicate a serious threat above WARNING must use CRITICAL (or ALERT/EMERGENCY), not HIGH.

Why this answer

Falco rules support priority levels as defined in the syslog severity standard. The valid priorities are: EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFORMATIONAL, and DEBUG. 'HIGH' is not a valid priority in Falco; the correct equivalent is 'ERROR' or 'CRITICAL' depending on severity. Therefore, option B is not a valid priority level.

Exam trap

The CNCF CKS exam often tests the exact set of Falco priority levels, and the trap here is that candidates confuse 'HIGH' with the valid 'ERROR' or 'CRITICAL' levels, as 'HIGH' is a common severity label in other security tools but is not part of Falco's syslog-based priority list.

How to eliminate wrong answers

Option A is wrong because NOTICE is a valid Falco priority, corresponding to syslog severity level 5. Option C is wrong because CRITICAL is a valid Falco priority, corresponding to syslog severity level 2. Option D is wrong because WARNING is a valid Falco priority, corresponding to syslog severity level 4.

Full explanation →

745

MCQhard

A Falco rule is written to detect access to /etc/shadow inside a container. Which condition should be used?

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

B.spawned_process and proc.name in (cat, less) and container

C.evt.type=execve and proc.name=cat and fd.name=/etc/shadow

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

AnswerD

The open syscall is the correct hook because it is the first syscall where the target path is supplied by the caller and resolved by the kernel, making it ideal for path-based detection. With evt.type=open, fd.name matches the path exactly as passed, and the event is emitted on both successful opens and failed attempts like EACCES, so even permission-denied probing is captured. This rule does not depend on the process name, meaning it works for any utility or binary, and it also covers openat variants when Falco normalizes them appropriately. It is the most reliable and complete condition for detecting access to /etc/shadow among the given options.

Why this answer

The correct condition is 'evt.type=open and fd.name=/etc/shadow' because reading a file in Linux typically involves the open or openat syscall to obtain a file descriptor. Falco's fd.name field captures the file path, and evt.type=open detects the attempt to open the file. This directly detects access to /etc/shadow without relying on specific tools like cat or less.

Exam trap

CKS often tests the confusion between process execution (execve) and file access (open), leading candidates to pick options that monitor process names instead of syscalls.

How to eliminate wrong answers

Option A is wrong because evt.type=read is not a valid syscall for file access; read is used after a file is opened, and fd.name may not be populated correctly. Option B is wrong because it only detects specific processes (cat, less) and misses other tools or methods of reading the file. Option C is wrong because evt.type=execve detects process execution, not file access, and combining with proc.name=cat is too narrow.

Full explanation →

746

Multi-Selecteasy

Which TWO checks are performed by kube-bench for the master node?

Select 2 answers

A.Ensure that the kubelet uses the NodeRestriction admission plugin

B.Ensure that the API server uses TLS 1.2

C.Ensure that the container runtime is Docker

D.Ensure that the --anonymous-auth argument is set to false

E.Ensure that the --audit-log-path argument is set

AnswersD, E

kube-bench verifies that the API server has --anonymous-auth explicitly set to false. This is a critical CIS control because enabling anonymous authentication allows unauthenticated requests to reach the API server, potentially leading to unauthorized cluster access. The check is performed on the kube-apiserver process to ensure that anonymous requests are rejected.

Why this answer

Option D is correct because kube-bench's master node checks (from the CIS Kubernetes Benchmark, section 1.2.x on API server) include verifying that the API server's --anonymous-auth argument is set to false, preventing unauthenticated requests to the API server. Option E is correct because kube-bench also checks that the --audit-log-path argument is set on the API server, ensuring audit logging is enabled and events are written to a log file. Option A is not a master node check; the NodeRestriction admission plugin is verified in the worker node section (kubelet configuration, 4.2.x).

Option B is not a kube-bench master check as stated; kube-bench verifies TLS cipher suites and related API server flags rather than a simple 'uses TLS 1.2' check. Option C is incorrect because kube-bench does not require Docker as the container runtime; it supports any CRI-compliant runtime and checks runtime-specific configuration separately.

Exam trap

CNCF often tests the distinction between kube-bench checks for the master node vs. worker node, and candidates mistakenly think kube-bench checks for container runtime type (like Docker) or TLS version specifics, when in reality kube-bench focuses on CIS benchmark items like authentication settings and audit logging.

Full explanation →

747

MCQmedium

An administrator runs `kube-bench` and sees that the check 'Ensure that the --protect-kernel-defaults flag is set to true' has failed. Which component does this check apply to?

A.etcd

B.API server

C.Kubelet

D.Controller manager

AnswerC

The --protect-kernel-defaults flag belongs to the kubelet, which runs on each node and is responsible for the node's runtime environment. When enabled, the kubelet verifies that sensitive kernel parameters like vm.overcommit_memory and kernel.panic match its defaults, and it fails startup if they do not. This prevents a node from running with insecure kernel settings and is the exact target of the kube-bench check in question.

Why this answer

The `--protect-kernel-defaults` flag is a kubelet-specific security option that ensures the kubelet does not modify kernel parameters that could weaken node security. When set to true, it enforces that the kubelet respects kernel defaults, preventing privilege escalation via sysctl overrides. This check is part of the CIS Benchmark for the kubelet component, not for etcd, the API server, or the controller manager.

Exam trap

The trap here is that candidates often associate kernel parameter protection with the kubelet's sysctl management, but mistakenly attribute it to the API server or controller manager, which handle authorization and scheduling, not node-level kernel interactions.

How to eliminate wrong answers

Option A is wrong because etcd does not have a `--protect-kernel-defaults` flag; etcd uses flags like `--auto-compaction-retention` and `--peer-cert-file` for security. Option B is wrong because the API server does not have a `--protect-kernel-defaults` flag; its security flags include `--anonymous-auth`, `--authorization-mode`, and `--tls-cert-file`. Option D is wrong because the controller manager does not have a `--protect-kernel-defaults` flag; its relevant security flags are `--use-service-account-credentials` and `--root-ca-file`.

Full explanation →

748

MCQeasy

An administrator wants to restrict pods from running as root. Which admission controller should be enabled?

A.NodeRestriction

B.AlwaysPullImages

C.ServiceAccount

D.PodSecurity

AnswerD

PodSecurity is the correct answer because it is a built-in admission controller that enforces the Pod Security Standards, specifically the 'restricted' profile, which mandates that containers run as a non-root user (e.g., runAsNonRoot: true and runAsUser set to a non-zero ID). It validates the Pod's securityContext during creation and rejects any Pod that attempts to run as root. This directly implements the administrator's policy to restrict root execution.

Why this answer

The PodSecurity admission controller (D) is the correct choice because it enforces the Pod Security Standards (Privileged, Baseline, Restricted) defined in the Kubernetes documentation. By enabling this controller, the administrator can configure a policy that prevents pods from running as root, typically by setting the 'Restricted' profile which requires 'runAsNonRoot: true' and 'runAsUser: > 10000' in the pod security context.

Exam trap

CNCF often tests the misconception that NodeRestriction or ServiceAccount can enforce pod-level security policies, but these controllers serve entirely different purposes—NodeRestriction is for kubelet authorization, and ServiceAccount is for identity management, not for restricting root access.

How to eliminate wrong answers

Option A (NodeRestriction) is wrong because it limits the Node API access for kubelets, preventing them from modifying sensitive node objects, but it does not enforce any pod-level security policies like preventing root containers. Option B (AlwaysPullImages) is wrong because it ensures that container images are always pulled from the registry, which is a security measure against stale or tampered images, but it has no effect on the user ID under which a container runs. Option C (ServiceAccount) is wrong because it manages the automatic creation and mounting of service account tokens into pods, but it does not restrict the security context or user ID of the containers.

Full explanation →

749

MCQmedium

A CI/CD pipeline builds a Docker image and pushes it to a registry. To ensure supply chain security, the pipeline should scan the image for vulnerabilities before deployment. Which of the following is the correct command to scan a local Docker image using Trivy?

A.trivy fs --image myimage:latest

B.trivy image myimage:latest

C.trivy scan myimage:latest

D.trivy check myimage:latest

AnswerB

This is the correct command because `trivy image` is the dedicated subcommand for scanning container images. It resolves `myimage:latest` from the local Docker daemon cache or a remote registry, analyzes the image layers and SBOM of OS packages (like Alpine, Debian, CentOS) and language-specific dependencies (pip, npm, cargo, etc.), and then compares them against the Trivy vulnerability database to report CVEs. In a CI/CD pipeline, running this after `docker build` but before `docker push` catches vulnerable images before they are published.

Why this answer

`trivy image` is the specific subcommand used to scan a local Docker image for vulnerabilities. Trivy requires the `image` subcommand followed by the image name and tag (e.g., `myimage:latest`) to analyze the image layers and report CVEs. This command directly integrates with the local Docker daemon to access the image.

Exam trap

The CKAD/CKS exam often tests the distinction between Trivy subcommands (e.g., `image` vs. `fs` vs. `repo`) to catch candidates who assume a generic `scan` or `check` verb exists, mirroring common misconceptions from other tools like Docker Scout or Snyk.

How to eliminate wrong answers

Option A is wrong because `trivy fs` scans a filesystem or directory, not a Docker image; it is used for scanning local file paths or repositories, not container images. Option C is wrong because `trivy scan` is not a valid subcommand; Trivy uses specific subcommands like `image`, `fs`, `repo`, or `config` depending on the target. Option D is wrong because `trivy check` is not a valid subcommand; Trivy does not have a `check` command—the correct subcommand for image scanning is `image`.

Full explanation →

750

Multi-Selectmedium

Which TWO of the following are valid steps to respond to a runtime security incident where a container is suspected to be compromised? (Select two.)

Select 2 answers

A.Apply a NetworkPolicy that denies all ingress and egress to the pod

B.Immediately delete the pod to stop the attack

C.Add a taint to the node to evict the pod

D.Use kubectl logs to capture container logs before taking action

E.Restart the kubelet on the node

AnswersA, D

Applying a NetworkPolicy that denies all ingress and egress to the pod is a correct first step because it achieves network-level containment without destroying the running container or its filesystem. This isolation prevents the attacker from communicating with the pod or using it as a pivot, while preserving the pod's memory, disk, and process state for forensic analysis. Unlike deletion or eviction, this action is reversible and does not trigger rescheduling, keeping the compromised pod in a known, quarantined state for further investigation.

Why this answer

Applying a NetworkPolicy that denies all ingress and egress to the compromised pod immediately isolates it, preventing lateral movement and data exfiltration while preserving the pod for forensic analysis. This aligns with the incident response principle of containment before eradication, and Kubernetes NetworkPolicy uses label selectors and pod selectors to enforce eBPF/iptables-based rules at the CNI layer.

Exam trap

The exam often tests the misconception that immediate deletion or node-level actions (like tainting or restarting kubelet) are appropriate first-response steps, when in fact the priority is containment and evidence preservation using network isolation and logging.

Full explanation →

Certified Kubernetes Security Specialist CKS (CKS) — Questions 676–750