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

751

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 the most permissive level.

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 →

752

MCQeasy

Which tool can generate an SBOM (Software Bill of Materials) from a container image?

A.syft

B.kubesec

C.trivy

D.checkov

AnswerA

Syft produces SBOMs in various formats (SPDX, CycloneDX) from container images.

Why this answer

Syft is a CLI tool specifically designed to generate a Software Bill of Materials (SBOM) from container images and filesystems. It uses static analysis to extract package metadata from package managers (e.g., dpkg, RPM, APK) and produces SBOMs in formats like SPDX and CycloneDX, directly addressing the requirement for supply chain transparency.

Exam trap

The trap here is that candidates confuse Trivy's vulnerability scanning capability with its SBOM generation feature, but the CKS exam expects you to know that Syft is the dedicated SBOM tool from Anchore, while Trivy is primarily a vulnerability scanner that can also produce SBOMs as a secondary function.

How to eliminate wrong answers

Option B (kubesec) is wrong because it is a static analysis tool for Kubernetes resource manifests, not for generating SBOMs from container images. Option C (trivy) is wrong because while Trivy can scan container images for vulnerabilities and also generate SBOMs, its primary function is vulnerability scanning, and the question asks for a tool that 'can generate an SBOM' — Syft is the dedicated SBOM generator, whereas Trivy's SBOM generation is a secondary feature. Option D (checkov) is wrong because it is a policy-as-code tool for scanning infrastructure-as-code (Terraform, CloudFormation, Kubernetes) for misconfigurations, not for extracting package metadata from container images.

Full explanation →

753

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

ConstraintTemplate defines the Rego policy logic and parameters. It must be created before instantiating a Constraint.

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 →

754

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

nodeSelector matches nodes with specific labels.

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 →

755

MCQhard

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

A.NOTICE

B.HIGH

C.CRITICAL

D.WARNING

AnswerB

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 →

756

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

Correct. open syscall with fd.name exactly matching /etc/shadow.

Why this answer

Access to a file is detected by the 'open' syscall event. To detect reads of /etc/shadow, use 'evt.type=open' and 'fd.name' containing the path.

Full explanation →

757

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

This is a CIS check for the API server.

Why this answer

Kube-bench checks that the API server's `--anonymous-auth` argument is set to `false` to prevent unauthenticated requests. This is a CIS Kubernetes Benchmark recommendation (e.g., 1.2.1) to enforce authentication for all API server requests. Setting this to false ensures that anonymous users cannot perform operations on the API server, reducing the attack surface.

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 →

758

Multi-Selectmedium

Which THREE are valid admission controllers in Kubernetes? (Select three.)

Select 3 answers

A.ServiceAccount

B.NetworkPolicy

C.ImagePolicyWebhook

D.MutatingAdmissionWebhook

E.PodSecurity

AnswersC, D, E

It is an admission controller that validates images.

Why this answer

ImagePolicyWebhook is a valid admission controller that allows an external webhook to validate container images against a policy before they are admitted into the cluster. It is part of Kubernetes' supply chain security controls, enabling checks such as image signature verification or registry allowlisting.

Exam trap

The trap here is that candidates confuse Kubernetes resources (like ServiceAccount and NetworkPolicy) with admission controllers, which are separate components that modify or validate API requests before they are persisted.

Full explanation →

759

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 flag belongs to the kubelet to protect kernel defaults.

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 →

760

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 enforces the Pod Security Standards, including 'restricted' profile which prevents running as root.

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 →

761

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 command scans the specified container image for vulnerabilities.

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 →

762

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

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 →

763

MCQhard

An etcd cluster uses TLS for peer and client communication. You need to secure etcd further by enabling RBAC. Which flag do you set on the etcd process to enable authentication?

A.--client-cert-auth=true

B.--enable-rbac=true

C.--authentication-mode=RBAC

D.--auth-mode=rbac

AnswerA

This enables client certificate authentication, which is required for RBAC.

Why this answer

In etcd, RBAC is not enabled by a dedicated RBAC flag; instead, authentication must first be turned on using `--client-cert-auth=true`. This flag requires clients to present a valid TLS certificate, which is the prerequisite for enabling RBAC. After setting this flag, you can use `etcdctl` commands like `etcdctl role add` and `etcdctl user add` to configure RBAC roles and users.

Exam trap

The trap here is that candidates often assume there is a direct `--enable-rbac` or `--auth-mode` flag for RBAC, but etcd requires `--client-cert-auth=true` first, and then RBAC is enabled via the etcd API or `etcdctl` commands.

How to eliminate wrong answers

Option B is wrong because `--enable-rbac=true` is not a valid etcd flag; etcd does not have a direct flag to enable RBAC. Option C is wrong because `--authentication-mode=RBAC` is not a recognized etcd flag; authentication in etcd is controlled via TLS client certificate authentication, not a mode parameter. Option D is wrong because `--auth-mode=rbac` is not a valid etcd flag; etcd uses `--client-cert-auth` for authentication and then RBAC is configured via the API or `etcdctl` commands.

Full explanation →

764

MCQeasy

You need to ensure that all containers in a pod run as non-root. Which security context field should you set to enforce this?

A.privileged: false

B.readOnlyRootFilesystem: true

C.allowPrivilegeEscalation: false

D.runAsNonRoot: true

AnswerD

This field enforces that the container runs as a non-root user.

Why this answer

Setting `runAsNonRoot: true` in the pod or container security context instructs Kubernetes to verify that the container's user ID (UID) is non-zero (i.e., not root) before starting the container. If the container image is configured to run as root (UID 0), the Pod will fail to start, ensuring compliance with the requirement that all containers run as non-root.

Exam trap

The trap here is that candidates often confuse `runAsNonRoot: true` with `allowPrivilegeEscalation: false` or `privileged: false`, thinking that disabling privilege escalation or privileged mode is sufficient to enforce non-root execution, but those fields do not actually prevent the container from running as the root user.

How to eliminate wrong answers

Option A is wrong because `privileged: false` is the default behavior and does not enforce non-root execution; it only disables privileged mode (e.g., access to host devices). Option B is wrong because `readOnlyRootFilesystem: true` only makes the container's root filesystem read-only, which is a security measure but does not prevent the container from running as root. Option C is wrong because `allowPrivilegeEscalation: false` prevents the container from gaining additional privileges (e.g., via setuid binaries) but does not require the container to run as a non-root user.

Full explanation →

765

Multi-Selectmedium

Which TWO admission plugins should be enabled to improve cluster security according to the CIS Benchmark? (Select 2)

Select 2 answers

A.NodeRestriction

B.PodSecurity

C.AlwaysPullImages

D.NamespaceLifecycle

E.ServiceAccount

AnswersA, B

CIS recommends enabling NodeRestriction to limit kubelet permissions.

Why this answer

NodeRestriction (A) is correct because it limits the permissions of kubelet nodes to only modify their own pods and node objects, preventing a compromised node from accessing or modifying other nodes' resources. PodSecurity (B) is correct because it enforces Pod Security Standards (Privileged, Baseline, Restricted) at the namespace level, replacing the deprecated PodSecurityPolicy and ensuring pods comply with security contexts like running as non-root or dropping capabilities. Both are explicitly recommended in the CIS Benchmark for Kubernetes to reduce the attack surface.

Exam trap

CNCF often tests the distinction between plugins that are 'recommended for security' (like NodeRestriction and PodSecurity) versus those that are 'useful but not CIS-mandated' (like AlwaysPullImages), leading candidates to over-select based on general security benefits rather than the specific CIS Benchmark requirements.

Full explanation →

766

MCQmedium

Which of the following host access settings should be avoided to minimize the attack surface from containers? (Select the setting that increases risk the most.)

A.hostPID: true

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

C.readOnlyRootFilesystem: true

D.resources: limits: memory: "512Mi"

AnswerA

Setting `hostPID: true` grants a container direct access to the host’s process ID namespace, allowing it to view and potentially interact with all processes running on the host. This violates the principle of namespace isolation, which is the core constraint the stem targets for minimising attack surface. Exposing host PID enables privilege escalation or information leakage from other containers or system services.

Why this answer

Setting `hostPID: true` allows a container to share the host's process ID namespace, enabling it to see all processes running on the host. This breaks the fundamental isolation that containers should provide, giving a compromised container direct visibility into host processes and the ability to potentially interact with them (e.g., sending signals). This significantly increases the attack surface and is the most dangerous setting among the options.

Exam trap

The CKS exam often tests the misconception that resource limits or read-only filesystems are more critical for security than namespace isolation, but the core principle is that sharing the host PID namespace breaks container isolation at the kernel level, which is far more dangerous than misconfiguring capabilities or resource constraints.

How to eliminate wrong answers

Option B is wrong because dropping all capabilities with `drop: ["ALL"]` is a security best practice that minimizes the kernel capabilities available to the container, reducing the attack surface. Option C is wrong because setting `readOnlyRootFilesystem: true` mounts the container's root filesystem as read-only, preventing writes to the container's filesystem and mitigating tampering or malware persistence. Option D is wrong because setting memory limits with `resources.limits.memory: "512Mi"` is a resource constraint that prevents a container from consuming excessive host memory, which helps mitigate denial-of-service risks and is a recommended security control.

Full explanation →

767

MCQmedium

A Falco rule detects unexpected outbound connections. Which condition would identify a connection to an external IP not in the allowed list?

A.evt.type=connect and fd.ip not in (allowed_ips)

B.evt.type=accept and fd.ip not in (allowed_ips)

C.evt.type=listen and fd.ip not in (allowed_ips)

D.evt.type=bind and fd.ip not in (allowed_ips)

AnswerA

This matches connect syscalls to IPs not in the allowed list.

Why this answer

The evt.type=connect and fd.ip checks the destination IP; combined with a not in list condition detects unexpected outbound connections.

Full explanation →

768

Multi-Selecthard

You need to preserve forensic evidence from a compromised pod. Which TWO actions should you take?

Select 2 answers

A.Delete the pod immediately

B.Take a snapshot of the container's filesystem

C.Apply a NetworkPolicy to allow all traffic

D.Capture the container logs using kubectl logs

E.Restart the container

AnswersB, D

Preserves the filesystem state for analysis.

Why this answer

Taking a snapshot of the container filesystem (e.g., using crictl export) and capturing the container logs are standard forensic steps.

Full explanation →

769

MCQhard

You are creating a custom seccomp profile for a container that runs a binary requiring the 'write' syscall only. You place the profile JSON file at '/var/lib/kubelet/seccomp/profiles/write-only.json'. In the pod spec, which seccomp configuration correctly uses this profile?

A.securityContext: seccompProfile: type: RuntimeDefault localhostProfile: profiles/write-only.json

B.securityContext: seccompProfile: type: Localhost localhostProfile: /var/lib/kubelet/seccomp/profiles/write-only.json

C.securityContext: seccompProfile: type: Localhost localhostProfile: profiles/write-only.json

D.securityContext: seccompProfile: type: Localhost profile: write-only.json

AnswerC

Correctly specifies type Localhost and the profile path relative to /var/lib/kubelet/seccomp/.

Why this answer

When using a custom seccomp profile with type 'Localhost', the 'localhostProfile' field must specify a path relative to the kubelet's seccomp root directory (default: /var/lib/kubelet/seccomp). The path 'profiles/write-only.json' is relative and resolves to /var/lib/kubelet/seccomp/profiles/write-only.json, matching the file location. The 'type' field must be 'Localhost' to reference a local profile file.

Exam trap

CNCF often tests the distinction between relative and absolute paths for 'localhostProfile', and the trap here is that candidates mistakenly use an absolute path (option B) or confuse the field name 'localhostProfile' with 'profile' (option D), while also testing that 'type: RuntimeDefault' cannot be combined with a custom profile path.

How to eliminate wrong answers

Option A is wrong because 'type: RuntimeDefault' uses the container runtime's default seccomp profile, not a custom one, and 'localhostProfile' is ignored when type is not Localhost. Option B is wrong because 'localhostProfile' must be a relative path from the kubelet's seccomp root directory, not an absolute path; using '/var/lib/kubelet/seccomp/profiles/write-only.json' would cause the kubelet to look for the file at /var/lib/kubelet/seccomp/var/lib/kubelet/seccomp/profiles/write-only.json, which does not exist. Option D is wrong because the field name is 'localhostProfile', not 'profile', and 'profile' is not a valid key in the seccompProfile object.

Full explanation →

770

MCQhard

An AppArmor profile is loaded in 'complain' mode. What happens when a pod with that profile attempts an action that violates the profile?

A.The pod is terminated.

B.The action is allowed but a log entry is created.

C.The action is allowed and no log is generated.

D.The action is blocked and an audit log is generated.

AnswerB

Complain mode allows the action and logs the violation.

Why this answer

In AppArmor, 'complain' mode (also known as 'learning' mode) allows all actions, including those that violate the profile, but logs the violation to the system audit log (typically via auditd or syslog). This is distinct from 'enforce' mode, which blocks violating actions. Therefore, when a pod runs with a profile in complain mode, prohibited actions are permitted and recorded.

Exam trap

CNCF often tests the distinction between AppArmor modes, and the trap here is confusing 'complain' mode with 'enforce' mode, leading candidates to think violations are blocked or that no logging occurs.

How to eliminate wrong answers

Option A is wrong because termination only occurs in 'enforce' mode when a violation is blocked, not in complain mode. Option C is wrong because complain mode explicitly generates a log entry for each violation; no log would only happen if the profile were not loaded or in 'audit' mode without logging. Option D is wrong because blocking the action is the behavior of 'enforce' mode, not complain mode; audit logs are generated in both modes, but in complain mode the action is allowed.

Full explanation →

771

MCQeasy

Which tool is commonly used to generate a Software Bill of Materials (SBOM) for a container image?

A.kubesec

B.syft

C.trivy

D.cosign

AnswerB

Syft is designed to generate SBOMs from container images and filesystems.

Why this answer

Syft is a CLI tool purpose-built for generating Software Bill of Materials (SBOMs) from container images and filesystems. It uses static analysis to extract package metadata (e.g., dpkg, RPM, APK, Python, Node.js) and outputs the SBOM in formats like CycloneDX or SPDX, which are the industry standards for supply chain transparency.

Exam trap

The CKS exam 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 SBOM capability with its primary vulnerability scanning role.

How to eliminate wrong answers

Option A is wrong because kubesec is a static analysis tool for Kubernetes resource manifests (YAML/JSON), not for generating SBOMs from container images. Option C is wrong because Trivy is primarily a vulnerability scanner that can also produce SBOMs as a secondary feature, but it is not the tool commonly associated with SBOM generation; Syft is the dedicated SBOM generator. Option D is wrong because cosign is used for signing and verifying container image signatures (e.g., using Sigstore), not for generating SBOMs.

Full explanation →

772

MCQmedium

An administrator runs 'kube-bench master' and receives a warning that etcd has no client certificate authentication. What is the recommended remediation?

A.Remove the --client-cert-auth flag

B.Set --anonymous-auth=true on etcd

C.Use etcdctl to enable authentication

D.Set --client-cert-auth=true and --trusted-ca-file on the etcd process

AnswerD

This enables mutual TLS authentication for etcd clients.

Why this answer

The warning indicates that etcd is running without client certificate authentication, which means any client can communicate with etcd without verifying its identity. Setting `--client-cert-auth=true` enables TLS-based client certificate authentication, and `--trusted-ca-file` specifies the CA certificate used to validate client certificates. This is the recommended remediation because it ensures only clients with valid certificates signed by the trusted CA can access etcd, preventing unauthorized access to the cluster's key-value store.

Exam trap

The trap here is that candidates might think enabling authentication via `etcdctl` (Option C) is sufficient, but etcd's client certificate authentication must be configured at the server process level via startup flags, not through a client command.

How to eliminate wrong answers

Option A is wrong because removing the `--client-cert-auth` flag would disable client certificate authentication entirely, which is the opposite of the required remediation and would worsen the security issue. Option B is wrong because setting `--anonymous-auth=true` on etcd allows unauthenticated anonymous requests, which would bypass authentication and increase the attack surface, not fix the missing client certificate authentication. Option C is wrong because `etcdctl` is a client tool for interacting with etcd, not a mechanism to enable client certificate authentication on the etcd server process; authentication must be configured via etcd's startup flags or configuration file.

Full explanation →

773

MCQeasy

Which kubectl command lists all MutatingWebhookConfigurations in the cluster?

A.kubectl get webhooks

B.kubectl list webhooks

C.kubectl get mutatingwebhookconfigurations

D.kubectl get mutating-webhooks

AnswerC

Correct.

Why this answer

`kubectl get mutatingwebhookconfigurations` is the standard Kubernetes command to list all MutatingWebhookConfiguration resources. These resources are part of the admission webhook mechanism, which intercepts API requests to mutate objects before they are persisted. The resource name is case-sensitive and must match the exact API resource name `mutatingwebhookconfigurations` (or the short form `mutatingwebhookconfiguration`).

Exam trap

The trap here is that candidates may guess a generic or intuitive command like `kubectl get webhooks` or `kubectl get mutating-webhooks`, but the CKS exam expects exact knowledge of the Kubernetes API resource name `mutatingwebhookconfigurations` (no hyphens, no shorthand).

How to eliminate wrong answers

Option A is wrong because `kubectl get webhooks` is not a valid kubectl command; there is no built-in resource named 'webhooks' in Kubernetes. Option B is wrong because `kubectl list webhooks` is not a valid kubectl command; the correct verb is 'get', not 'list', and 'webhooks' is not a recognized resource. Option D is wrong because `kubectl get mutating-webhooks` uses a hyphenated form that does not match the actual API resource name `mutatingwebhookconfigurations`; Kubernetes resource names use camelCase or lowercase concatenation, not hyphens.

Full explanation →

774

Multi-Selecthard

Which TWO practices help secure the Kubernetes Dashboard?

Select 2 answers

A.Enable anonymous access to the Dashboard

B.Use a ClusterIP service and access it via kubectl proxy

C.Grant the Dashboard service account cluster-admin role for full functionality

D.Use RBAC to restrict Dashboard service account permissions to read-only

E.Expose the Dashboard via a NodePort service for easy access

AnswersB, D

Access via proxy avoids public exposure.

Why this answer

Accessing the Kubernetes Dashboard via `kubectl proxy` creates a secure, authenticated HTTP proxy between your local machine and the API server. This method leverages the API server's built-in authentication and authorization, ensuring that only users with valid kubeconfig credentials can reach the Dashboard. It also avoids exposing the Dashboard directly to the network, reducing the attack surface.

Exam trap

The trap here is that candidates often think exposing the Dashboard via a NodePort or granting it cluster-admin is acceptable for 'full functionality,' but the CKS exam strictly enforces least privilege and network security, making RBAC-restricted access via kubectl proxy the only secure approach among the options.

Full explanation →

775

Multi-Selectmedium

Which TWO are valid stages in a Kubernetes audit event? (Select 2)

Select 2 answers

A.RequestReceived

B.ResponseStarted

C.PreProcessing

D.None

E.PostProcessing

AnswersA, B

RequestReceived is a valid stage.

Why this answer

'RequestReceived' is one of the defined stages in the Kubernetes audit event lifecycle. When an audit policy is configured, the kube-apiserver records an audit event at the 'RequestReceived' stage after it has received the request but before it has been processed by the admission controllers or the resource handler. This stage captures the raw request as it arrives.

Exam trap

Kubernetes often tests the exact naming of audit stages, and the trap here is that candidates confuse generic terms like 'PreProcessing' or 'PostProcessing' with the actual Kubernetes-defined stages, which are strictly 'RequestReceived', 'ResponseStarted', 'ResponseComplete', and 'Panic'.

Full explanation →

776

Multi-Selecthard

Which THREE of the following are capabilities required for a Falco rule to detect privilege escalation via setuid binary execution? (Choose three.)

Select 3 answers

A.fd.name contains /dev/tcp

B.proc.name in (su, sudo)

C.proc.uid=0

D.evt.type=execve

E.evt.type=open

AnswersB, C, D

Common setuid binaries for privilege escalation.

Why this answer

Falco detects privilege escalation via setuid binary execution by monitoring the 'execve' syscall (option D) to capture process execution events. It then checks if the process name matches known setuid binaries like 'su' or 'sudo' (option B). Additionally, it verifies that the resulting process UID is 0 (root) (option C), indicating privilege escalation.

Option A (fd.name contains /dev/tcp) relates to network connections, and option E (evt.type=open) relates to file open events; neither is required for detection of setuid binary execution.

Full explanation →

777

Multi-Selectmedium

Which TWO of the following are valid ways to restrict access to etcd? (Select 2)

Select 2 answers

A.Enable RBAC on etcd by setting --auth-token=jwt and configuring roles.

B.Use --peer-auto-tls=true to auto-generate certificates.

C.Use --admission-control=NodeRestriction on etcd.

D.Use TLS client certificates for authentication.

E.Set --client-cert-auth=false to disable authentication.

AnswersA, D

etcd supports RBAC with JWT tokens to restrict access.

Why this answer

Etcd supports Role-Based Access Control (RBAC) when you enable it with the `--auth-token=jwt` flag and then configure roles and users via `etcdctl`. This allows you to restrict which clients can read or write to the etcd key-value store, which is critical for securing Kubernetes cluster state. Without RBAC, any client that can reach the etcd port can access all secrets and configuration data.

Exam trap

The trap here is that candidates confuse etcd's `--client-cert-auth` flag (which enables TLS client certificate authentication) with the Kubernetes API server's `--admission-control` flag, or they assume that peer TLS options restrict client access.

Full explanation →

778

Drag & Dropmedium

Order the steps to rotate a Kubernetes API server certificate.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Certificate rotation involves generating new certs, replacing files, restarting the service, and verifying. Kubeconfig updates may be needed if CA changes.

Full explanation →

779

MCQhard

A cluster has both ImagePolicyWebhook and a mutating webhook that adds a sidecar. The admin notices that even when ImagePolicyWebhook rejects an image, the mutating webhook has already added the sidecar. What admission ordering issue is occurring?

A.Validating webhooks should run before mutating webhooks

B.Use a validating webhook instead of ImagePolicyWebhook

C.The mutating webhook should be configured to skip pods with certain images

D.The ImagePolicyWebhook should be placed before the mutating webhook in the webhook configuration

AnswerA

Correct. This describes the issue exactly: validating webhooks should run before mutating webhooks, but the fixed order causes them to run after, leading to the sidecar being added even when the image is rejected.

Why this answer

In Kubernetes, admission controllers are invoked in a fixed order: mutating admission controllers (including MutatingAdmissionWebhook) run before validating ones (including ImagePolicyWebhook and ValidatingAdmissionWebhook). Therefore, the mutating webhook that adds the sidecar runs before ImagePolicyWebhook validates the image. This means even if ImagePolicyWebhook rejects the image, the sidecar has already been added.

The issue is that validating webhooks should run before mutating webhooks to prevent such problems, but the fixed order prevents this. Option B is wrong because using a validating webhook still runs after mutating webhooks. Option C is a workaround but not related to the ordering issue.

Option D is incorrect because you cannot change the order of built-in admission controllers; the order is fixed.

Exam trap

The trap is that candidates think they can reorder admission controllers, but Kubernetes enforces a fixed order: mutating runs before validating. Therefore, placing a validating controller before a mutating one is not possible.

How to eliminate wrong answers

Option A is wrong because the Kubernetes admission order is mutating webhooks first, then validating webhooks, not the reverse; placing validating before mutating would break the standard flow. Option B is wrong because using a validating webhook instead of ImagePolicyWebhook does not change the ordering issue; the problem is the sequence, not the type of webhook. Option C is wrong because configuring the mutating webhook to skip pods with certain images is a workaround, but it does not address the fundamental ordering problem and may not be feasible if the image is not known until after the mutating webhook runs.

Full explanation →

780

MCQhard

You want to allow only images from a specific registry (e.g., myregistry.io) to be deployed in your cluster. Which tool or approach is best suited for this requirement?

A.Use OPA/Gatekeeper to create a constraint that checks the image registry

B.Set up a NetworkPolicy to block traffic from other registries

C.Configure an ImagePolicyWebhook

D.Modify the kubelet configuration to only pull from a specific registry

AnswerA

Gatekeeper can enforce policies on images, including allowing only certain registries.

Why this answer

OPA/Gatekeeper allows you to define a ConstraintTemplate and a Constraint that validates the image registry in pod specs via a Rego rule. This approach enforces admission control at the API server level, rejecting any pod that references an image from an unauthorized registry before it is persisted in etcd.

Exam trap

A common misconception is that NetworkPolicy can control image sources, but NetworkPolicy operates on network traffic, not on admission of pod specifications.

How to eliminate wrong answers

Option B is wrong because NetworkPolicy controls network traffic between pods and external endpoints at layer 3/4, not image pull sources; it cannot prevent a pod from being created with an image from a disallowed registry. Option C is wrong because ImagePolicyWebhook is a deprecated admission controller that validates image signatures or policies, but it does not natively restrict which registry an image comes from without custom webhook logic, and it is not the recommended or best-suited tool for this specific registry allowlisting requirement. Option D is wrong because modifying the kubelet configuration to restrict image pulls is not a cluster-wide admission control mechanism; it only affects that specific node and can be bypassed by other nodes, and kubelet does not have a native setting to allow only a specific registry.

Full explanation →

781

MCQmedium

An administrator runs 'aa-status' on a node and sees a profile in 'complain' mode. What does this indicate?

A.The profile logs violations but does not block them.

B.The profile is disabled and has no effect.

C.The profile is enforcing restrictions and blocking violations.

D.The profile is not loaded.

AnswerA

Correct. Complain mode logs but does not enforce.

Why this answer

AppArmor profiles in 'complain' mode log policy violations to the system log (e.g., /var/log/syslog or audit.log) but do not enforce them, meaning the actions are allowed while being recorded. This is distinct from 'enforce' mode, where violations are blocked. The 'aa-status' command shows the current mode of loaded profiles.

Exam trap

The CKS exam often tests the distinction between 'complain' and 'enforce' modes, and the trap here is that candidates confuse 'complain' with 'disabled' or think it means the profile is not loaded, when in fact it is loaded and logging but not blocking.

How to eliminate wrong answers

Option B is wrong because a profile in 'complain' mode is still loaded and active, not disabled; disabling a profile would remove it from the kernel's policy or set it to 'unconfined'. Option C is wrong because 'enforce' mode is the one that blocks violations, not 'complain' mode. Option D is wrong because 'aa-status' only lists loaded profiles; if a profile were not loaded, it would not appear in the output at all.

Full explanation →

782

MCQhard

An organization uses a private container registry and wants to ensure that only images built from a specific CI/CD pipeline are deployed. Which combination of measures provides the strongest guarantee?

A.Implement network policies to restrict egress from pods to the registry.

B.Grant registry write access only to the CI system's service account.

C.Use a static analysis tool to check the Dockerfile before building.

D.Use a unique registry path and restrict access via firewall rules.

E.Generate signed attestations with in-toto during the CI pipeline and verify them using an admission webhook like Kyverno.

AnswerE

Attestations provide non-repudiation and can be verified at admission time.

Why this answer

It implements a complete chain of custody for container images. In-toto generates signed attestations that record every step of the CI/CD pipeline (e.g., source code checkout, build, test), and an admission webhook like Kyverno verifies these attestations before allowing a pod to run. This ensures that only images that passed the exact, attested pipeline are deployed, providing the strongest guarantee against unauthorized or tampered images.

Exam trap

CNCF often tests the distinction between access control measures (network policies, RBAC, firewalls) and cryptographic provenance verification; candidates mistakenly think restricting registry access or network egress is sufficient, but the exam emphasizes that only signed attestations with admission control can guarantee the image was built by the intended pipeline.

How to eliminate wrong answers

Option A is wrong because network policies restrict egress from pods to the registry, which controls runtime access but does not verify the provenance or integrity of the image itself; an attacker could still deploy a malicious image that was built outside the CI/CD pipeline. Option B is wrong because granting registry write access only to the CI system's service account prevents unauthorized pushes but does not prevent the CI system itself from being compromised or building images from untrusted sources; it lacks verification of the build process. Option C is wrong because static analysis of the Dockerfile checks for vulnerabilities or misconfigurations in the build instructions but does not provide any cryptographic proof that the resulting image was actually built from that Dockerfile in the approved pipeline.

Option D is wrong because using a unique registry path and firewall rules restricts network access but does not verify the image's supply chain; an attacker who gains access to the registry path could push arbitrary images.

Full explanation →

783

MCQhard

You need to create an RBAC role that allows reading secrets only in namespace 'production'. Which ClusterRole and RoleBinding combination is correct?

A.Create a ClusterRole with get and list on secrets, then a RoleBinding in 'production'

B.Create a Role with get and list on secrets in namespace 'production', then a ClusterRoleBinding

C.Create a ClusterRole with get and list on secrets, then a ClusterRoleBinding to bind it to the user

D.Create a Role with get and list on secrets in namespace 'production', then a RoleBinding in 'production'

AnswerD

This is correct. A Role is namespaced and grants permissions only within the specified namespace ('production'). A RoleBinding binds the Role to a user, group, or service account within the same namespace, ensuring the permissions are scoped exactly to 'production'.

Why this answer

A Role is namespaced and can only grant permissions within a specific namespace, which is 'production' in this case. A RoleBinding then binds that Role to a user, group, or service account within the same namespace, ensuring the permissions are scoped correctly. This combination restricts secret read access exclusively to the 'production' namespace, meeting the requirement precisely.

Exam trap

CNCF often tests the misconception that ClusterRoles are always cluster-wide even when bound via a RoleBinding, but the trap here is that a ClusterRole bound with a RoleBinding actually scopes permissions to that namespace, yet the question's requirement for a Role (not ClusterRole) is the precise answer because a Role is inherently namespaced and avoids any ambiguity about scope.

How to eliminate wrong answers

Option A is wrong because a ClusterRole is cluster-scoped and, when used with a RoleBinding, grants permissions across all namespaces unless explicitly restricted by a RoleBinding's namespace, but the RoleBinding itself does not limit the ClusterRole's scope to a single namespace; the ClusterRole's rules apply cluster-wide, so this would allow reading secrets in all namespaces. Option B is wrong because a Role is namespaced, but a ClusterRoleBinding binds cluster-wide, which would fail as a Role cannot be bound to a ClusterRoleBinding; ClusterRoleBindings only bind ClusterRoles, not Roles. Option C is wrong because a ClusterRole with get and list on secrets, when bound via a ClusterRoleBinding, grants permissions across all namespaces, not just 'production', violating the requirement to restrict access to a single namespace.

Full explanation →

784

MCQeasy

Which of the following is a valid method to disable automatic mounting of service account tokens for a pod?

A.Delete the service account token secret

B.Add 'automountServiceAccountToken: false' to the pod spec

C.Use a NetworkPolicy to block access to the token

D.Set the service account's 'automountServiceAccountToken' field to false

AnswerB

This field in the pod spec disables token mounting for that pod.

Why this answer

Setting `automountServiceAccountToken: false` in the pod spec explicitly disables the automatic mounting of the service account token into the pod. This is the most direct and granular way to prevent the token from being available inside the container, which is a key hardening step to reduce the attack surface if the pod does not need to interact with the Kubernetes API.

Exam trap

CNCF often tests the distinction between pod-level and service account-level settings, and candidates mistakenly choose the service account-level option (D) thinking it applies to all pods, but the pod-level setting (B) is the only one that directly and unconditionally disables mounting for that specific pod.

How to eliminate wrong answers

Option A is wrong because deleting the service account token secret does not prevent automatic mounting; Kubernetes will recreate the secret or the pod may still mount a token from a different secret. Option C is wrong because a NetworkPolicy controls network traffic, not filesystem mounts; it cannot block the pod's access to the token file that is already mounted inside the container. Option D is wrong because setting the service account's `automountServiceAccountToken` field to false only affects pods that use that service account by default, but a pod can override this by explicitly setting the field in its own spec; the pod-level setting takes precedence.

Full explanation →

785

Multi-Selectmedium

Which TWO of the following are valid methods to verify the integrity of a container image before deployment?

Select 2 answers

A.Run a vulnerability scan on the image

B.Use the latest tag to ensure the most recent version

C.Generate an SBOM for the image

D.Use the image digest (SHA256) instead of a tag

E.Verify the image signature using Cosign

AnswersD, E

Using the digest ensures that the exact image content is used, preventing tag mutability attacks.

Why this answer

Using the image digest (SHA256) provides a cryptographic hash of the image manifest, ensuring that the exact same image content is pulled every time, regardless of tag changes. This prevents tag mutability attacks where a malicious actor could overwrite a tag with a compromised image. The digest is immutable and uniquely identifies the image content.

Exam trap

The CNCF exam often tests the distinction between integrity verification (cryptographic guarantees) and security scanning or metadata generation, leading candidates to confuse vulnerability scanning or SBOM generation with integrity checks.

Full explanation →

786

MCQmedium

A security policy requires that all pods drop ALL Linux capabilities and disable privilege escalation. Which YAML snippet correctly implements this in the pod's security context?

A.securityContext: privileged: false capabilities: drop: ["ALL"]

B.securityContext: allowPrivilegeEscalation: false capabilities: add: ["NET_ADMIN"]

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

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

AnswerD

Correctly sets both fields.

Why this answer

It explicitly drops all Linux capabilities with `capabilities: drop: ["ALL"]` and disables privilege escalation with `allowPrivilegeEscalation: false`. This satisfies the security policy requirement to remove all capabilities and prevent any process from gaining more privileges than its parent, which is essential for minimizing container breakout risks.

Exam trap

A common Kubernetes exam trap is the distinction between `privileged: false` (which does not drop capabilities) and explicitly dropping capabilities with `drop: ["ALL"]`, leading candidates to mistakenly think setting `privileged: false` is sufficient to remove all capabilities.

How to eliminate wrong answers

Option A is wrong because setting `privileged: false` is the default and does not drop any capabilities; it only ensures the container is not running in privileged mode, but capabilities remain intact. Option B is wrong because it adds `NET_ADMIN` capability instead of dropping all capabilities, and while it disables privilege escalation, it violates the requirement to drop ALL capabilities. Option C is wrong because it drops all capabilities but omits `allowPrivilegeEscalation: false`, leaving the container vulnerable to privilege escalation via SUID binaries or other mechanisms, which the policy explicitly requires to be disabled.

Full explanation →

787

MCQmedium

A security team wants to ensure that all communication between the kubelet and the API server is encrypted. Which flag must be set on the kubelet to enforce this?

A.--tls-cert-file

B.--node-status-update-frequency

C.--kubeconfig

D.--require-kubeconfig

AnswerC

The kubeconfig file contains the API server address with HTTPS.

Why this answer

The `--kubeconfig` flag on the kubelet specifies the path to a kubeconfig file that contains the credentials and server address for the API server. When this flag is set, the kubelet uses TLS to authenticate and encrypt all communication with the API server, as the kubeconfig file typically references an HTTPS endpoint and includes client certificates or tokens. Without this flag, the kubelet may fall back to insecure or unencrypted connections, violating the requirement for encrypted communication.

Exam trap

The trap here is that candidates often confuse `--tls-cert-file` (which secures the kubelet's own server) with the flag that secures outbound kubelet-to-API-server communication, leading them to pick Option A instead of the correct `--kubeconfig`.

How to eliminate wrong answers

Option A is wrong because `--tls-cert-file` specifies the certificate file for the kubelet's own TLS server (used when serving its metrics or health endpoints), not for encrypting outbound communication to the API server. Option B is wrong because `--node-status-update-frequency` controls how often the kubelet posts node status to the API server, but has no effect on encryption of the communication channel. Option D is wrong because `--require-kubeconfig` is a deprecated flag that caused the kubelet to exit if no kubeconfig was provided, but it does not itself enforce encryption; the actual encryption is enforced by the presence and content of the kubeconfig file referenced by `--kubeconfig`.

Full explanation →

788

MCQmedium

You suspect a container has been compromised and want to perform forensics using kubectl exec. Which command safely collects the container's process list without affecting the container?

A.kubectl attach <pod>

B.kubectl exec <pod> -- ps aux

C.kubectl cp /proc <pod>:/tmp

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

AnswerB

This runs ps aux non-interactively, collecting process list without modifying the container.

Why this answer

kubectl exec with -- ps aux runs the ps command inside the container, capturing processes without altering the container state.

Full explanation →

789

MCQeasy

Which container runtime is specifically designed for sandboxing containers with a lightweight kernel?

A.Docker

B.containerd

C.gVisor (runsc)

D.runc

AnswerC

gVisor implements a user-space kernel for sandboxing.

Why this answer

gVisor (runsc) is a container runtime that provides a lightweight kernel written in Go, which intercepts system calls from the container and handles them in user space. This creates a strong sandbox between the container and the host kernel, making it specifically designed for sandboxing containers with a lightweight kernel, unlike standard runtimes that share the host kernel directly.

Exam trap

The CNCF CKS exam often tests the distinction between container runtimes that share the host kernel (like runc) and those that provide an additional isolation layer (like gVisor or Kata Containers), and candidates mistakenly pick containerd or Docker because they are more familiar names, not realizing they lack the lightweight kernel sandboxing feature.

How to eliminate wrong answers

Option A (Docker) is wrong because Docker is a container platform that uses runc by default and does not provide its own sandboxing kernel; it relies on the host kernel directly. Option B (containerd) is wrong because containerd is a container runtime manager that manages the container lifecycle but delegates execution to lower-level runtimes like runc, and does not include a lightweight kernel for sandboxing. Option D (runc) is wrong because runc is the standard OCI-compliant runtime that creates containers using the host kernel directly, without any additional sandboxing or lightweight kernel layer.

Full explanation →

790

Multi-Selecthard

You are securing a cluster and want to ensure that service account tokens are not automatically mounted in pods that do not need them. Which THREE actions should you take?

Select 3 answers

A.Set --service-account-lookup=false on the API server

B.Set automountServiceAccountToken: false in the service account definition for service accounts that do not need tokens

C.Audit all service accounts to determine which ones need token mounting disabled

D.Set automountServiceAccountToken: false in the pod spec for each pod that does not need the token

E.Delete all service accounts except those used by system components

AnswersB, C, D

Correct. This disables mounting for all pods using that service account.

Why this answer

Setting `automountServiceAccountToken: false` in the service account definition prevents the automatic mounting of the service account token into any pod that uses that service account. This is a declarative, scalable approach to disable token mounting for all pods associated with that service account, aligning with the principle of least privilege.

Exam trap

The trap here is that candidates often confuse `automountServiceAccountToken: false` with deleting service accounts or disabling token validation, when the correct approach is to disable mounting at the service account or pod level, not to remove accounts or alter API server flags.

Full explanation →

791

MCQeasy

You are using crictl to debug a container. Which command lists all running containers on the node?

A.crictl containers

B.crictl ps

C.crictl get pods

D.crictl list

AnswerB

Correct. crictl ps lists containers.

Why this answer

`crictl ps` is the command used to list running containers on a node when using the CRI (Container Runtime Interface) compatible runtimes like containerd or CRI-O. It mirrors the Docker `docker ps` syntax and shows only running containers by default, which is exactly what the question asks for.

Exam trap

The trap here is that candidates familiar with Docker might expect `crictl containers` to work, but `crictl` deliberately uses `ps` to align with Docker's command syntax, and `crictl list` is not a valid command at all.

How to eliminate wrong answers

Option A is wrong because `crictl containers` is not a valid command; the correct command to list containers is `crictl ps`. Option C is wrong because `crictl get pods` is used to list pods, not individual containers, and it is a command from `kubectl`, not `crictl`. Option D is wrong because `crictl list` is not a valid command; the correct command is `crictl ps`.

Full explanation →

792

MCQhard

You need to ensure a container's filesystem is immutable at runtime except for a temporary volume. Which Pod spec configuration achieves this?

A.containers: - name: app securityContext: runAsNonRoot: true volumeMounts: - mountPath: /tmp name: scratch volumes: - name: scratch emptyDir: {}

B.containers: - name: app securityContext: readOnlyRootFilesystem: true volumeMounts: - mountPath: /tmp name: scratch volumes: - name: scratch emptyDir: {}

C.containers: - name: app securityContext: readOnlyRootFilesystem: false

D.containers: - name: app securityContext: readOnlyRootFilesystem: true volumeMounts: - mountPath: /tmp name: scratch volumes: - name: scratch hostPath: path: /tmp

AnswerB

readOnlyRootFilesystem makes rootfs read-only; emptyDir provides writable tmpfs.

Why this answer

Setting `readOnlyRootFilesystem: true` in the container's securityContext makes the container's filesystem immutable at runtime, preventing any writes to the root filesystem. By mounting an `emptyDir` volume at `/tmp`, the container gets a writable temporary volume for scratch data, satisfying the requirement of a temporary writable area while keeping the rest of the filesystem read-only.

Exam trap

The CKS exam often tests the distinction between `runAsNonRoot` and `readOnlyRootFilesystem`, where candidates mistakenly think `runAsNonRoot` provides filesystem immutability, or they overlook that `hostPath` volumes are not temporary and violate the requirement for a temporary volume.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot: true` only ensures the container runs as a non-root user, but does not make the filesystem immutable; it does not prevent writes to the root filesystem. Option C is wrong because `readOnlyRootFilesystem: false` explicitly allows writes to the root filesystem, which is the opposite of the required immutability. Option D is wrong because while it sets `readOnlyRootFilesystem: true`, it uses a `hostPath` volume mounted at `/tmp` instead of an `emptyDir`; `hostPath` volumes are not temporary and can persist data on the node, violating the 'temporary volume' requirement and introducing security risks by exposing the host filesystem.

Full explanation →

793

MCQhard

An administrator applies the following manifest to enable audit logging: apiVersion: audit.k8s.io/v1 kind: Policy metadata: name: audit-policy rules: - level: Metadata resources: - group: "" resources: ["secrets"] Which audit level is being used for requests to the Secrets API?

A.RequestResponse

B.Metadata

C.Request

D.None

AnswerB

Metadata logs request metadata without request/response bodies.

Why this answer

The manifest defines an audit policy rule with `level: Metadata` for the Secrets API (group: "", resources: ["secrets"]). The Metadata level logs only the metadata of the request—such as user, timestamp, and resource—without logging the request body or response body. Therefore, the correct audit level for requests to the Secrets API is Metadata.

Exam trap

CNCF often tests the distinction between audit levels, and the trap here is that candidates may confuse Metadata with Request or RequestResponse, thinking that Secrets require logging the full request/response for security, when in fact Metadata is the recommended level to avoid exposing sensitive data in audit logs.

How to eliminate wrong answers

Option A is wrong because RequestResponse logs both the request and response bodies, which is a higher verbosity level than what is specified in the policy. Option C is wrong because Request logs the request body but not the response body, which is also not the level set in the policy. Option D is wrong because the policy explicitly sets the level to Metadata, so the audit level is not None.

Full explanation →

794

Multi-Selecthard

Which THREE of the following are valid Falco rule priorities? (Select THREE.)

Select 3 answers

A.CRITICAL

B.EMERGENCY

C.ALERT

D.HIGH

E.MEDIUM

AnswersA, B, C

Correct.

Why this answer

Falco defines a specific set of priority levels for rule output, and CRITICAL is one of the valid priorities. It is used for the most severe security events that require immediate attention, such as a container breakout attempt. The official Falco documentation lists CRITICAL as a valid priority, along with EMERGENCY and ALERT.

Exam trap

The CKS exam often tests the exact list of Falco priorities, and the trap here is that candidates may confuse common severity terms like HIGH or MEDIUM (used in other security tools) with Falco's specific, more granular priority set.

Full explanation →

795

MCQeasy

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

A.--tls-cert-file=/etc/kubernetes/pki/apiserver.crt

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

C.--anonymous-auth=false

D.--authorization-mode=RBAC

AnswerC

This flag disables anonymous authentication, ensuring all requests are authenticated.

Why this answer

The `--anonymous-auth=false` flag explicitly disables anonymous authentication on the kube-apiserver. By default, anonymous requests are allowed (the flag defaults to `true`), which can permit unauthenticated users to access the API server. Setting this flag to `false` ensures that all requests must present valid credentials, aligning with the principle of least privilege and hardening the cluster against unauthorized access.

Exam trap

CNCF often tests the distinction between authentication and authorization flags, so candidates may mistakenly choose `--authorization-mode=RBAC` (option D) thinking it controls who can access the API, when in fact it only governs what authenticated users are allowed to do, not whether anonymous users are permitted at all.

How to eliminate wrong answers

Option A is wrong because `--tls-cert-file` specifies the TLS certificate file for serving HTTPS, not authentication; it secures the transport layer but does not control whether anonymous requests are accepted. Option B is wrong because `--audit-log-path` enables audit logging to record API requests, but it does not affect authentication or disable anonymous access. Option D is wrong because `--authorization-mode=RBAC` sets the authorization mode to Role-Based Access Control, which governs what authenticated users can do, but it does not disable anonymous authentication; anonymous users could still be authorized if RBAC grants them permissions.

Full explanation →

796

Multi-Selectmedium

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

Select 2 answers

A.ResponseStarted

B.RequestReceived

C.ResponseFinished

D.RequestProcessing

E.AuthorizationChecked

AnswersA, B

Valid audit stage.

Why this answer

`ResponseStarted` is a valid audit stage in Kubernetes audit logging. It occurs when the response headers are sent, but the response body is not yet complete. This stage is useful for auditing the start of a response, especially for streaming or large responses.

Exam trap

Kubernetes often tests the exact names of Kubernetes audit stages, and the trap here is that candidates confuse `ResponseFinished` with the correct `ResponseComplete` stage, or invent stages like `RequestProcessing` or `AuthorizationChecked` that sound plausible but do not exist in the Kubernetes audit logging specification.

Full explanation →

797

MCQhard

An audit policy is configured with the following rule: - level: Metadata resources: - group: "" resources: ["secrets"] What does this rule log for requests to the Secrets API?

A.The full request and response body

B.Metadata about the request, excluding the body

C.Nothing, because secrets are excluded by default

D.The request body only

AnswerB

Correct: Metadata level logs metadata only.

Why this answer

The 'Metadata' level logs request metadata (user, timestamp, resource) but not the request or response body. Option A corresponds to the 'RequestResponse' level, which logs both request and response bodies. Option C is incorrect because secrets are not excluded by default; the rule applies to secrets.

Option D corresponds to the 'Request' level, which logs the request body only.

Full explanation →

798

MCQmedium

In an Istio service mesh, you want to enforce mutual TLS (mTLS) between all services in the 'default' namespace. Which resource should you create?

A.PeerAuthentication with mTLS mode STRICT

B.Sidecar resource with outboundTrafficPolicy REGISTRY_ONLY

C.ServiceEntry with resolution NONE

D.DestinationRule with trafficPolicy tls mode ISTIO_MUTUAL

AnswerA

PeerAuthentication sets mTLS mode; STRICT requires mTLS for all traffic.

Why this answer

To enforce mutual TLS (mTLS) between all services in the 'default' namespace, you create a PeerAuthentication resource with mTLS mode set to STRICT. This policy enforces that all traffic within the namespace must use mTLS, rejecting any plaintext connections. PeerAuthentication is the Istio resource specifically designed to define mTLS enforcement at the namespace or mesh level.

Exam trap

Istio often tests the distinction between PeerAuthentication (for mTLS enforcement) and DestinationRule (for TLS settings on outbound traffic), leading candidates to mistakenly choose DestinationRule for namespace-wide mTLS enforcement.

How to eliminate wrong answers

Option B is wrong because a Sidecar resource with outboundTrafficPolicy REGISTRY_ONLY controls which external services sidecars can reach, not mTLS enforcement. Option C is wrong because a ServiceEntry with resolution NONE is used to add external services to the mesh registry for routing, not to enforce mTLS. Option D is wrong because a DestinationRule with trafficPolicy tls mode ISTIO_MUTUAL configures TLS settings for traffic to a specific host, but it does not enforce mTLS for all services in the namespace; PeerAuthentication is the correct resource for namespace-wide mTLS enforcement.

Full explanation →

799

MCQmedium

A security audit reveals that several pods have the service account token mounted automatically. Which annotation should be added to the pod's service account to prevent automatic mounting?

A.Set 'automountServiceAccountToken: true' in the pod spec.

B.Add annotation 'seccomp.security.alpha.kubernetes.io/pod: "runtime/default"' to the service account.

C.Add annotation 'kubernetes.io/enforce-mountable-secrets: "false"' to the service account.

D.Set 'automountServiceAccountToken: false' in the service account definition.

AnswerD

Setting this field to false on the service account prevents automatic mounting of the token in pods using that service account.

Why this answer

Setting `automountServiceAccountToken: false` in the service account definition prevents pods that use that service account from automatically mounting the service account token. This is the recommended way to disable automatic token mounting at the service account level, as per Kubernetes security best practices.

Exam trap

The trap here is that candidates may confuse the `automountServiceAccountToken` field with other security mechanisms like seccomp profiles or secret mounting annotations, or mistakenly think that setting it to `true` in the pod spec would disable mounting.

How to eliminate wrong answers

Option A is wrong because setting `automountServiceAccountToken: true` in the pod spec explicitly enables automatic mounting, which is the opposite of what is needed to prevent it. Option B is wrong because the annotation `seccomp.security.alpha.kubernetes.io/pod: "runtime/default"` is used to set a seccomp profile for the pod, not to control service account token mounting. Option C is wrong because the annotation `kubernetes.io/enforce-mountable-secrets: "false"` does not exist; the correct annotation for controlling secret mounting is `kubernetes.io/enforce-mountable-secrets` but it is used to restrict which secrets can be mounted, not to disable automatic service account token mounting.

Full explanation →

800

MCQmedium

Which of the following is the correct way to disable swap on a Kubernetes node to improve security?

A.Run 'swapoff -a' and remove swap entry from /etc/fstab

B.Set kernel parameter 'vm.swappiness=0'

C.Run 'systemctl stop swap'

D.Run 'kubelet --disable-swap'

AnswerA

This disables swap immediately and permanently.

Why this answer

Disabling swap is a prerequisite for Kubernetes nodes to ensure kubelet works correctly with memory management and resource isolation. Running 'swapoff -a' disables all active swap devices immediately, and removing the swap entry from /etc/fstab prevents swap from being re-enabled after a reboot. This is the standard and complete method recommended by Kubernetes documentation for system hardening.

Exam trap

The trap here is that candidates may think 'vm.swappiness=0' is sufficient to disable swap, but it only minimizes swap usage without actually turning it off, which still violates Kubernetes node requirements.

How to eliminate wrong answers

Option B is wrong because setting 'vm.swappiness=0' only reduces the kernel's tendency to use swap but does not disable it; swap remains active and can still be used, which can cause kubelet instability. Option C is wrong because 'systemctl stop swap' is not a valid systemd command; swap is managed via 'swapoff' or systemd swap units (e.g., 'systemctl stop dev-sda1.swap'), but the generic 'swap' service does not exist. Option D is wrong because 'kubelet --disable-swap' is not a valid kubelet flag; kubelet does not have a built-in option to disable swap, and swap must be disabled at the OS level before starting kubelet.

Full explanation →

801

Multi-Selecthard

Which THREE of the following are valid methods to restrict access to the Kubernetes Dashboard? (Choose three.)

Select 3 answers

A.Use a ClusterIP service and only allow access via kubectl proxy

B.Expose the Dashboard via a NodePort service to the internet

C.Use an Ingress with authentication and TLS

D.Apply RBAC policies that restrict who can access the Dashboard

E.Deploy the Dashboard with a hostNetwork: true configuration

AnswersA, C, D

By using a ClusterIP service and kubectl proxy, access is limited to users who have kubectl and cluster access.

Why this answer

Using a ClusterIP service restricts the Dashboard to internal cluster access only. Access is then granted exclusively through `kubectl proxy`, which creates a local proxy server that authenticates the user via their kubeconfig context, ensuring that only authenticated and authorized users can reach the Dashboard without exposing it to the network.

Exam trap

CNCF often tests the misconception that exposing a service via NodePort or hostNetwork is acceptable for internal-only access, when in fact both methods inherently expose the service to the node's network and require additional security measures to restrict access.

Full explanation →

802

MCQmedium

You are tasked with enabling audit logging for the Kubernetes API server. You have created an audit policy file at /etc/kubernetes/audit-policy.yaml. Which flag must be added to the API server manifest to enable audit logging?

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

B.--audit-log-level=2

C.--enable-audit-log

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

AnswerD

This flag enables audit logging by specifying the output file.

Why this answer

The `--audit-log-path` flag is required to enable audit logging in the Kubernetes API server. Without specifying a log path, the API server will not write audit events to a file, even if an audit policy is defined. The `--audit-policy-file` flag (Option A) defines the rules for what to audit, but audit logging itself is only activated when a log destination is provided via `--audit-log-path`.

Exam trap

CNCF often tests the misconception that `--audit-policy-file` alone enables audit logging, but the trap is that the log destination flag (`--audit-log-path`) is mandatory to actually start writing audit events.

How to eliminate wrong answers

Option A is wrong because `--audit-policy-file` only specifies the policy file that defines which events to audit; it does not enable the writing of audit logs. Option B is wrong because `--audit-log-level` is not a valid Kubernetes API server flag; audit log verbosity is controlled by the policy file, not a command-line level. Option C is wrong because `--enable-audit-log` is not a real flag; audit logging is enabled implicitly by providing a log path and policy file.

Full explanation →

803

MCQhard

A security scanner reports that the Kubernetes dashboard is publicly accessible. Which recommended action should be taken?

A.Expose the dashboard as a NodePort service for easy access

B.Configure firewall rules to restrict access to the dashboard's ClusterIP

C.Enable authentication on the dashboard

D.Delete the dashboard deployment and use kubectl proxy to access it

AnswerD

kubectl proxy provides secure local access. Deleting the dashboard or restricting its service is recommended.

Why this answer

The Kubernetes Dashboard is a powerful administrative tool that should never be exposed to the public internet. Deleting the dashboard deployment and using `kubectl proxy` to access it locally is the recommended action because it eliminates the attack surface entirely and ensures that access is restricted to the machine running the kubectl command, leveraging the API server's built-in authentication and authorization.

Exam trap

CNCF often tests the misconception that adding authentication or network restrictions is sufficient to secure an exposed dashboard, when the correct answer is to remove the public-facing component and use a secure, authenticated proxy method like `kubectl proxy`.

How to eliminate wrong answers

Option A is wrong because exposing the dashboard as a NodePort service makes it accessible on every node's IP address at a high port, which directly contradicts the goal of restricting public access and increases the attack surface. Option B is wrong because configuring firewall rules to restrict access to the dashboard's ClusterIP is ineffective; ClusterIP is only reachable from within the cluster, so the scanner's report of public accessibility indicates the dashboard is already exposed via a different service type (e.g., LoadBalancer or NodePort), and firewall rules on ClusterIP do not address the actual exposure. Option C is wrong because enabling authentication on the dashboard does not prevent public network-level access; the dashboard would still be reachable from the internet, and authentication alone does not protect against denial-of-service attacks or unauthorized network scanning.

Full explanation →

804

MCQeasy

Which of the following is the correct annotation to apply an AppArmor profile named 'my-profile' to a container named 'app' in a pod?

A.security.alpha.kubernetes.io/apparmor/app: localhost/my-profile

B.container.apparmor.security.beta.kubernetes.io/app: localhost/my-profile

C.pod.apparmor.security.beta.kubernetes.io/app: my-profile

D.container.apparmor.security.beta.kubernetes.io/app: my-profile

AnswerB

Correct. The annotation key targets the container, and the value includes the profile name with 'localhost/' prefix.

Why this answer

The AppArmor profile annotation for a container must follow the format `container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_name>`. This annotation is in the `security.beta.kubernetes.io` API group (beta, not alpha) and targets the specific container by name. The value must include the `localhost/` prefix to indicate a profile loaded on the node, not a built-in or default profile.

Exam trap

CNCF often tests the exact annotation format, specifically the `localhost/` prefix and the `security.beta.kubernetes.io` API group, to catch candidates who confuse AppArmor with Seccomp (which uses `security.alpha.kubernetes.io/seccomp`) or who forget the per-container targeting.

How to eliminate wrong answers

Option A is wrong because it uses the `security.alpha.kubernetes.io` prefix, which is an older, deprecated API group for AppArmor; the correct group is `security.beta.kubernetes.io`. Option C is wrong because it uses `pod.apparmor.security.beta.kubernetes.io`, which is not a valid annotation key; AppArmor annotations are per-container, not per-pod. Option D is wrong because it omits the required `localhost/` prefix in the value; the profile name must be specified as `localhost/my-profile` to reference a locally loaded profile, not just `my-profile`.

Full explanation →

805

MCQeasy

Which of the following is a static analysis tool for Kubernetes manifests that can identify security misconfigurations?

A.Clair

B.kubesec

C.OPA/Gatekeeper

D.Notary

AnswerB

kubesec performs static analysis of Kubernetes YAML files to identify security risks.

Why this answer

kubesec is a static analysis tool that scans Kubernetes manifests (YAML/JSON) and assigns a security score based on misconfigurations such as running containers as root, missing resource limits, or allowing privilege escalation. It operates offline without requiring a running cluster, making it a pure static analysis tool for identifying security issues in manifests before deployment.

Exam trap

The CKS exam often tests the distinction between static analysis (scanning files offline) and dynamic/runtime enforcement (admission controllers), leading candidates to mistakenly choose OPA/Gatekeeper for static scanning when it is actually a runtime policy engine.

How to eliminate wrong answers

Option A is wrong because Clair is a static analysis tool for container images, not Kubernetes manifests; it scans layers for known vulnerabilities (CVEs) in OS packages and libraries. Option C is wrong because OPA/Gatekeeper is a dynamic admission controller that enforces policies at runtime when resources are created or updated, not a static analysis tool for manifests. Option D is wrong because Notary is a tool for signing and verifying container image artifacts to ensure supply chain integrity, not for scanning Kubernetes manifest configurations.

Full explanation →

806

MCQeasy

What is the primary purpose of using a service mesh like Istio for microservices security?

A.To replace Kubernetes NetworkPolicies for network segmentation.

B.To provide a centralized logging solution.

C.To automatically scale pods based on CPU usage.

D.To provide mTLS communication between services for encrypted and authenticated traffic.

AnswerD

One of the main features of a service mesh is to enable mTLS between services transparently.

Why this answer

The primary purpose of a service mesh like Istio for microservices security is to enforce mutual TLS (mTLS) between services, ensuring that all inter-service communication is both encrypted and authenticated. This is achieved by injecting sidecar proxies (Envoy) that handle TLS termination and certificate management transparently, without requiring changes to application code.

Exam trap

The CKS exam often tests the distinction between network-layer controls (NetworkPolicies) and service-mesh-layer controls (mTLS), so the trap here is that candidates confuse Istio's role in network segmentation with its actual purpose of securing service-to-service communication via encrypted and authenticated mTLS.

How to eliminate wrong answers

Option A is wrong because Istio does not replace Kubernetes NetworkPolicies; it operates at Layer 7 (application) for traffic management and security, while NetworkPolicies work at Layer 3/4 (network) for basic ingress/egress rules, and both can coexist. Option B is wrong because Istio provides observability (metrics, traces, logs) via its telemetry features, but its primary security purpose is not centralized logging; tools like Fluentd or Elasticsearch are dedicated to that. Option C is wrong because pod autoscaling based on CPU usage is handled by Kubernetes HorizontalPodAutoscaler (HPA), not by Istio, which focuses on traffic routing, security, and observability.

Full explanation →

807

MCQeasy

You need to configure the Kubernetes API server to enable audit logging at the 'Metadata' level for all requests. Which flag should be used when starting the kube-apiserver?

A.--feature-gates=Auditing=true

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

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

D.--audit-log-maxsize=100

AnswerC

Correct. The audit policy file is required to enable audit logging and define levels.

Why this answer

Audit logging is enabled by specifying --audit-policy-file pointing to a policy file. The policy file defines the level. The flag itself is --audit-policy-file.

Full explanation →

808

MCQhard

You are tasked with creating a Kubernetes admission controller that validates image signatures before allowing pods to run. Which admission controller should you configure?

A.ImagePolicyWebhook

B.MutatingAdmissionWebhook

C.ValidatingAdmissionWebhook

D.NodeRestriction

AnswerA

ImagePolicyWebhook is an admission controller specifically for image policy validation, often used with image signing.

Why this answer

The ImagePolicyWebhook admission controller is specifically designed to validate container image signatures against an external policy engine (e.g., OPA, Sigstore) before a pod is admitted. It intercepts pod creation requests and sends the image metadata to a webhook endpoint, which returns an allow/deny decision based on signature verification. This directly addresses the requirement to enforce image signature validation as part of supply chain security.

Exam trap

The trap here is that candidates often confuse ValidatingAdmissionWebhook (a generic validation tool) with ImagePolicyWebhook (the specific controller for image signature validation), but the CKS exam expects you to know the exact admission controller designed for this supply chain security use case.

How to eliminate wrong answers

Option B (MutatingAdmissionWebhook) is wrong because it modifies objects (e.g., injecting sidecars) but does not inherently validate image signatures; it could be used to call an external service, but the question specifically asks for the admission controller that validates image signatures, and ImagePolicyWebhook is the dedicated controller for that purpose. Option C (ValidatingAdmissionWebhook) is wrong because while it can validate arbitrary policies, it is a generic webhook and not the specific controller designed for image signature validation; the ImagePolicyWebhook is the correct choice as it is purpose-built for this task. Option D (NodeRestriction) is wrong because it limits node kubelet permissions (e.g., preventing modification of pods on other nodes) and has no role in image signature validation.

Full explanation →

809

Multi-Selecthard

Which THREE of the following are recommended practices for hardening RBAC in a Kubernetes cluster? (Select 3)

Select 3 answers

A.Use the default service account in each namespace with cluster-admin.

B.Regularly audit ClusterRoleBindings and RoleBindings for over-privileged subjects.

C.Grant only the minimum permissions necessary for each subject.

D.Avoid binding cluster-admin to service accounts unless absolutely necessary.

E.Use RoleBindings with ClusterRoles in the same namespace to increase security.

AnswersB, C, D

Auditing helps identify and reduce excessive permissions.

Why this answer

Regular auditing of ClusterRoleBindings and RoleBindings helps identify over-privileged subjects, such as service accounts or users with excessive permissions, which is a key hardening practice. This aligns with the principle of least privilege and is recommended by Kubernetes security best practices to reduce the attack surface.

Exam trap

CNCF often tests the misconception that using RoleBindings with ClusterRoles is always more secure, but the trap here is that ClusterRoles can contain cluster-scoped permissions that are not namespace-restricted, potentially granting broader access than intended if not carefully reviewed.

Full explanation →

810

MCQeasy

Which command correctly creates a secret from a file named 'config.json'?

A.kubectl create configmap my-secret --from-file=config.json

B.kubectl create secret generic my-secret --from-file=config.json

C.kubectl create secret tls my-secret --cert=config.json

D.kubectl create secret generic my-secret --from-literal=config.json

AnswerB

Correct. This creates a secret named my-secret with the file contents as the value, key defaults to 'config.json'.

Why this answer

`kubectl create secret generic` with `--from-file=config.json` reads the file content and stores it as a key-value pair in the Secret, where the key defaults to the filename ('config.json') and the value is the raw file data. This is the standard method for creating a generic Secret from a file in Kubernetes.

Exam trap

The CKS exam often tests the confusion between `--from-file` and `--from-literal`, where candidates mistakenly use `--from-literal` with a filename, expecting it to read the file, or confuse `kubectl create secret generic` with `kubectl create configmap` for storing sensitive data.

How to eliminate wrong answers

Option A is wrong because `kubectl create configmap` creates a ConfigMap, not a Secret, which stores data in plain text without base64 encoding or the security context of a Secret. Option C is wrong because `kubectl create secret tls` expects a TLS certificate and key pair (typically `--cert` and `--key` flags pointing to PEM files), not a JSON configuration file; using `--cert=config.json` would misinterpret the JSON as a certificate. Option D is wrong because `--from-literal` expects a key=value string directly on the command line (e.g., `--from-literal=key=value`), not a filename; passing `--from-literal=config.json` would treat 'config.json' as a literal key with no value, failing to read the file.

Full explanation →

811

Multi-Selecthard

Which THREE of the following are required when setting up a Kubernetes control plane with kubeadm for a production environment?

Select 3 answers

A.Ensure the Kubernetes version is not downgraded

B.Specify --pod-network-cidr to define the pod network range

C.Specify --control-plane-endpoint for high availability

D.Specify --apiserver-advertise-address

E.Generate a bootstrap token with kubeadm token create

AnswersA, B, C

kubeadm prevents downgrading.

Why this answer

Kubeadm enforces a strict version skew policy: the kubelet version must not be newer than the control plane version, and downgrading the control plane (e.g., from v1.28 to v1.27) is not supported. Attempting a downgrade can lead to API version mismatches, schema incompatibilities, and cluster instability. In production, you must plan upgrades carefully and never downgrade the control plane components.

Exam trap

CNCF often tests the misconception that --apiserver-advertise-address is mandatory for all control plane setups, but it is only needed when the node has multiple network interfaces or you need to override the default IP detection.

Full explanation →

812

MCQmedium

A cluster administrator wants to enforce Pod Security Standards at the namespace level using the built-in PodSecurity admission controller. The namespace 'test' should reject any pod that violates the 'baseline' level. Which command applies this correctly?

A.kubectl annotate ns test pod-security.kubernetes.io/enforce-version=baseline

B.kubectl label ns test pod-security.kubernetes.io/enforce=baseline

C.kubectl label ns test pod-security.kubernetes.io/warn=baseline

D.kubectl label ns test pod-security.kubernetes.io/audit=baseline

AnswerB

This label enforces the baseline Pod Security Standard on the namespace.

Why this answer

The PodSecurity admission controller uses the label `pod-security.kubernetes.io/enforce` to enforce the specified Pod Security Standard (e.g., `baseline`) at the namespace level. Pods that violate the enforced level are rejected by the admission controller. The `enforce` label triggers the admission webhook to block non-compliant pods, which matches the requirement to reject violations.

Exam trap

CNCF often tests the distinction between the three Pod Security Standard modes (`enforce`, `warn`, `audit`) and the fact that only `enforce` actually blocks pods, while `warn` and `audit` are non-blocking; candidates frequently confuse `warn` or `audit` with enforcement.

How to eliminate wrong answers

Option A is wrong because it uses `kubectl annotate` with the key `pod-security.kubernetes.io/enforce-version`, which is not a valid label for enforcement; the correct key is `pod-security.kubernetes.io/enforce`, and it must be set as a label, not an annotation. Option C is wrong because `pod-security.kubernetes.io/warn=baseline` only generates a warning for violations but does not reject the pod, so it does not meet the requirement to reject violations. Option D is wrong because `pod-security.kubernetes.io/audit=baseline` only logs violations in the audit log without rejecting or warning, which also fails to enforce rejection.

Full explanation →

813

MCQmedium

A security auditor runs kube-bench on your cluster and reports that the apiserver is using default service account tokens. Which admission plugin should be enabled to address this?

A.DefaultStorageClass

B.PodSecurity

C.NodeRestriction

D.ServiceAccount

AnswerB

PodSecurity (or legacy PodSecurityPolicy) can enforce policies that require automountServiceAccountToken: false.

Why this answer

(PodSecurity) because the PodSecurity admission plugin (replacing the deprecated PodSecurityPolicy) enforces a restricted security context on pods, preventing them from automatically mounting the default service account token. By default, Kubernetes mounts a service account token into every pod, which can be exploited if an attacker gains access to a pod. Enabling PodSecurity with a policy that restricts automounting of service account tokens addresses the kube-bench finding.

Exam trap

The trap here is that candidates often confuse the ServiceAccount admission plugin (which handles token creation) with the PodSecurity plugin (which enforces restrictions on token mounting), leading them to select D instead of B.

How to eliminate wrong answers

Option A is wrong because DefaultStorageClass is an admission plugin that sets a default storage class for PersistentVolumeClaims, not related to service account token security. Option C is wrong because NodeRestriction limits the Node API permissions for kubelets, preventing them from modifying pods or secrets on other nodes, but does not control service account token mounting. Option D is wrong because ServiceAccount is an admission plugin that handles service account creation and token binding, but it does not enforce restrictions on automatic token mounting; in fact, it is the plugin that enables the default behavior of mounting tokens.

Full explanation →

814

MCQmedium

Refer to the exhibit. The pod fails to start with the error 'container has runAsNonRoot but image will run as root'. Which change would fix the issue?

A.Set runAsNonRoot: false

B.Change runAsUser to 0

C.Use a different image that runs as non-root

D.Add NET_ADMIN capability

AnswerA

Removes the non-root requirement, allowing the image to run as root.

Why this answer

The error 'container has runAsNonRoot but image will run as root' occurs because the Pod's security context sets `runAsNonRoot: true`, but the container image is configured to run as root (UID 0). Setting `runAsNonRoot: false` removes the enforcement, allowing the container to run as root as the image expects. This directly resolves the conflict between the security context constraint and the image's default user.

Exam trap

CNCF often tests the misconception that you must change the image or add capabilities to fix a `runAsNonRoot` violation, when in fact the simplest fix is to adjust the security context setting to match the image's behavior.

How to eliminate wrong answers

Option B is wrong because changing `runAsUser` to 0 explicitly sets the container to run as root, which still violates the `runAsNonRoot: true` constraint and would produce the same error. Option C is wrong because while using a different image that runs as non-root would technically fix the issue, it is not the only or most direct change; the question asks which change would fix the issue, and modifying the security context is a simpler, valid approach. Option D is wrong because adding `NET_ADMIN` capability does not affect the user ID the container runs as; it only grants network administration privileges and does not address the root/non-root mismatch.

Full explanation →

815

MCQeasy

Which admission plugin should be enabled on the kube-apiserver to enforce that kubelets cannot modify nodes they are not assigned to?

A.AlwaysPullImages

B.NodeSelector

C.PodSecurity

D.NodeRestriction

AnswerD

NodeRestriction ensures kubelets can only modify their own node objects.

Why this answer

The NodeRestriction admission plugin ensures that kubelets can only modify their own Node API objects and pods bound to them. When enabled, it prevents a kubelet from modifying nodes it is not assigned to, enforcing the principle of least privilege and limiting the blast radius of a compromised kubelet.

Exam trap

The trap here is that candidates confuse admission plugins that control pod behavior (like PodSecurity or AlwaysPullImages) with those that restrict kubelet actions, or they mistakenly think NodeSelector is a security control rather than a scheduling feature.

How to eliminate wrong answers

Option A is wrong because AlwaysPullImages forces every pod to pull container images from the registry on each start, but it does not restrict kubelet actions on nodes. Option B is wrong because NodeSelector is a scheduling constraint that limits which nodes a pod can run on, not a mechanism to control kubelet node modifications. Option C is wrong because PodSecurity (formerly PodSecurityPolicy) enforces security contexts on pods, such as privilege escalation or host namespace usage, but does not regulate kubelet behavior regarding node objects.

Full explanation →

816

MCQmedium

You need to run a container with a sandboxed runtime using gVisor (runsc). Which Kubernetes resource must be created first to enable this?

A.A RuntimeClass resource with handler: runsc

B.A PodSecurityPolicy that allows the runsc runtime

C.A ValidatingWebhookConfiguration to validate the runtime

D.A priorityClass with a high priority

AnswerA

RuntimeClass defines the container runtime to use for pods.

Why this answer

A RuntimeClass resource is required to define a container runtime configuration that uses gVisor (runsc). When you create a RuntimeClass with handler: runsc, you can then reference it in a Pod spec via the runtimeClassName field, which instructs the kubelet to use the runsc runtime instead of the default runc. This is the foundational step to enable sandboxed runtime isolation for containers.

Exam trap

A common misconception is that runtime selection is done via PodSecurityPolicy or admission webhooks, when in fact it requires a dedicated RuntimeClass resource that maps to a runtime handler configured in the container runtime (e.g., containerd).

How to eliminate wrong answers

Option B is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) controls security context constraints, not runtime selection; it cannot enable a specific runtime like runsc. Option C is wrong because a ValidatingWebhookConfiguration is used to intercept and validate API requests (e.g., enforcing policies), not to configure or enable a container runtime. Option D is wrong because a PriorityClass sets scheduling priority for pods, which has no effect on which container runtime is used.

Full explanation →

817

MCQmedium

An administrator runs kubectl get clusterrolebindings and sees a binding named 'system:node'. This binding is part of the legacy node authorization. According to CIS benchmarks, what should be done with it?

A.Delete it and rely on NodeRestriction and Node authorizer

B.Modify the role to include only necessary permissions

C.Keep it as it is required for cluster functionality

D.Add a condition to limit it to read-only

AnswerA

CIS recommends removing the system:node binding and using NodeRestriction.

Why this answer

The 'system:node' ClusterRoleBinding is a legacy binding that grants the 'system:node' cluster role to all nodes, effectively bypassing the Node Authorizer and NodeRestriction admission plugin. The CIS Benchmark for Kubernetes (section 5.1.1) recommends deleting this binding because it allows nodes to have broad, unrestricted access to the API server, which undermines the principle of least privilege. Instead, the Node Authorizer and NodeRestriction plugin should be used to enforce fine-grained, node-specific permissions based on the node's identity and the pods it runs.

Exam trap

The trap here is that candidates may think the 'system:node' binding is essential for node-to-API-server communication, but in reality, the Node Authorizer and NodeRestriction plugin handle this securely, making the legacy binding a security risk that should be removed.

How to eliminate wrong answers

Option B is wrong because modifying the role to include only necessary permissions does not address the fundamental issue: the binding itself grants the 'system:node' role to all nodes, which is a legacy mechanism that bypasses the Node Authorizer; the correct action is to delete the binding entirely and rely on the Node Authorizer. Option C is wrong because the binding is not required for cluster functionality; modern Kubernetes clusters use the Node Authorizer and NodeRestriction plugin to manage node permissions, making this legacy binding obsolete and a security risk. Option D is wrong because adding a read-only condition does not solve the problem; the binding still grants broad access to all nodes, and the Node Authorizer provides more granular, dynamic permissions based on the node's identity and the pods it runs, which is the recommended approach.

Full explanation →

818

MCQeasy

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

A.Run containers as root to ensure all permissions are available

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

C.Use distroless base images to minimize the attack surface

D.Embed secrets directly in the Dockerfile for easy access

AnswerC

Distroless images contain only essential components, reducing the number of potential vulnerabilities.

Why this answer

Distroless base images contain only the application and its runtime dependencies, omitting package managers, shells, and other utilities that could be exploited. This dramatically reduces the attack surface and aligns with the principle of least functionality, making it a best practice for securing container images in Kubernetes environments.

Exam trap

A common trap in the CKS exam is the belief that using the 'latest' tag for base images is safe because it provides the newest security patches. However, 'latest' is mutable and can introduce breaking changes or vulnerabilities without version pinning, violating supply chain security best practices.

How to eliminate wrong answers

Option A is wrong because running containers as root violates the principle of least privilege; if the container is compromised, an attacker gains root access to the container and potentially the host via kernel vulnerabilities. Option B is wrong because using the 'latest' tag introduces unpredictability and breaks reproducibility; the image may change without notice, potentially pulling a vulnerable or malicious version. Option D is wrong because embedding secrets directly in a Dockerfile exposes them in the image layers, making them accessible to anyone who can pull the image, and they persist in the image history even if later removed.

Full explanation →

819

MCQhard

You are asked to ensure that a specific Kubernetes dashboard (e.g., kubernetes-dashboard) is not publicly accessible. The dashboard is deployed in the 'kube-system' namespace. Which NetworkPolicy should you apply?

A.NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Ingress], ingress: [{from: [{namespaceSelector: {matchLabels: {}}}]}]

B.NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Ingress], ingress: []

C.NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Ingress], ingress: [{from: [{podSelector: {matchLabels: {app: kubernetes-dashboard}}}]}]

D.NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Egress], egress: [{to: [{podSelector: {}}]}]

AnswerB

An empty ingress list with Ingress policy type denies all ingress traffic.

Why this answer

A NetworkPolicy with an empty `ingress` array (i.e., `ingress: []`) explicitly denies all inbound traffic to the selected pods. This ensures that the kubernetes-dashboard pod in the kube-system namespace is not publicly accessible, as no ingress rules are defined to allow any source. By default, if no NetworkPolicy selects a pod, all traffic is allowed; applying this policy changes the default to deny for ingress.

Exam trap

The trap here is that candidates often think an empty `ingress: []` means 'no restriction' (like an empty allow list) or confuse it with omitting the `ingress` field entirely, but in NetworkPolicy, an empty array explicitly denies all ingress traffic, while omitting the field leaves the default allow behavior unchanged.

How to eliminate wrong answers

Option A is wrong because it uses `namespaceSelector: {matchLabels: {}}` which matches all namespaces (since an empty label selector matches everything), effectively allowing traffic from any namespace, thus not restricting public access. Option C is wrong because it allows ingress only from pods with the same label `app: kubernetes-dashboard`, which would permit traffic from other dashboard pods (e.g., replicas) but still denies external traffic; however, the goal is to deny all ingress, and this rule still allows some internal traffic, which is not the strictest deny. Option D is wrong because it defines an Egress policy (controlling outbound traffic) instead of an Ingress policy, and it allows egress to all pods (`podSelector: {}`), which does not address inbound access to the dashboard.

Full explanation →

820

MCQmedium

A security auditor requires that all pods in a cluster must not run as root. Which Pod Security Standard (PSS) and enforcement mode should be applied at the namespace level?

A.Baseline profile with enforce mode

B.Restricted profile with enforce mode

C.Baseline profile with warn mode

D.Privileged profile with audit mode

AnswerB

The Restricted profile requires runAsNonRoot: true, which prevents pods from running as root. Enforce mode rejects non-compliant pods.

Why this answer

The Restricted profile is the only Pod Security Standard that prohibits running containers as root by enforcing the 'MustRunAsNonRoot' security context constraint. Applying it in 'enforce' mode ensures that any pod violating this rule is immediately rejected at admission time, which directly meets the auditor's requirement.

Exam trap

Candidates often mistakenly think that the Baseline profile is sufficient for non-root requirements, but Baseline only blocks host-level privilege escalation and does not prevent containers from running as root. The Restricted profile explicitly requires MustRunAsNonRoot, making it the correct choice.

How to eliminate wrong answers

Option A is wrong because the Baseline profile allows running as root (it only blocks known privilege escalations like hostPID and hostNetwork), so it does not satisfy the 'must not run as root' requirement. Option C is wrong because 'warn' mode only generates a warning without blocking the pod, which fails the auditor's enforcement mandate. Option D is wrong because the Privileged profile permits unrestricted privileges including root access, and 'audit' mode merely logs violations without enforcement, both of which contradict the requirement.

Full explanation →

821

Multi-Selectmedium

Which THREE options are valid methods to secure etcd in a Kubernetes cluster?

Select 3 answers

A.Set --auto-compaction-mode=periodic

B.Enable TLS with peer and client certificates

C.Use a firewall to restrict access to etcd's port

D.Encrypt secrets at rest using EncryptionConfiguration

E.Enable RBAC authorization in etcd

AnswersB, C, D

Encrypts communication and authenticates clients.

Why this answer

Enabling TLS with peer and client certificates encrypts all communication between etcd members and between etcd and the Kubernetes API server, preventing man-in-the-middle attacks and unauthorized access. This is a fundamental security requirement for etcd in production clusters, as etcd stores all cluster state and secrets.

Exam trap

The trap here is that candidates may confuse etcd's maintenance features (like compaction) with security controls, or assume that Kubernetes RBAC extends to etcd, when in fact etcd has its own separate access control mechanisms.

Full explanation →

822

MCQmedium

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

A.Access the Dashboard using 'kubectl proxy' and never expose it publicly.

B.Expose the Dashboard via a LoadBalancer service for easy access.

C.Disable authentication for the Dashboard to simplify access.

D.Grant the Dashboard service account cluster-admin permissions.

AnswerA

kubectl proxy provides a secure way to access the Dashboard without exposing it to the network.

Why this answer

Accessing the Kubernetes Dashboard via 'kubectl proxy' is recommended because it creates a local HTTP proxy between your workstation and the API server, ensuring the Dashboard is never exposed to external networks. This approach leverages the API server's authentication and authorization mechanisms, avoiding the need to open network ports or expose the Dashboard directly, which aligns with the principle of least privilege and reduces the attack surface.

Exam trap

The trap here is that candidates often assume exposing the Dashboard via a LoadBalancer or NodePort is acceptable for convenience, but Cisco tests the understanding that the Dashboard must never be publicly accessible and should only be accessed through the API server proxy to enforce authentication and authorization.

How to eliminate wrong answers

Option B is wrong because exposing the Dashboard via a LoadBalancer service makes it publicly accessible over the internet, which violates security best practices by increasing the attack surface and potentially allowing unauthorized access. Option C is wrong because disabling authentication for the Dashboard removes all access controls, allowing anyone who can reach the Dashboard URL to perform actions with the Dashboard's service account permissions, which is a severe security risk. Option D is wrong because granting the Dashboard service account cluster-admin permissions provides unrestricted superuser access across the entire cluster, violating the principle of least privilege and enabling privilege escalation if the Dashboard is compromised.

Full explanation →

823

MCQhard

You want to ensure that kubelets only serve pods that have been scheduled by the API server. Which admission plugin should be enabled?

A.ServiceAccount

B.AlwaysPullImages

C.PodNodeSelector

D.NodeRestriction

AnswerD

This plugin restricts kubelet self-modification and ensures pods are bound to the node.

Why this answer

The NodeRestriction admission plugin limits the Node and Pod objects a kubelet can modify. When enabled, each kubelet can only create/modify pods bound to its own node, and only pods that have been scheduled by the API server (i.e., have a non-empty `spec.nodeName` set by the scheduler). This prevents a compromised kubelet from creating arbitrary pods or modifying pods on other nodes, enforcing that only the API server schedules pods.

Exam trap

The trap here is that candidates confuse admission plugins that control pod placement (like PodNodeSelector) with the plugin that restricts kubelet actions (NodeRestriction), leading them to select PodNodeSelector because it sounds related to node selection, but it does not enforce that pods are only created by the API server.

How to eliminate wrong answers

Option A is wrong because ServiceAccount is an admission plugin that enforces service account automounting and token projection, not node-level pod scheduling restrictions. Option B is wrong because AlwaysPullImages forces every pod to pull its images with credentials, which is a security measure for image integrity, not for restricting pod scheduling to API-server-scheduled pods. Option C is wrong because PodNodeSelector enforces namespace-level node selector constraints on pods, but it does not prevent a kubelet from creating or modifying pods that were not scheduled by the API server.

Full explanation →

824

Multi-Selecthard

Which THREE flags should be set on the kubelet to comply with the CIS Benchmark for worker node security?

Select 3 answers

A.--authentication-token-webhook=false

B.--read-only-port=10255

C.--anonymous-auth=false

D.--protect-kernel-defaults=true

E.--authorization-mode=Webhook

AnswersC, D, E

Disables anonymous authentication.

Why this answer

The CIS Benchmark for Kubernetes requires disabling anonymous authentication on the kubelet by setting `--anonymous-auth=false`. This ensures that all requests to the kubelet are authenticated, preventing unauthenticated access to the kubelet API, which could allow an attacker to execute commands or retrieve sensitive node information.

Exam trap

CNCF often tests the distinction between authentication and authorization flags, leading candidates to confuse `--authentication-token-webhook=false` (which weakens security) with the required `--authorization-mode=Webhook` (which strengthens it).

Full explanation →

825

MCQhard

A security audit reveals that a Deployment uses an image with a mutable tag 'app:latest'. Which change ensures the image is immutable and traceable?

A.Change tag to 'app:stable'

B.Set 'replicas: 1'

C.Use 'image: app@sha256:abc123...'

D.Add 'imagePullPolicy: Always'

AnswerC

Using a digest ensures the exact image layer is used, providing immutability.

Why this answer

Using the image digest (e.g., `image: app@sha256:abc123...`) pins the container image to an immutable, content-addressable identifier. Unlike mutable tags, the digest is a cryptographic hash of the image manifest, ensuring that every pull returns the exact same image, which is critical for traceability and supply chain security.

Exam trap

A common misconception is that using a 'stable' tag provides immutability, but in Kubernetes, any tag can be reassigned. Only the image digest (SHA256) guarantees a specific image version, ensuring traceability and supply chain security.

How to eliminate wrong answers

Option A is wrong because 'app:stable' is still a mutable tag that can be updated to point to a different image, failing to provide immutability. Option B is wrong because setting 'replicas: 1' only controls the number of Pod replicas and has no effect on image immutability or traceability. Option D is wrong because 'imagePullPolicy: Always' forces the kubelet to pull the image every time, but if the tag is mutable, it still allows the underlying image to change, and it does not pin to a specific digest.

Full explanation →

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