Certified Kubernetes Security Specialist CKS CKS Questions 76–150 | Page 2/12

MCQhard

You are tasked with reducing the attack surface on a Kubernetes node. Which of the following actions is LEAST effective for hardening the node itself?

A.Restrict SSH access to the node using firewall rules

B.Disable unnecessary system services (e.g., telnet, rsh) on the node

C.Drop the NET_RAW capability from all containers running on the node

D.Apply the latest security patches to the host kernel

AnswerC

Dropping NET_RAW restricts container capabilities, which is a pod-level control, not node hardening. Node hardening targets the host itself: kubelet flags, file permissions, kernel parameters and package updates. Capability removal leaves the underlying node configuration untouched, making it least effective here.

Why this answer

The least effective for hardening the node itself because dropping NET_RAW from containers is a container-level security control (e.g., via Pod Security Standards or seccomp), not a node-level hardening measure. Node hardening focuses on the host OS and Kubernetes components, not container capabilities. While it reduces attack surface for containers, it does not directly secure the node's kernel, services, or network access.

Exam trap

The trap here is that candidates confuse container-level security controls (like dropping capabilities) with node-level hardening, assuming any security measure applied to containers also hardens the underlying node, when in fact node hardening requires direct OS and infrastructure changes.

How to eliminate wrong answers

Option A is wrong because restricting SSH access via firewall rules directly reduces the node's network attack surface by limiting administrative access, which is a fundamental node hardening practice. Option B is wrong because disabling unnecessary services like telnet and rsh eliminates legacy, unencrypted protocols that could be exploited to compromise the node, making it a critical hardening step. Option D is wrong because applying the latest security patches to the host kernel addresses known vulnerabilities in the node's core operating system, which is essential for node-level security.

Full explanation →

MCQmedium

You are implementing supply chain security for container images. Which tool would you use to scan a local directory of Dockerfiles and Kubernetes manifests for known vulnerabilities?

A.kubectl scan

B.syft

C.cosign sign

D.trivy fs

AnswerD

trivy fs is a valid and appropriate choice because it scans local filesystem paths, including Dockerfiles and Kubernetes manifests, for vulnerabilities and misconfigurations. It parses the base image references and dependency files in those directories, then cross-references them against vulnerability databases, and also performs configuration checks for insecure settings. This makes it a comprehensive scanner for code and Infrastructure-as-Code artifacts in a supply-chain context.

Why this answer

D is correct because `trivy fs` scans a local filesystem (including directories containing Dockerfiles and Kubernetes manifests) for known vulnerabilities. It parses these files, checks base images against vulnerability databases, and detects misconfigurations or CVEs. This tool is designed for supply chain security, covering both package vulnerabilities and infrastructure-as-code issues.

The `fs` subcommand of trivy combines filesystem scanning with configuration analysis, making it suitable for the stated task.

Exam trap

The trap is that candidates might think `trivy fs` only scans packages, but it can also scan configuration files like Dockerfiles and Kubernetes manifests for vulnerabilities. The exam tests the understanding that `trivy` is a multi-purpose tool, and `fs` is the appropriate subcommand for local directory scanning, not just `trivy image`.

How to eliminate wrong answers

Option A is wrong because `kubectl scan` is not a valid kubectl subcommand; kubectl does not have a built-in vulnerability scanning feature. Option B is wrong because `syft` generates a Software Bill of Materials (SBOM) from container images or filesystems but does not scan for known vulnerabilities; it catalogs packages but lacks a vulnerability database. Option C is wrong because `cosign sign` is used for signing container images to ensure integrity and provenance, not for scanning local directories for vulnerabilities.

Full explanation →

MCQeasy

Which admission controller is responsible for validating and mutating requests based on webhooks?

A.ServiceAccount

B.PodSecurityPolicy

C.NodeRestriction

D.ValidatingAdmissionWebhook and MutatingAdmissionWebhook

AnswerD

ValidatingAdmissionWebhook and MutatingAdmissionWebhook are the admission controllers that serve as the runtime entry points for dynamic admission webhooks. MutatingAdmissionWebhook executes first to transform matching requests, then ValidatingAdmissionWebhook runs to validate them, both calling external HTTPS endpoints defined in MutatingWebhookConfiguration and ValidatingWebhookConfiguration resources. They are the specific controllers responsible for handling custom validation and mutation logic supplied by webhook servers.

Why this answer

The ValidatingAdmissionWebhook and MutatingAdmissionWebhook admission controllers are specifically designed to intercept admission requests and call external webhooks to validate or mutate the request. MutatingAdmissionWebhook can modify the object (e.g., inject sidecar containers) before it is persisted, while ValidatingAdmissionWebhook only validates and can reject the request. These controllers are the only ones that delegate admission decisions to external HTTP callbacks.

Exam trap

The exam often tests the distinction between built-in admission controllers (like PodSecurityPolicy or ServiceAccount) and webhook-based controllers, expecting candidates to know that only ValidatingAdmissionWebhook and MutatingAdmissionWebhook rely on external HTTP callbacks.

How to eliminate wrong answers

Option A is wrong because the ServiceAccount admission controller is responsible for automating the creation and binding of service accounts to pods, not for webhook-based validation or mutation. Option B is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) enforced security constraints on pod specifications via an internal admission plugin, not via external webhooks. Option C is wrong because the NodeRestriction admission controller limits the Node API access of kubelets, preventing them from modifying other nodes or secrets; it does not involve webhooks.

Full explanation →

MCQmedium

Which etcd security measure should be implemented to ensure only authorized clients can access the etcd cluster?

A.Enable anonymous authentication on etcd

B.Configure etcd to listen on localhost only

C.Enable TLS client-to-server authentication

D.Use etcd RBAC with role-based access control

AnswerC

Enabling TLS client-to-server authentication, also known as mutual TLS, requires every client to present a certificate signed by a trusted CA that etcd validates using --client-cert-auth=true and --trusted-ca-file. This ensures that only the Kubernetes API server and other explicitly trusted clients can connect, while also protecting the data in transit from eavesdropping and man-in-the-middle attacks. It is the primary authentication mechanism for etcd because it cryptographically proves the identity of each client before any request is processed.

Why this answer

Enabling TLS client-to-server authentication (mutual TLS) ensures that only clients presenting a valid certificate signed by a trusted Certificate Authority (CA) can communicate with the etcd cluster. This cryptographically verifies the client's identity, preventing unauthorized access and man-in-the-middle attacks. Without client certificate validation, any client with network access could potentially interact with etcd, compromising the Kubernetes control plane.

Exam trap

CNCF often tests the distinction between authentication (verifying identity) and authorization (controlling actions), so candidates may mistakenly choose RBAC (Option D) thinking it controls access, when in fact TLS client authentication is the prerequisite for ensuring only authorized clients can connect.

How to eliminate wrong answers

Option A is wrong because enabling anonymous authentication on etcd would allow unauthenticated clients to access the cluster, directly contradicting the requirement to restrict access to authorized clients only. Option B is wrong because configuring etcd to listen on localhost only restricts network access to the local machine, which is impractical for a multi-node etcd cluster and does not provide authentication or authorization for clients that do have access. Option D is wrong because etcd RBAC (role-based access control) controls what operations an authenticated user can perform, but it does not authenticate the client itself; without TLS client authentication, an attacker could still connect and attempt to exploit RBAC misconfigurations.

Full explanation →

Multi-Selectmedium

Which TWO of the following are recommended CIS benchmark practices for securing etcd? (Choose two.)

Select 2 answers

A.Use TLS certificates for client-to-server communication

B.Run etcd as root user

C.Disable authentication for etcd to reduce latency

D.Enable encryption at rest

E.Expose etcd to the public internet for easier management

AnswersA, D

TLS certificates for client-to-server communication are a CIS benchmark requirement for etcd because they authenticate the kube-apiserver as the only legitimate etcd client and encrypt all traffic between them, preventing man-in-the-middle interception and unauthorized writes. Without mutual TLS, an attacker on the network could impersonate the API server or read and modify cluster state in transit. This is a critical control-plane hardening measure.

Why this answer

The CIS benchmark for etcd recommends using TLS certificates for client-to-server communication to ensure data in transit is encrypted and authenticated. This prevents man-in-the-middle attacks and unauthorized access to the etcd cluster, which stores critical cluster state and secrets.

Exam trap

CNCF often tests the misconception that disabling authentication reduces latency and is acceptable for performance, but the CIS benchmark explicitly requires authentication and encryption for all etcd communication, and candidates may overlook the security implications of running etcd as root or exposing it publicly.

Full explanation →

MCQhard

An administrator needs to encrypt secrets at rest in etcd. Which of the following steps is required?

A.Use kubectl encrypt secrets command.

B.Modify the etcd configuration to enable encryption.

C.Create an EncryptionConfiguration resource and pass it to the kube-apiserver via the --encryption-provider-config flag.

D.Set the environment variable ENCRYPT_SECRETS=true on all nodes.

AnswerC

This is the correct approach: you create an EncryptionConfiguration object (YAML) that declares one or more encryption providers (e.g., aescbc, secretbox, or kms) and a key list, then start the kube-apiserver with --encryption-provider-config=/path/to/this/file. When a Secret is written, the apiserver encrypts it with the first non-identity provider before sending it to etcd; when read, it tries providers in order until one can decrypt. This gives you at-rest encryption with per-resource control, key rotation, and support for external KMS providers.

Why this answer

Kubernetes does not have a native `kubectl encrypt secrets` command, and etcd itself does not handle encryption configuration directly. Instead, encryption at rest is configured by creating an `EncryptionConfiguration` YAML resource that defines providers (e.g., `aescbc`, `secretbox`) and passing it to the `kube-apiserver` via the `--encryption-provider-config` flag. The API server then transparently encrypts secrets before writing them to etcd and decrypts them on read.

Exam trap

The CKS exam often tests the misconception that encryption at rest is configured directly on etcd or via an environment variable, when in fact it is a kube-apiserver configuration that intercepts writes to etcd.

How to eliminate wrong answers

Option A is wrong because `kubectl encrypt secrets` is not a valid kubectl command; encryption is handled server-side by the API server, not by the client. Option B is wrong because etcd does not have a configuration option to encrypt secrets at rest; encryption is enforced by the API server, which writes encrypted data to etcd. Option D is wrong because there is no `ENCRYPT_SECRETS` environment variable in Kubernetes; encryption is configured declaratively via the `EncryptionConfiguration` resource and the API server flag.

Full explanation →

MCQmedium

To enforce Pod Security Standards at the namespace level, which admission plugin must be enabled on the API server?

A.SecurityContextDeny

B.NodeRestriction

C.PodSecurityPolicy

D.PodSecurity

AnswerD

PodSecurity is the built-in admission controller that enforces the three Pod Security Standards (privileged, baseline, restricted) using namespace labels such as pod-security.kubernetes.io/enforce=restricted. During Pod creation and update, it checks the effective policy derived from the namespace labels and rejects non-compliant Pods, while supporting warn, audit, and enforce modes for gradual rollout. It is the current mechanism that replaces the deprecated PodSecurityPolicy and enforces PSS at the namespace level.

Why this answer

Pod Security Standards (PSS) are enforced at the namespace level using the PodSecurity admission plugin, which was introduced in Kubernetes v1.23 and graduated to stable in v1.25. This plugin evaluates pods against the predefined security levels (privileged, baseline, restricted) based on labels on the namespace, replacing the deprecated PodSecurityPolicy.

Exam trap

CNCF often tests the distinction between the deprecated PodSecurityPolicy (PSP) and the current PodSecurity admission plugin, leading candidates to mistakenly select PSP because they recall 'Pod Security' in the name, but PSP is no longer available in recent Kubernetes versions.

How to eliminate wrong answers

Option A is wrong because SecurityContextDeny is a deprecated admission plugin that only rejects pods with specific security context settings (like privileged containers) but does not implement the three-tier Pod Security Standards. Option B is wrong because NodeRestriction is an admission plugin that limits the kubelet's ability to modify node and pod objects, not related to enforcing pod security policies. Option C is wrong because PodSecurityPolicy (PSP) is a deprecated admission plugin that was removed in Kubernetes v1.25; it enforced security policies at the cluster level via PSP resources, not at the namespace level using Pod Security Standards.

Full explanation →

MCQmedium

A security policy requires that all containers in the 'staging' namespace drop all Linux capabilities and only add the necessary ones. Which pod security context configuration achieves this?

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

B.cap_drop: ["NET_RAW"]

C.cap_add: ["ALL"]

D.cap_add: ["NET_BIND_SERVICE"]

AnswerA

This configuration correctly satisfies the policy by first using capabilities.drop: ["ALL"] to clear the container's entire capability bounding set, effectively denying every privilege by default. It then explicitly re-adds only NET_BIND_SERVICE, which is the specific capability required to bind to privileged ports (those below 1024). This follows the principle of least privilege: the container starts with nothing and receives only the single capability necessary for its intended function, making it compliant and secure.

Why this answer

It drops all Linux capabilities using `capabilities.drop: ["ALL"]` and then explicitly adds only the necessary `NET_BIND_SERVICE` capability via `capabilities.add: ["NET_BIND_SERVICE"]`. This adheres to the principle of least privilege by starting from a clean slate and granting only the required capability. In Kubernetes security contexts, the correct keys are `capabilities.drop` and `capabilities.add` under the `securityContext` field.

Options B and D partially meet the requirement but do not drop all capabilities; Option C adds all capabilities, violating the policy.

Exam trap

CNCF often tests the misconception that simply adding a capability is sufficient, without realizing that the default capability set includes many capabilities (e.g., `CHOWN`, `DAC_OVERRIDE`, `FOWNER`, `FSETID`, `KILL`, `SETGID`, `SETUID`, `SETPCAP`, `NET_BIND_SERVICE`, `NET_RAW`, `SYS_CHROOT`, `MKNOD`, `AUDIT_WRITE`, `SETFCAP`) and that dropping all first is mandatory to enforce least privilege.

How to eliminate wrong answers

Option B is wrong because `cap_drop: ["NET_RAW"]` only drops the `CAP_NET_RAW` capability, leaving all other capabilities intact, which violates the requirement to drop all capabilities first. Option C is wrong because `cap_add: ["ALL"]` adds every capability, which is the opposite of dropping all capabilities and contradicts the security policy. Option D is wrong because `cap_add: ["NET_BIND_SERVICE"]` without a preceding `cap_drop: ["ALL"]` only adds the capability on top of the default set, which still includes many unnecessary capabilities, failing to meet the 'drop all' requirement.

Full explanation →

MCQmedium

A security team is hardening a cluster where the kube-apiserver is started with the flag --authorization-mode=Node,RBAC. A penetration test reveals that kubelet authentication is using anonymous requests and the webhook authorizer is not enabled. To ensure that kubelet API requests are authenticated and authorized, which combination of kubelet configuration changes should be applied?

A.Set authentication.webhook.enabled=true and authorization.mode=Node in the kubelet config file.

B.Set authentication.x509.clientCAFile to a valid CA and authorization.mode=AlwaysAllow in the kubelet config file.

C.Set authentication.anonymous.enabled=true and authorization.mode=AlwaysAllow in the kubelet config file.

D.Set authentication.anonymous.enabled=false and authorization.mode=Webhook in the kubelet config file.

AnswerD

Disabling anonymous authentication forces all requests to be authenticated, and setting authorization mode to Webhook delegates authorization decisions to the API server. This ensures that only authenticated and authorized entities can access the kubelet API. It directly addresses the penetration test finding by preventing anonymous access and enforcing proper authorization, aligning with Kubernetes security best practices for cluster hardening.

Why this answer

The correct configuration disables anonymous authentication and sets the kubelet authorization mode to Webhook. This forces all kubelet API requests to be authenticated and then authorized by the API server, eliminating anonymous access and ensuring only authorized actions are allowed. This directly remediates the penetration test finding and is a fundamental step in cluster hardening.

Exam trap

The trap here is assuming that enabling any authentication method is sufficient, while overlooking that authorization mode must also be set to Webhook to prevent anonymous or overly permissive access.

Full explanation →

MCQmedium

Which Kyverno policy action is used to automatically mutate a resource to add a sidecar container for security?

A.validate

B.verifyImages

C.mutate

D.generate

AnswerC

Kyverno's `mutate` action rewrites matching resources during admission, applying JSON patches or strategic merge to inject the sidecar container automatically. This satisfies the stem's requirement for automatic modification, unlike `validate`, which only permits or denies requests without altering them.

Why this answer

The `mutate` action in Kyverno is specifically designed to modify incoming Kubernetes resources before they are persisted. Adding a sidecar container (e.g., a security agent like Istio or Falco) is a classic mutation use case, where the policy patches the Pod spec to inject the container definition. This is distinct from validation, image verification, or resource generation.

Exam trap

The CKS exam often tests the distinction between `mutate` and `validate` by describing a scenario that requires a change to the resource, leading candidates to incorrectly choose `validate` because they confuse 'enforcing a policy' with 'modifying the resource'.

How to eliminate wrong answers

Option A is wrong because `validate` only checks whether a resource conforms to a policy and can enforce admission rules, but it cannot modify the resource to add a sidecar. Option B is wrong because `verifyImages` is a dedicated action for checking image signatures and attestations (e.g., using Sigstore/cosign), not for mutating Pod specs. Option D is wrong because `generate` creates new resources (e.g., NetworkPolicies or ConfigMaps) based on a trigger, but it does not mutate the triggering resource itself.

Full explanation →

Multi-Selectmedium

Which THREE of the following are recommended practices for securing container images in a Kubernetes environment?

Select 3 answers

A.Scan images for vulnerabilities before deployment

B.Store sensitive configuration data directly in the image

C.Use imagePullSecrets to authenticate to private container registries

D.Use minimal base images like distroless or scratch

E.Run containers as root to avoid permission issues

AnswersA, C, D

Scanning images for known vulnerabilities before deployment is a foundational security gate because containers inherit the package inventory of their base image and layers. Tools like Trivy or Grype compare installed packages against vulnerability databases in CI/CD, failing builds on critical flaws. Without this check, vulnerable images can run indefinitely, giving attackers a known path to exploit in production.

Why this answer

Scanning container images for vulnerabilities before deployment is a fundamental security practice in Kubernetes environments. Tools like Trivy, Clair, or Anchore Grype can identify known CVEs in the base image and application dependencies, allowing teams to remediate issues before the image is run. This aligns with the principle of shifting security left and is a key requirement for compliance with standards like the NIST Application Container Security Guide.

Option C is correct because using imagePullSecrets is a recommended practice to authenticate to private container registries. While imagePullSecrets do not enforce access control policies on which images can be pulled, they securely store credentials and enable pods to pull images from private registries, which is essential for using images that are not publicly accessible. This prevents unauthorized access to private images and reduces the risk of using compromised public images.

Option D is correct because using minimal base images such as distroless or scratch reduces the attack surface by eliminating unnecessary packages, libraries, and utilities. This aligns with the principle of least functionality and minimizes the number of potential vulnerabilities that could be exploited.

Exam trap

CNCF often tests the misconception that imagePullSecrets (Option C) are used to restrict which images can be pulled from registries, but in reality, imagePullSecrets only authenticate to private registries and do not enforce any access control or policy on which images are allowed to be pulled; for restriction, you need an admission controller like OPA/Gatekeeper or a registry firewall.

Full explanation →

MCQmedium

A development team uses a custom container image for their application, built from a base image that includes multiple CVEs. The security team requires that no container runs with known critical vulnerabilities. Which approach best ensures that only images with no critical vulnerabilities are deployed in production?

A.Configure a Kubernetes admission controller (e.g., Kyverno) to reject pods using images with critical vulnerabilities.

B.Scan the base image before building the application image.

C.Integrate an image scanner (e.g., Trivy) into the CI/CD pipeline to block builds with critical vulnerabilities.

D.Manually review vulnerability reports after the image is deployed.

AnswerC

Integrating a scanner like Trivy into the CI/CD pipeline creates a build-time quality gate: it scans the final image after all layers are assembled and fails the pipeline if critical vulnerabilities are found, so vulnerable images are never pushed to the container registry. This shift-left approach automates prevention at the earliest practical stage and provides a clear signal to developers before the image reaches deployment. This is the recommended primary control for supply chain security.

Why this answer

Integrating an image scanner like Trivy into the CI/CD pipeline ensures that any image with critical vulnerabilities is blocked before it is even built or pushed to a registry. This shift-left approach prevents vulnerable images from ever reaching the production environment, aligning with the security team's requirement to deploy only images with no critical vulnerabilities.

Exam trap

CNCF often tests the distinction between shift-left security (preventing vulnerabilities at build time) versus runtime enforcement (admission controllers), and the trap here is that candidates choose admission controllers (Option A) because they seem to block vulnerable images, but they fail to realize that the image must already exist in the registry and may have been built with vulnerabilities, whereas CI/CD scanning prevents the image from being created in the first place.

How to eliminate wrong answers

Option A is wrong because a Kubernetes admission controller like Kyverno can only reject pods at deployment time, but the image may already be in the registry with known CVEs, and the admission controller relies on metadata or external scans that may not be up-to-date; it also does not prevent the image from being built or stored. Option B is wrong because scanning only the base image before building the application image does not account for vulnerabilities introduced by the application layer or dependencies added during the build process, leaving the final image potentially vulnerable. Option D is wrong because manually reviewing vulnerability reports after deployment is reactive and does not prevent vulnerable images from running in production, violating the requirement to ensure no container runs with critical vulnerabilities.

Full explanation →

MCQhard

A platform team runs a multi-tenant cluster and wants to enforce that all newly created Pods in the 'payments' namespace must run as non-root and must drop all Linux capabilities. The team decides to use a Pod Security Admission (PSA) label on the namespace. Which label value should they apply to the namespace to enforce these restrictions while still allowing other namespaces to remain unrestricted?

A.pod-security.kubernetes.io/enforce: baseline

B.pod-security.kubernetes.io/audit: restricted

C.pod-security.kubernetes.io/enforce: restricted

D.pod-security.kubernetes.io/enforce: privileged

AnswerC

The restricted policy enforces the most hardened Pod Security Standard, requiring non-root execution, dropping all capabilities, disallowing privilege escalation, and mandating seccomp and runtime default settings. Applying this enforce label to the payments namespace makes non-compliant Pods rejected at admission, while other namespaces without the label remain unaffected, matching the requirement.

Why this answer

Pod Security Admission enforces one of three levels: privileged, baseline, or restricted. The restricted level is the only one that requires non-root execution and dropping all capabilities. Setting the enforce label to restricted on the payments namespace blocks non-compliant Pods there while leaving other namespaces without the label unrestricted, which satisfies the multi-tenant requirement.

Exam trap

The trap here is confusing the audit or warn labels with enforce, when only the enforce label actually rejects non-compliant Pods.

Full explanation →

MCQhard

A pod is using a custom seccomp profile stored at /var/lib/kubelet/seccomp/custom-profile.json. Which securityContext configuration correctly references this profile?

A.seccompProfile: type: Unconfined localhostProfile: "custom-profile.json"

B.seccompProfile: type: RuntimeDefault localhostProfile: "custom-profile.json"

C.seccompProfile: type: Localhost localhostProfile: "/var/lib/kubelet/seccomp/custom-profile.json"

D.seccompProfile: type: Localhost localhostProfile: "custom-profile.json"

AnswerD

This is the correct configuration: type Localhost tells the kubelet to load a custom seccomp profile from a file on the node, and localhostProfile gives the filename relative to the kubelet's seccomp directory. The kubelet then constructs the full path /var/lib/kubelet/seccomp/custom-profile.json and passes it to the container runtime, which enforces the syscall restrictions defined in that JSON file.

Why this answer

When using a custom seccomp profile stored in the default kubelet seccomp directory (`/var/lib/kubelet/seccomp/`), the `type` must be `Localhost` and the `localhostProfile` must be a relative path (just the filename). Kubernetes automatically prepends the default seccomp root path, so `custom-profile.json` resolves to `/var/lib/kubelet/seccomp/custom-profile.json`.

Exam trap

The CKS exam often tests the misconception that `localhostProfile` requires an absolute path, but the correct syntax is a relative path (just the filename) when the profile resides in the default kubelet seccomp directory.

How to eliminate wrong answers

Option A is wrong because `type: Unconfined` disables seccomp entirely and ignores any `localhostProfile` value. Option B 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 C is wrong because `localhostProfile` must be a relative path (just the filename) when the profile is in the default kubelet seccomp directory; an absolute path like `/var/lib/kubelet/seccomp/custom-profile.json` is not valid in this context.

Full explanation →

Multi-Selectmedium

Which TWO of the following are valid ways to enforce that a container runs as a non-root user?

Select 2 answers

A.Set the container image to use a root user

B.Set runAsNonRoot: true in the pod securityContext

C.Use a PodSecurityPolicy (PSP)

D.Use a Kyverno policy to validate runAsNonRoot

E.Set runAsUser: 0 in the container securityContext

AnswersB, D

Setting `runAsNonRoot: true` in the pod securityContext is a native Kubernetes admission check that forces the container's effective user ID to be non-zero. When this is set, the kubelet will verify the image's user configuration, and if the container image is set to run as root (UID 0), the pod creation is rejected. To pass this check, either the image must define a non-root `USER` directive or the pod must explicitly set a non-zero `runAsUser`. This is the fundamental built-in method for enforcing non-root containers.

Why this answer

Setting `runAsNonRoot: true` in the pod's `securityContext` explicitly instructs the kubelet to validate that the container's user ID is not 0 (root) before starting the container. If the container attempts to run as root, the kubelet will refuse to start it, providing a strong enforcement mechanism at the Kubernetes level.

Exam trap

The CKS exam often tests the misconception that PodSecurityPolicy (PSP) is still a valid option, but it has been removed since Kubernetes v1.25, so candidates must know that Kyverno or OPA/Gatekeeper policies are the modern replacements for enforcing non-root execution.

Full explanation →

MCQmedium

You have a requirement to encrypt secrets at rest in etcd. Which resource and apiVersion should be used?

A.EtcdEncryption with apiVersion apiserver.config.k8s.io/v1beta1

B.EncryptionConfig with apiVersion v1

C.SecretEncryption with apiVersion v1

D.EncryptionConfiguration with apiVersion apiserver.config.k8s.io/v1

AnswerD

EncryptionConfiguration is the Kubernetes resource that defines encryption at rest for etcd, and apiserver.config.k8s.io/v1 is its correct apiVersion. This satisfies the requirement to encrypt secrets at rest by configuring the kube-apiserver's encryption provider, distinct from Secret or EncryptionKey resources.

Why this answer

The Kubernetes API server uses an `EncryptionConfiguration` resource with `apiVersion apiserver.config.k8s.io/v1` to define how secrets and other resources are encrypted at rest in etcd. This resource specifies providers (e.g., `aescbc`, `secretbox`) and keys, and is loaded via the `--encryption-provider-config` flag on the API server. The `v1` version is the stable, production-ready API version for this configuration.

Exam trap

CNCF often tests the exact resource name and API group, and the trap here is that candidates confuse `EncryptionConfiguration` with made-up names like `EtcdEncryption` or `SecretEncryption`, or incorrectly assume it belongs to the core `v1` API group instead of `apiserver.config.k8s.io`.

How to eliminate wrong answers

Option A is wrong because `EtcdEncryption` is not a valid Kubernetes resource; the correct resource is `EncryptionConfiguration`. Option B is wrong because `EncryptionConfig` with `apiVersion v1` does not exist; the resource is `EncryptionConfiguration` under `apiserver.config.k8s.io`, not core `v1`. Option C is wrong because `SecretEncryption` is not a real resource; Kubernetes uses `EncryptionConfiguration` to configure encryption at rest, not a resource named after the object type.

Full explanation →

MCQhard

You are tasked with securing a Kubernetes cluster. You want to ensure that the kubelet only serves APIs that are explicitly allowed and that it does not allow anonymous requests. Which kubelet configuration flags should you set?

A.--anonymous-auth=false and --authorization-mode=RBAC

B.--anonymous-auth=true and --authorization-mode=ABAC

C.--anonymous-auth=false and --authorization-mode=AlwaysAllow

D.--anonymous-auth=false and --authorization-mode=Webhook

AnswerD

This is the recommended secure configuration because disabling anonymous auth ensures no unauthenticated request reaches the kubelet's server, while the Webhook mode delegates every authorization decision to the API server's SubjectAccessReview endpoint. The API server evaluates the request against RBAC rules for the kubelet's credentials, meaning a user or service account can only see or control pods they are explicitly allowed to access. This integration also ensures that kubelet authorization is centrally managed and consistent with the rest of cluster policy, rather than relying on a local fallback. The flag combination is the golden standard for production Kubernetes hardening.

Why this answer

Setting `--anonymous-auth=false` disables anonymous requests to the kubelet, and `--authorization-mode=Webhook` delegates authorization decisions to an external service (e.g., the API server), allowing fine-grained control over which APIs the kubelet serves. This combination ensures that only authenticated, authorized requests are processed, aligning with the principle of least privilege.

Exam trap

The trap here is that candidates confuse kubelet authorization modes with API server authorization modes, mistakenly selecting `RBAC` (Option A) which is not a valid kubelet flag, while overlooking that `Webhook` is the correct mode to enforce RBAC-like policies on the kubelet.

How to eliminate wrong answers

Option A is wrong because `--authorization-mode=RBAC` is not a valid kubelet flag; the kubelet supports `AlwaysAllow`, `Webhook`, and `ABAC` modes, but RBAC is an API server authorization mode, not a kubelet one. Option B is wrong because `--anonymous-auth=true` allows anonymous requests, which contradicts the requirement to disallow them, and `--authorization-mode=ABAC` is deprecated and less secure than Webhook for dynamic authorization. Option C is wrong because `--authorization-mode=AlwaysAllow` permits all authenticated requests without any authorization checks, failing to restrict APIs to only those explicitly allowed.

Full explanation →

MCQeasy

An admin wants to check which AppArmor profiles are loaded. Which command should they run?

A.apparmor list

B.aa-status

C.seccomp-status

D.ls /sys/kernel/security/apparmor/profiles

AnswerB

aa-status is the canonical utility from the apparmor-utils package that reads the kernel's loaded AppArmor profiles via the securityfs interface and presents them in a human-readable format. It shows each profile's mode (enforce or complain), lists profiles that are loaded, and can optionally display the processes currently confined by each profile. For an admin checking loaded profiles, aa-status is the correct, supported command.

Why this answer

The `aa-status` command is the standard tool for displaying the status of AppArmor, including which profiles are loaded, their enforcement mode (enforce/complain), and process confinement. It queries the AppArmor security module directly via the kernel interface, making it the correct and most comprehensive command for this task.

Exam trap

A common trap is that candidates may think the profiles are listed via a filesystem path or confuse AppArmor with seccomp, which is another Linux security module used in Kubernetes for restricting syscalls. However, `aa-status` is the proper command for AppArmor profile status, and it is often used on Kubernetes nodes to verify profile loading.

How to eliminate wrong answers

Option A is wrong because `apparmor list` is not a valid command; AppArmor does not provide a `list` subcommand. Option C is wrong because `seccomp-status` is not a real command; seccomp (secure computing mode) is a separate Linux kernel feature for syscall filtering, and its status is checked via `/proc/sys/kernel/seccomp/` or `seccomp-tools`, not this command. Option D is wrong because while `ls /sys/kernel/security/apparmor/profiles` does list the profile names as files, it only shows the names and not the full status (e.g., mode, process association), and is not the standard admin command; `aa-status` is the intended tool.

Full explanation →

Multi-Selecthard

Which THREE are valid methods to enforce that only images from a specific registry can be deployed in a Kubernetes cluster? (Select three.)

Select 3 answers

A.PodSecurityPolicy (PSP)

B.ImagePolicyWebhook admission controller

C.Kyverno policy validating image registry

D.OPA/Gatekeeper constraint to validate registry

E.NetworkPolicy to restrict egress to registries

AnswersB, C, D

ImagePolicyWebhook delegates admission decisions to an external HTTPS service that inspects the pod's image reference and returns allow or deny. Configuring it to reject images outside the specified registry enforces the restriction at admission time, satisfying the registry-only deployment requirement.

Why this answer

Option B (ImagePolicyWebhook admission controller) is correct because it is a built-in Kubernetes admission controller that calls an external HTTP webhook during admission to approve or reject a Pod based on its container image, so the webhook can enforce that images originate only from an allowed registry. Option C (Kyverno policy validating image registry) is correct because Kyverno is a Kubernetes-native admission policy engine whose validating policies can match on Pod specs and deny any container whose image field does not reference the approved registry. Option D (OPA/Gatekeeper constraint to validate registry) is correct because Gatekeeper runs OPA as a validating admission webhook and its ConstraintTemplates/Constraints (e.g., using Rego on input.review.object.spec.containers[_].image) can reject workloads that pull from unapproved registries.

Option A (PodSecurityPolicy) is not correct because PSP only governed pod security attributes such as privileged mode, host namespaces, and volume types, not image registry provenance. Option E (NetworkPolicy) is not correct because it only controls L3/L4 network traffic (e.g., egress to registry IPs/ports) and cannot inspect or validate the image reference used in a Pod specification.

Exam trap

The CKS exam often tests that candidates confuse PodSecurityPolicy (PSP) with image registry validation, but PSP only controls pod security attributes, not image sources; the trap is assuming PSP can filter registries because it has 'policy' in its name.

Full explanation →

MCQhard

A security team wants to enforce that no container in the 'restricted' namespace runs with added Linux capabilities beyond the default set (according to the restricted Pod Security Standard). Which PodSecurityConfiguration should be applied to the namespace?

A.apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "restricted" enforce-version: "latest"

B.apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: warn: "restricted" warn-version: "latest"

C.apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "privileged" enforce-version: "latest"

D.apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "baseline" enforce-version: "latest"

AnswerA

The `restricted` enforce level applies the most restrictive Pod Security Standard, which is exactly what the security team requires. It rejects any pod that does not meet strict criteria: privileged containers are forbidden, all Linux capabilities are dropped except `NET_BIND_SERVICE`, and settings like `runAsNonRoot` and `seccompProfile` become mandatory. With `enforce-version: latest`, the policy tracks the current standard as Kubernetes evolves, ensuring ongoing compliance without manual updates.

Why this answer

The 'restricted' Pod Security Standard (PSS) is the most stringent profile, which enforces that no container runs with added Linux capabilities beyond the default set (e.g., dropping all capabilities except those required by the runtime). The 'enforce' mode blocks non-compliant pods from being created, and 'enforce-version: latest' applies the most current version of the restricted profile, ensuring that any new restrictions are automatically enforced.

Exam trap

The trap here is that candidates often confuse the 'baseline' profile with 'restricted', thinking baseline is sufficient to block added capabilities, but baseline explicitly allows a set of capabilities (e.g., CHOWN, DAC_OVERRIDE) that are not permitted under the restricted standard.

How to eliminate wrong answers

Option B is wrong because it uses 'warn' mode, which only generates a warning but does not block non-compliant pods; the question requires enforcement (blocking) of the restricted profile. Option C is wrong because it uses the 'privileged' profile, which allows all capabilities and is the opposite of the required restriction. Option D is wrong because it uses the 'baseline' profile, which allows a minimal set of capabilities beyond the default (e.g., NET_RAW, CHOWN) and does not enforce the stricter 'restricted' standard that drops all non-default capabilities.

Full explanation →

MCQmedium

An administrator runs 'kubectl describe nodes' and notices that the node status shows 'Ready,SchedulingDisabled'. What is the most likely cause?

A.The kubelet is not running

B.The node was cordoned using 'kubectl cordon <node>'

C.The node has insufficient resources

D.The node is tainted with NoSchedule

AnswerB

Cordoning a node with 'kubectl cordon <node>' sets its unschedulable field to true, which instructs the scheduler to avoid placing new or pending pods on that node while existing pods keep running. This is exactly what surfaces as 'SchedulingDisabled' in kubectl describe node output (and often as 'Ready,SchedulingDisabled' in get nodes). The node's readiness remains True because the kubelet is healthy; only the scheduler's admission decision is changed, making cordoning the correct explanation for the observed status.

Why this answer

The 'Ready,SchedulingDisabled' status indicates that the node is marked as unschedulable for new pods while remaining fully operational. This is exactly what happens when an administrator runs 'kubectl cordon <node>', which sets the node's 'spec.unschedulable' field to true. The kubelet continues to run and report readiness, but the scheduler will skip the node when placing new pods.

Exam trap

CNCF often tests the distinction between taints (which affect scheduling based on tolerations) and cordoning (which makes the node completely unschedulable), leading candidates to confuse taint-based scheduling restrictions with the explicit unschedulable flag.

How to eliminate wrong answers

Option A is wrong because if the kubelet were not running, the node status would be 'NotReady' or 'Unknown', not 'Ready,SchedulingDisabled'. Option C is wrong because insufficient resources would cause the node to report conditions like 'MemoryPressure' or 'DiskPressure', not the specific 'SchedulingDisabled' marker. Option D is wrong because a NoSchedule taint prevents pod scheduling via the scheduler's taint-toleration mechanism, but the node status would still show 'Ready' without the 'SchedulingDisabled' suffix; the node remains schedulable for pods that tolerate the taint.

Full explanation →

MCQhard

A Falco rule has priority: CRITICAL and condition: evt.type=execve and proc.name!=bash. What does this rule detect?

A.Any process spawning bash

B.All execve events except bash regardless of namespace

C.All execve events inside containers except bash

D.All execve events on the host except bash

AnswerB

Falco evaluates the condition against every execve event, and the proc.name!=bash filter excludes only processes named bash. No namespace field appears in the condition, so container and host executions alike trigger the CRITICAL alert, matching the option's scope exactly.

Why this answer

The Falco rule `evt.type=execve and proc.name!=bash` with priority CRITICAL detects all `execve` system call events where the process name is NOT `bash`. Falco operates at the host level and monitors all system calls across the entire node, including those from containers. Since the rule does not include a container-specific filter (e.g., `container.id != host`), it applies to all processes regardless of namespace.

Therefore, the rule detects all execve events except bash on the entire node—both host and container processes. Option B correctly captures this scope ('regardless of namespace').

Exam trap

The trap here is that candidates often assume Falco rules are container-scoped by default, but Falco operates at the host level and monitors all system calls unless explicitly filtered by container ID or namespace, so a rule without a container filter applies to the entire host.

How to eliminate wrong answers

Option A is wrong because the rule detects processes that are NOT bash, not processes spawning bash. Option B is wrong because the rule does not exclude bash events; it excludes events where the process name is bash, meaning it detects all execve events except those from bash, but it does not filter by namespace, so it applies to all execve events on the host, not just those inside containers. Option C is wrong because the rule does not limit detection to containers; Falco monitors all system calls on the host, including those from containers, but the rule applies globally to the entire node.

Full explanation →

MCQmedium

A security team wants to detect anomalous process executions in containers without modifying the container images or requiring agents inside containers. Which approach is most suitable?

A.Configure CRI-O to log all container process starts to syslog.

B.Deploy Falco as a DaemonSet using eBPF probe to monitor system calls.

C.Enable Kubernetes audit logging and parse the logs for process events.

D.Use OPA Gatekeeper to enforce allowed process lists in pod specs.

AnswerB

Falco deployed as a DaemonSet runs on every node and consumes kernel events via an eBPF probe (or a kernel module) to observe system calls such as execve, open, and connect across all containers. It applies a rules engine to flag anomalous process executions in real-time, without requiring modifications to container images or pod specs. The eBPF approach is preferred over the kernel module on modern distributions because it avoids out-of-tree module compilation and is safer in hardened environments.

Why this answer

Falco, deployed as a DaemonSet with an eBPF probe, can monitor system calls at the kernel level without modifying container images or requiring agents inside containers. This allows it to detect anomalous process executions in real time by analyzing syscall events from the host, which is the most suitable approach for runtime security monitoring in Kubernetes.

Exam trap

CNCF often tests the distinction between admission control (e.g., OPA Gatekeeper) and runtime monitoring (e.g., Falco), where candidates mistakenly choose a policy enforcement tool for detection tasks.

How to eliminate wrong answers

Option A is wrong because CRI-O does not natively log all container process starts to syslog; it manages container runtime operations but lacks built-in process-level auditing. Option C is wrong because Kubernetes audit logging captures API server requests (e.g., pod creation), not process executions within containers, so it cannot detect anomalous process starts. Option D is wrong because OPA Gatekeeper enforces admission control policies on pod specs (e.g., allowed process lists) but does not monitor runtime behavior or detect anomalies after a container is running.

Full explanation →

MCQhard

A pod has been compromised. You want to isolate it from other pods while preserving its network state for forensics. Which NetworkPolicy rule achieves this?

A.Deny all ingress and egress traffic to/from the pod's namespace

B.Create a NetworkPolicy with podSelector matching the compromised pod and empty ingress/egress rules (deny all)

C.Add a label to the pod and create a NetworkPolicy allowing only traffic from a forensic pod

D.Delete the pod

AnswerB

This is correct because a NetworkPolicy with a podSelector that matches only the compromised pod and contains no ingress or egress rules creates a default-deny policy for that pod alone. Under Kubernetes NetworkPolicy semantics, any selected pod with no matching rules is isolated: all inbound and outbound traffic is dropped, including DNS and cluster traffic. The policy does not alter the pod itself, so it preserves the running state and evidence. This is the standard, least-privilege method for isolating a single pod without disturbing the rest of the namespace.

Why this answer

A NetworkPolicy with a `podSelector` matching the compromised pod and empty `ingress` and `egress` rules (i.e., no rules specified) defaults to denying all traffic to and from that pod. This isolates the pod from all other pods in the cluster while preserving its network state for forensics, as the pod remains running and its network interfaces are untouched.

Exam trap

The trap here is that candidates often think a NetworkPolicy must explicitly specify `deny all` rules, but Kubernetes uses an implicit deny when the `ingress` or `egress` arrays are empty, which is a subtle but critical distinction tested in the CKS exam.

How to eliminate wrong answers

Option A is wrong because denying all ingress and egress traffic to/from the pod's namespace would affect all pods in that namespace, not just the compromised one, and does not isolate the specific pod while preserving its network state. Option C is wrong because adding a label and creating a NetworkPolicy that allows only traffic from a forensic pod would still permit egress traffic from the compromised pod unless explicitly denied, and it does not achieve full isolation. Option D is wrong because deleting the pod destroys its network state and prevents forensic analysis of its runtime behavior.

Full explanation →

100

Multi-Selecthard

Which THREE of the following are correct statements about seccomp in Kubernetes? (Select 3)

Select 3 answers

A.Seccomp can be configured using the securityContext.seccompProfile field

B.Seccomp profiles can only be applied to privileged containers

C.The RuntimeDefault seccomp profile uses the container runtime's default profile

D.Seccomp can only restrict system calls, not allow them

E.Custom seccomp profiles must be placed in /var/lib/kubelet/seccomp/ on the node

AnswersA, C, E

In the Kubernetes API, seccomp is configured declaratively through the securityContext.seccompProfile field, available at both pod and container scope. This field accepts a type (Unconfined, RuntimeDefault, or Localhost) and optionally a localhostProfile name. Since v1.19 it is GA, superseding the older alpha annotations, and is the only supported way to attach a seccomp profile to workloads.

Why this answer

The `securityContext.seccompProfile` field in a Pod or container spec allows you to configure seccomp profiles directly in the Kubernetes API. This field supports values like `RuntimeDefault`, `Localhost`, and `Unconfined`, enabling fine-grained control over system call filtering without requiring manual profile loading on the node.

Exam trap

CNCF often tests the misconception that seccomp only applies to privileged containers or that it can only deny syscalls, when in fact it is a general-purpose syscall filter for all containers and supports both allow and deny actions.

Full explanation →

101

Multi-Selectmedium

Which TWO of the following Falco fields can be used in a rule condition to detect a shell spawned inside a container? (Choose two.)

Select 2 answers

A.evt.type

B.k8s.ns.name

C.proc.pname

D.container.id

E.proc.name

AnswersC, E

In Falco, proc.pname contains the name of the parent process of the event's process. This field is particularly valuable for detecting suspicious subprocess spawning: a shell like 'bash' is frequently launched by an application (e.g., a web server or a Kubernetes controller) rather than directly by a user. If a rule checks proc.pname for a known parent binary (such as 'nginx' or 'java') and proc.name for 'bash', it can flag a shell being spawned by an unexpected parent. Since proc.pname gives the immediate ancestor, it is a valid Falco field for writing shell-detection rules.

Why this answer

Option C (proc.pname) is correct because it identifies the parent process name, so a rule can match when the parent is a shell or entrypoint such as bash, sh, or a container runtime, indicating a shell was spawned by another process. Option E (proc.name) is correct because it identifies the name of the process that was executed, allowing detection of the spawned shell itself, e.g., proc.name=bash or proc.name=sh. Together, proc.pname and proc.name let Falco express conditions like proc.name in (bash, sh) and proc.pname in (bash, sh, docker, containerd) to catch shells spawned inside containers.

Option A (evt.type) only describes the syscall event type (e.g., execve, clone) and does not by itself identify a shell process. Option B (k8s.ns.name) only scopes the event to a Kubernetes namespace and provides no process-level information. Option D (container.id) merely identifies the container in which the event occurred, not that a shell was spawned.

Exam trap

CKS often tests whether candidates know which Falco fields are process-identity fields versus metadata/enrichment fields — the trap is selecting container.id or k8s.ns.name thinking they 'detect' the shell, when they only scope or locate the event.

Full explanation →

102

MCQmedium

Which tool can generate an SBOM for a container image?

A.Trivy

B.Cosign

C.Kubescape

D.Syft

AnswerD

Syft is a purpose-built SBOM generator from Anchore that scans container images and filesystems to inventory packages, libraries, and dependencies. It outputs standard formats like CycloneDX, SPDX, and Syft JSON, making it the definitive tool for converting an image into a software bill of materials.

Why this answer

Syft is a CLI tool specifically designed to generate a Software Bill of Materials (SBOM) for container images and filesystems. It scans the image layers and package managers (e.g., APT, RPM, pip, npm) to produce an SBOM in formats like CycloneDX or SPDX, directly addressing the question's requirement.

Exam trap

The trap here is that candidates confuse Trivy (a vulnerability scanner that can also output SBOMs) with Syft (a dedicated SBOM generator), but the CKS exam expects you to know the primary purpose of each tool in the CNCF supply chain security toolkit.

How to eliminate wrong answers

Option A is wrong because Trivy is a vulnerability scanner that can output SBOMs as a secondary feature, but its primary purpose is security scanning, not SBOM generation; the question asks for a tool that 'can generate an SBOM', and while Trivy can, Syft is the dedicated SBOM tool. Option B is wrong because Cosign is used for signing and verifying container images and attestations, not for generating SBOMs. Option C is wrong because Kubescape is a Kubernetes security scanner that checks cluster configurations and compliance, not a tool for generating SBOMs from container images.

Full explanation →

103

MCQeasy

Which of the following is a BEST practice for securing container images in a Dockerfile?

A.Use the USER directive to specify a non-root user

B.Store secrets in environment variables in the image

C.Run the container as root to simplify permission management

D.Use the 'latest' tag to always get the newest base image

AnswerA

The USER directive in a Dockerfile (or pod securityContext runAsNonRoot) enforces a non-root user for the container's process. This follows the principle of least privilege, limiting filesystem access and kernel namespace capabilities, so an attacker who compromises the application does not inherit root privileges on the host. Combined with a properly configured group and file ownership, it significantly reduces the blast radius of a container breakout.

Why this answer

The USER directive in a Dockerfile sets the user for the container process, and using a non-root user (e.g., USER 1000) follows the principle of least privilege. This reduces the attack surface by preventing an attacker who gains code execution from having root access to the host or container, which is a critical security requirement for containerized workloads.

Exam trap

The CKS exam often tests the misconception that running as root is acceptable if you drop capabilities or use a read-only filesystem, but it emphasizes that a non-root user is a fundamental defense-in-depth layer that must be explicitly set in the Dockerfile.

How to eliminate wrong answers

Option B is wrong because storing secrets in environment variables in the image embeds them in the image layers, making them accessible via `docker history` or image inspection, and they persist even if the container is restarted — this violates secret management best practices (use secrets mounts or external vaults instead). Option C is wrong because running as root inside the container grants unnecessary privileges; if the container is compromised, the attacker gains root access to the container and potentially to the host via kernel vulnerabilities or misconfigured capabilities. Option D is wrong because using the 'latest' tag introduces unpredictability and breaks reproducibility; the base image can change without notice, potentially introducing vulnerabilities or breaking changes — always pin to a specific digest or version tag.

Full explanation →

104

MCQmedium

An administrator wants to enforce mTLS between all services in the 'mesh' namespace using Istio. Which resource should be applied to require mutual TLS for all workloads in that namespace?

A.PeerAuthentication with mtls.mode: STRICT in the namespace

B.VirtualService with tls mode

C.DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL

D.ServiceEntry for external services

AnswerA

PeerAuthentication is the Istio custom resource that defines the server-side mTLS policy for accepted traffic. Setting `mtls.mode: STRICT` tells the sidecar proxy to reject all plaintext HTTP and require mutual TLS on every inbound connection to workloads in that namespace, making it a true namespace-wide enforcement. It is the standard, authoritative way to enforce mTLS between services because it specifically governs peer authentication, not routing or client-side TLS configuration.

Why this answer

PeerAuthentication defines the authentication policy for workloads within a namespace. Setting `mtls.mode: STRICT` in a PeerAuthentication resource for the 'mesh' namespace enforces that all services in that namespace require mutual TLS for incoming traffic, ensuring that only authenticated and encrypted connections are accepted. This is the correct Istio resource to enforce mTLS at the namespace level.

Exam trap

The CKS exam often tests the distinction between PeerAuthentication (server-side enforcement) and DestinationRule (client-side configuration), leading candidates to incorrectly choose DestinationRule for namespace-wide mTLS enforcement.

How to eliminate wrong answers

Option B is wrong because VirtualService is used for traffic routing and management (e.g., canary deployments, A/B testing), not for enforcing mTLS authentication policies. Option C is wrong because DestinationRule with `trafficPolicy.tls.mode: ISTIO_MUTUAL` configures the client side to use mTLS when sending traffic to a specific service, but it does not enforce mTLS on the server side for all workloads in the namespace; it is a per-service or per-host policy, not a namespace-wide enforcement. Option D is wrong because ServiceEntry is used to register external services (outside the mesh) into the Istio service registry, enabling traffic management and mTLS to those external endpoints, but it does not enforce mTLS for internal services within the namespace.

Full explanation →

105

MCQeasy

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

A.cosign verify <image>

B.cosign attest <image>

C.cosign sign <image>

D.cosign generate <image>

AnswerC

cosign sign is the dedicated command for signing a container image by creating an OCI signature object that references the image digest, either with a private key, a Cosign key pair, or keyless signing via Fulcio and Rekor. It computes a signature over the image manifest and stores the signature as a separate tag/artifact (e.g., sha256-...-key.sig) in the registry. This is the standard command for integrity and provenance verification workflows.

Why this answer

The `cosign sign <image>` command is used to sign a container image by attaching a digital signature to the image manifest in the container registry. This signature, typically stored as a separate tag or in an OCI artifact, allows verification of the image's origin and integrity using the corresponding public key.

Exam trap

The trap for CKS candidates is confusing the `cosign sign` command with `cosign attest` or `cosign verify`. Signing creates a signature artifact attached to the image, attestation adds a signed in-toto statement, and verification validates signatures. In the context of container supply chain security as tested on the CKS exam, understanding this distinction is key.

How to eliminate wrong answers

Option A is wrong because `cosign verify <image>` is used to verify an existing signature on an image, not to create one. Option B is wrong because `cosign attest <image>` creates an in-toto attestation (a signed statement about the image's build process or metadata), not a simple signature on the image itself. Option D is wrong because `cosign generate <image>` is not a valid command; the correct command for generating a key pair is `cosign generate-key-pair`, and `cosign generate` does not exist.

Full explanation →

106

MCQmedium

An administrator wants to enforce that all pods in a namespace use the restricted Pod Security Standard. Which of the following commands correctly enables this enforcement?

A.kubectl label namespace myns pod-security.kubernetes.io/audit=restricted

B.kubectl annotate namespace myns pod-security.kubernetes.io/enforce=restricted

C.kubectl label namespace myns pod-security.kubernetes.io/enforce=restricted

D.kubectl label namespace myns pod-security.kubernetes.io/warn=restricted

AnswerC

The enforce level of Pod Security Admission blocks pod creation if it violates the restricted policy, which is the strictest standard. By adding this label to the namespace, the PSA controller applies the policy at admission time, rejecting any non-compliant pod. This matches the administrator's requirement to enforce the policy.

Why this answer

The Pod Security Standards are enforced via labels on the namespace, and the `pod-security.kubernetes.io/enforce` label with value `restricted` tells the Pod Security Admission controller to reject any pod that violates the restricted policy. This is the only way to actively block non-compliant pods from being created in the namespace.

Exam trap

CNCF often tests the distinction between labels and annotations, and the trap here is that candidates confuse `kubectl annotate` with `kubectl label` for setting Pod Security Standard enforcement, or they pick `audit` or `warn` thinking they enforce the policy.

How to eliminate wrong answers

Option A is wrong because `pod-security.kubernetes.io/audit` only logs violations without blocking them, so it does not enforce the policy. Option B is wrong because Pod Security Standards use labels, not annotations; the `pod-security.kubernetes.io/enforce` key must be applied as a label for the admission controller to recognize it. Option D is wrong because `pod-security.kubernetes.io/warn` only generates a warning message for the user but still allows the pod to be created, so it does not enforce the restricted standard.

Full explanation →

107

Multi-Selectmedium

Which TWO of the following are valid methods to apply a seccomp profile to a container? (Select 2 correct answers)

Select 2 answers

A.Setting securityContext.seLinuxOptions.type

B.Using the seccomp.security.alpha.kubernetes.io/pod annotation

C.Using the container.apparmor.security.beta.kubernetes.io annotation

D.Using the seccomp.security.beta.kubernetes.io/pod annotation

E.Setting securityContext.seccompProfile.type

AnswersB, E

The seccomp.security.alpha.kubernetes.io/pod annotation was the original way to request seccomp enforcement, allowing values like localhost/profile.json or runtime/default. It is alpha-qualified and deprecated; since Kubernetes 1.19 the preferred expression is the seccompProfile field. The annotation still functions in many legacy clusters, but it has no beta counterpart and will be removed as the alpha API is abandoned.

Why this answer

The `seccomp.security.alpha.kubernetes.io/pod` annotation was the original method to apply a seccomp profile to a pod in Kubernetes versions prior to v1.19. This annotation allows you to specify a seccomp profile path (e.g., 'localhost/my-profile') or a runtime default ('runtime/default') directly on the pod, which then applies to all containers in the pod. Option E is correct because `securityContext.seccompProfile.type` is the current, stable API field (GA since v1.19) that sets the seccomp profile at the container or pod level, accepting values like 'RuntimeDefault', 'Localhost', or 'Unconfined'.

Exam trap

Kubernetes often tests the distinction between alpha (`seccomp.security.alpha.kubernetes.io/pod`) and beta (`seccomp.security.beta.kubernetes.io/pod`) annotations, where the beta version never existed for seccomp, causing candidates to confuse it with the AppArmor beta annotation pattern.

Full explanation →

108

MCQhard

You need to encrypt Kubernetes secrets at rest using aescbc. Which YAML snippet defines the EncryptionConfiguration correctly?

A.apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: MDEyMzQ1Njc4OWFiY2RlZjAxMjM0NTY3ODlhYmNkZWY= - identity: {} [CORRECT]

B.apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: my-plain-text-key

C.apiVersion: v1 kind: EncryptionConfig resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: c2VjcmV0LWtleS0zMi1ieXRlcw==

D.apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - secretbox: keys: - name: key1 secret: c2VjcmV0LWtleS0zMi1ieXRlcw==

AnswerA

This is correct because it uses the proper apiVersion `apiserver.config.k8s.io/v1` and kind `EncryptionConfiguration`, which matches what kube-apiserver expects. The `aescbc` provider is specified as required, and the key `c2VjcmV0LWtleS0zMi1ieXRlcw==` is a valid base64-encoded string that decodes to a 32-byte key, which is the required length for AES-256-CBC. Including `identity: {}` as the last provider is essential because it allows the API server to read existing unencrypted secrets during the migration process, avoiding data lockout, and it also serves as a fallback if decryption fails.

Why this answer

It defines an EncryptionConfiguration with the correct apiVersion (apiserver.config.k8s.io/v1), kind (EncryptionConfiguration), and a valid provider list. It uses the aescbc provider with a base64-encoded 32-byte key (MDEyMzQ1Njc4OWFiY2RlZjAxMjM0NTY3ODlhYmNkZWY=) for encrypting secrets, and includes the identity provider as a fallback to allow reading existing unencrypted data. This configuration ensures that secrets are encrypted at rest using AES-CBC with a properly encoded 32-byte key.

Exam trap

CNCF often tests the requirement that the aescbc provider's secret must be base64-encoded (not plain text) and that the correct apiVersion/kind must be used, leading candidates to pick options with plain-text keys or wrong resource types.

How to eliminate wrong answers

Option B is wrong because the secret value for the aescbc provider must be base64-encoded, not a plain-text key like 'my-plain-text-key'; Kubernetes expects the key to be base64-decoded to obtain the raw 32-byte key for AES-CBC. Option C is wrong because it uses an incorrect apiVersion 'v1' and kind 'EncryptionConfig' — the correct apiVersion is 'apiserver.config.k8s.io/v1' and kind is 'EncryptionConfiguration'. Option D is wrong because it uses the 'secretbox' provider, which implements XSalsa20-Poly1305 encryption, not AES-CBC; the question specifically requires aescbc.

Full explanation →

109

MCQhard

An administrator runs 'kubectl describe pod secure-pod' and sees that the pod is in a Pending state with the event 'Error: ImagePullBackOff' and the message 'unauthorized: authentication required'. The image is stored in a private registry. What is the most likely cause?

A.Missing imagePullSecret in the pod spec or in the namespace's default service account

B.The registry requires TLS 1.3 but the kubelet uses TLS 1.2

C.The image tag is misspelled

D.The registry hostname is not resolvable

AnswerA

The 'unauthorized' status in Kubernetes events indicates the image registry rejected the pull because the kubelet did not present valid credentials. Private registries require a kubernetes.io/dockerconfigjson secret referenced in the pod's `imagePullSecrets` field or in the pod's service account. If only the namespace's default service account has the secret and the pod explicitly uses another service account, the secret is not automatically attached, so replication and credential scoping must be checked.

Why this answer

The error 'unauthorized: authentication required' indicates that the kubelet cannot authenticate to the private registry. Kubernetes requires an imagePullSecret, which contains registry credentials (typically a Docker config JSON), to be attached either directly to the pod spec or to the namespace's default service account. Without this secret, the kubelet cannot pull the image, resulting in the ImagePullBackOff state.

Exam trap

The CKS exam often tests the distinction between authentication failures (ImagePullBackOff with 'unauthorized') and other pull errors (e.g., DNS, TLS, or image name issues), so candidates must recognize that 'authentication required' points specifically to missing or invalid registry credentials.

How to eliminate wrong answers

Option B is wrong because TLS version mismatch (e.g., kubelet using TLS 1.2 vs registry requiring TLS 1.3) would cause a TLS handshake failure, not an 'unauthorized: authentication required' message; the error would be something like 'tls: protocol version not supported'. Option C is wrong because a misspelled image tag would produce an 'ImagePullBackOff' with a 'manifest unknown' or 'not found' error, not an authentication error. Option D is wrong because an unresolvable registry hostname would cause a 'dial tcp: lookup' or 'no such host' error, not an authentication failure.

Full explanation →

110

Multi-Selectmedium

Which TWO of the following are valid ways to enforce that containers run with a read-only root filesystem?

Select 2 answers

A.Setting `runAsNonRoot: true` in the pod's securityContext

B.Using an emptyDir volume mounted at /

C.Setting `fsGroup: 1000` in the pod's securityContext

D.Using a MutatingWebhookConfiguration that adds `readOnlyRootFilesystem: true` to all containers

E.Setting `readOnlyRootFilesystem: true` in the container's securityContext

AnswersD, E

A MutatingWebhookConfiguration is a valid enforcement mechanism because it intercepts Pod create or update requests at admission time and mutates container specs before they are persisted. By injecting readOnlyRootFilesystem: true into every container, the webhook enforces the read-only root policy centrally, even when developers omit the field in their manifests. This is a common pattern for cluster-wide security controls.

Why this answer

A MutatingWebhookConfiguration can intercept Pod creation requests and automatically add the `readOnlyRootFilesystem: true` field to every container's securityContext, enforcing a read-only root filesystem without requiring manual changes to Pod specs. Option E is correct because setting `readOnlyRootFilesystem: true` directly in the container's securityContext is the explicit Kubernetes API field that makes the container's root filesystem read-only, preventing writes to the filesystem layer.

Exam trap

The CKS exam often tests the distinction between Pod-level and container-level securityContext fields, and candidates may incorrectly assume that Pod-level settings like `runAsNonRoot` or `fsGroup` affect the root filesystem's write permissions, when only the container-level `readOnlyRootFilesystem` field (or a mutating webhook) actually enforces that behavior.

Full explanation →

111

MCQmedium

You need to create a NetworkPolicy that allows only ingress traffic from pods with label 'app: frontend' in the same namespace. Which policyType and ingress rule should you use?

A.policyTypes: [Ingress] ingress: - from: - podSelector: matchLabels: app: frontend

B.policyTypes: [Ingress] ingress: - from: - podSelector: {}

C.policyTypes: [Ingress] ingress: - from: - namespaceSelector: {}

D.policyTypes: [Egress]

AnswerA

This NetworkPolicy correctly restricts inbound traffic: the `policyTypes` list explicitly includes `Ingress`, and the `ingress` rule uses a `podSelector` with `matchLabels: app: frontend`. This `podSelector` in the `from` field matches only source pods that carry the label `app=frontend` within the same namespace. Because a NetworkPolicy that selects a pod enforces default-deny for the specified policy types, this rule whitelists exactly the intended frontend pods while blocking all other ingress sources.

Why this answer

A NetworkPolicy that restricts ingress traffic to only pods with the label 'app: frontend' in the same namespace must use `policyTypes: [Ingress]` and an `ingress` rule with a `podSelector` that matches that label. The `podSelector` without a `namespaceSelector` implicitly selects pods only within the same namespace as the NetworkPolicy, which satisfies the requirement.

Exam trap

The trap here is that candidates often confuse `podSelector: {}` (which allows all pods in the namespace) with `podSelector` with specific labels, or they incorrectly add a `namespaceSelector` when the requirement explicitly says 'same namespace'.

How to eliminate wrong answers

Option B is wrong because `podSelector: {}` selects all pods in the namespace, which would allow ingress from any pod, not just those with label 'app: frontend'. Option C is wrong because `namespaceSelector: {}` selects all namespaces, allowing ingress from pods in any namespace, which violates the requirement to restrict to the same namespace. Option D is wrong because `policyTypes: [Egress]` only controls outbound traffic, not ingress traffic, so it cannot satisfy the requirement to allow only ingress traffic.

Full explanation →

112

MCQmedium

A security policy requires that all container images must have a signed attestation. Which Cosign command would an admin add to the CI pipeline to create this attestation?

A.cosign verify-attestation <image>

B.cosign sign --key <key> <image>

C.cosign download attestation <image>

D.cosign attest --type custom --predicate <file> <image>

AnswerD

cosign attest constructs an in-toto attestation in a DSSE envelope and signs it, binding the supplied predicate file to the image's digest. --type custom and --predicate <file> let you attach an arbitrary JSON/DSL predicate rather than a built-in provenance or SLSA type. This is the only command among the options that creates a new, signed attestation artifact, directly satisfying the security policy requirement.

Why this answer

The `cosign attest` command is specifically designed to create an in-toto attestation for a container image, attaching a signed predicate (e.g., a SLSA provenance file) that satisfies the policy requirement for a signed attestation. The `--type custom` flag allows specifying a custom predicate type, and `--predicate <file>` provides the attestation payload, which is then signed and stored in the image's OCI manifest as an attached attestation.

Exam trap

The CNCF CKS exam often tests the distinction between a simple image signature (`cosign sign`) and an attestation (`cosign attest`), where candidates mistakenly choose `cosign sign` because they think signing alone creates an attestation, but attestation requires a structured predicate and the `--type` flag.

How to eliminate wrong answers

Option A is wrong because `cosign verify-attestation` is used to verify an existing attestation, not to create one. Option B is wrong because `cosign sign --key <key> <image>` creates a simple signature on the image digest, not an attestation (which is a signed statement about the image's provenance or metadata). Option C is wrong because `cosign download attestation` retrieves an existing attestation from the registry, it does not create a new one.

Full explanation →

113

MCQhard

An audit policy is configured with the following rule: - level: RequestResponse users: ["system:serviceaccount:kube-system:admin"] verbs: ["get", "list"] resources: - group: "" resources: ["secrets"] What will be logged when the service account 'admin' in kube-system performs a GET request on a Secret?

A.Only the request metadata will be logged

B.Only the response will be logged

C.The request and response metadata and body will be logged

D.Nothing will be logged because the rule uses an empty api group

AnswerC

RequestResponse is the most verbose audit level. For any rule matched at this level, the audit event includes the complete request object and the complete response object, each with both metadata and body payloads. This includes the full submitted resource state and the returned status/object, so all request and response information is logged as the option correctly states.

Why this answer

The audit rule specifies `level: RequestResponse`, which instructs the API server to log both the request metadata and body, as well as the response metadata and body, for matching events. The rule matches the service account `system:serviceaccount:kube-system:admin` performing a GET on secrets (empty API group matches core API group), so the full request and response payloads are captured.

Exam trap

A common misconception is that an empty API group means 'no group' or 'invalid', but in Kubernetes audit policy, `group: ""` explicitly matches the core API group (e.g., pods, secrets, services), so the rule is valid and will log the event.

How to eliminate wrong answers

Option A is wrong because `RequestResponse` level logs both request and response metadata and body, not just request metadata (that would be `Request` level). Option B is wrong because `RequestResponse` logs both request and response, not only the response (no level logs only response). Option D is wrong because an empty `group: ""` in the resources section matches the core API group (e.g., `/api/v1`), which includes secrets, so the rule applies correctly.

Full explanation →

114

MCQhard

A custom seccomp profile is created at /var/lib/kubelet/seccomp/custom-profile.json. Which YAML snippet applies this profile to a container?

A.securityContext: seccompProfile: type: Localhost localhostProfile: custom-profile.json

B.securityContext: seccompProfile: type: Unconfined

C.securityContext: seccompProfile: type: RuntimeDefault localhostProfile: custom-profile.json

D.securityContext: seccomp: profile: custom-profile.json

AnswerA

The correct structure uses seccompProfile.type: Localhost to indicate that a profile file is stored on the node, and localhostProfile: custom-profile.json to reference that specific file. The kubelet looks for the file in the node's seccomp profile directory (typically /var/lib/kubelet/seccomp) and loads it to restrict syscalls for the container. This is the only syntax in the current Kubernetes API that directly applies a custom local seccomp profile.

Why this answer

When using a custom seccomp profile stored on the node, the `type: Localhost` field must be set, and the `localhostProfile` field specifies the filename (relative to the kubelet's seccomp root directory, which defaults to `/var/lib/kubelet/seccomp`). This configuration tells the container runtime to load the profile from the node's filesystem at the path `/var/lib/kubelet/seccomp/custom-profile.json`.

Exam trap

The CKS exam often tests the distinction between the `seccompProfile` field (correct in Kubernetes 1.19+) and the older `seccomp` annotation-based syntax, and candidates mistakenly choose option D because they remember the old annotation format or confuse `profile` with `localhostProfile`.

How to eliminate wrong answers

Option B is wrong because `type: Unconfined` disables seccomp entirely, which does not apply any custom profile and is the opposite of what the question asks. Option C is wrong because `type: RuntimeDefault` uses the container runtime's default seccomp profile, and specifying `localhostProfile` alongside `RuntimeDefault` is invalid; the `localhostProfile` field is only used when `type: Localhost` is set. Option D is wrong because the correct API field is `seccompProfile` (not `seccomp`), and the subfield for the profile name is `localhostProfile` (not `profile`); this syntax is from an older, deprecated API version.

Full explanation →

115

MCQhard

A compromised pod is making unexpected outbound connections. You want to isolate the pod by blocking all egress traffic while keeping it running for forensic analysis. Which action is correct?

A.Use kubectl exec to kill the outbound processes inside the container

B.Apply a NetworkPolicy that selects the pod and has no egress rules, effectively blocking all outbound traffic

C.Modify the pod's /etc/hosts to block external IPs

D.Delete the pod and recreate it with a restrictive NetworkPolicy

AnswerB

A NetworkPolicy that selects the compromised pod and specifies an empty egress rule list (e.g., `egress: []`) enforces a default-deny model for all outbound traffic. Because NetworkPolicy rules are additive—only traffic explicitly allowed by a matching rule passes—an empty list allows nothing, effectively containing the pod while preserving its state for forensics. For this to work, the cluster must run a CNI that implements NetworkPolicy, such as Calico, Cilium, or Weave Net. Alternatively, setting `policyTypes: [Egress]` with no egress rules achieves the same isolation.

Why this answer

Applying a NetworkPolicy that selects the pod with no egress rules blocks all outbound traffic while leaving the pod running, which is exactly what forensic isolation requires. In Kubernetes, once a pod is selected by a NetworkPolicy with an egress policy type, only explicitly allowed egress is permitted — an empty egress rule set means deny all. This preserves the pod's state and memory for analysis.

Exam trap

CKS often tests whether candidates understand that NetworkPolicy is additive and that an empty egress rule set means deny-all; a common mistake is thinking you must delete the pod or that /etc/hosts changes provide isolation.

How to eliminate wrong answers

Option A is wrong because killing processes inside the container alters the compromised state and may destroy forensic evidence, and it does not guarantee all outbound traffic stops. Option C is wrong because modifying /etc/hosts only affects name resolution for some applications and does not block traffic to IP addresses or other resolution paths. Option D is wrong because deleting the pod destroys volatile evidence (memory, running processes) and violates the requirement to keep it running for forensic analysis.

Full explanation →

116

MCQmedium

You need to enforce that all images deployed in the cluster are signed by a trusted key. Which Kubernetes admission control mechanism would you use?

A.ResourceQuota

B.NetworkPolicy

C.PodSecurityPolicy

D.ImagePolicyWebhook

AnswerD

ImagePolicyWebhook is a Kubernetes admission controller that intercepts pod creation and sends the image references to an external HTTP(S) webhook for evaluation. This external service can verify image signatures against trusted keys, enforce allowlists of registries, or require specific digests, effectively blocking unsigned or disallowed images. Because it runs during the admission phase, it can deny a pod's creation before it is persisted, making it an appropriate tool for enforcing a cluster-wide image signature policy.

Why this answer

The ImagePolicyWebhook admission controller is specifically designed to enforce that container images are signed by a trusted key. It intercepts Pod creation requests and validates the image signatures against a configured webhook endpoint, rejecting unsigned or untrusted images. This directly addresses the requirement for supply chain security by ensuring only cryptographically verified images are deployed.

Exam trap

The trap here is that candidates may confuse PodSecurityPolicy (which deals with pod security contexts) with image trust enforcement, but PodSecurityPolicy never validates image signatures—it only controls runtime security attributes.

How to eliminate wrong answers

Option A is wrong because ResourceQuota is used to limit resource consumption (CPU, memory, storage) per namespace, not to validate image signatures. Option B is wrong because NetworkPolicy controls pod-to-pod and pod-to-service network traffic using labels and ports, not image signing or trust. Option C is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) enforces security context constraints like privileged containers, host namespaces, and volume types, but does not validate image signatures or trust.

Full explanation →

117

MCQhard

You need to configure a NetworkPolicy that allows egress traffic only to an external database at IP 10.0.0.5 on port 5432, and denies all other egress. Which policy BEST achieves this?

A.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-egress spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 0.0.0.0/0 ports: - port: 5432

B.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-egress spec: podSelector: {} policyTypes: - Egress egress: - to: - podSelector: matchLabels: app: db

C.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-egress spec: podSelector: {} policyTypes: - Egress egress: []

D.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-egress spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 10.0.0.5/32 ports: - port: 5432

AnswerD

The ipBlock with CIDR 10.0.0.5/32 precisely identifies the database's IP address, and the port 5432 restricts traffic to the database listener, thereby permitting only the intended communication. Because policyTypes includes Egress and this is the sole egress rule, it also establishes an implicit default-deny for any other outbound traffic, aligning with least-privilege security. This is the correct configuration for allowing egress to a specific external IP and port.

Why this answer

The correct policy uses an ipBlock with cidr 10.0.0.5/32 and port 5432, which precisely allows egress only to that single external database IP on the PostgreSQL port. Because policyTypes includes Egress and the egress rule is the only one, all other egress traffic is implicitly denied. This matches the requirement exactly.

Exam trap

CKS often tests the trap of using 0.0.0.0/0 with a port filter, which looks restrictive but actually allows any destination on that port — candidates must verify the CIDR matches the exact target IP.

How to eliminate wrong answers

Option A is wrong because cidr 0.0.0.0/0 allows egress to any IP on port 5432, not just 10.0.0.5 — it violates the 'only to external database' requirement. Option B is wrong because podSelector matches pods by label within the cluster, not an external IP; it would not allow traffic to 10.0.0.5 and would instead allow traffic to labeled pods. Option C is wrong because an empty egress list (egress: []) denies all egress traffic, including the required database connection, so it blocks everything.

Full explanation →

118

Multi-Selecthard

Which THREE of the following are valid methods to disable automount of service account tokens for a pod?

Select 3 answers

A.Set --service-account-issuer flag on API server

B.Set env: - name: KUBERNETES_SERVICE_ACCOUNT_TOKEN to false

C.Set automountServiceAccountToken: false in the ServiceAccount YAML

D.Set spec.automountServiceAccountToken: false in the Pod spec

E.Use the 'default' service account with automount disabled

AnswersC, D, E

Setting `automountServiceAccountToken: false` in a ServiceAccount YAML disables automatic token mounting for every Pod that explicitly references that ServiceAccount. This is the standard way to revoke the default API credentials for workloads that use a dedicated service account. If a Pod sets `spec.automountServiceAccountToken` to true, that pod-level field overrides the ServiceAccount-level false.

Why this answer

Setting `automountServiceAccountToken: false` in the ServiceAccount YAML disables automatic mounting of the service account token for all pods that use that ServiceAccount. This is a declarative way to prevent the Kubernetes API server from injecting the token volume into pods, which is a key security hardening step to reduce the attack surface from compromised pods.

Exam trap

CNCF often tests the distinction between the Pod spec field (`spec.automountServiceAccountToken`) and the ServiceAccount field, and candidates may incorrectly think that environment variables or API server flags can disable token mounting, when only the `automountServiceAccountToken` boolean field in the Pod or ServiceAccount spec is valid.

Full explanation →

119

MCQhard

A cluster runs Kubernetes 1.29 with the AppArmor support enabled. A pod manifest sets securityContext.appArmorProfile.type to Localhost with localhostProfile: k8s-nginx. The pod stays in ContainerCreating and the kubelet logs show a failed to apply AppArmor profile error. Which action most directly resolves the failure?

A.Install the AppArmor profile into the container image at /etc/apparmor.d/k8s-nginx and restart the pod.

B.Add the k8s-nginx profile to the kube-apiserver's --apparmor-profile flag.

C.Change the profile type to RuntimeDefault so the container inherits the runtime's default AppArmor profile.

D.Load the k8s-nginx profile into the kernel on every node in the cluster with apparmor_parser -r before the pod is scheduled.

AnswerD

The Localhost AppArmor type requires the named profile to already be loaded into the kernel on the node where the pod runs. The kubelet does not load profiles from the manifest; it only references them. Running apparmor_parser to load k8s-nginx on each eligible node makes the profile available so the runtime can apply it and the container can start.

Why this answer

Localhost AppArmor profiles must exist in the node kernel before a pod referencing them can start. The kubelet and container runtime only look up the named profile; they do not load it. Loading k8s-nginx with apparmor_parser on each node that may run the pod makes the profile resolvable, allowing the container to be created under the intended policy.

Exam trap

The trap here is thinking the kubelet or the API server loads the AppArmor profile named in the pod spec, when in fact the profile must already be loaded into the node kernel.

Full explanation →

120

MCQhard

A pod is configured with securityContext: { seccompProfile: { type: RuntimeDefault } }. Which of the following is true about this configuration?

A.The pod uses a custom seccomp profile

B.Seccomp is disabled for the pod

C.The pod must have CAP_SYS_ADMIN to use this setting

D.The pod uses the default seccomp profile provided by the container runtime

AnswerD

RuntimeDefault instructs the kubelet to apply the container runtime's own preconfigured seccomp profile, such as containerd's or CRI-O's default, rather than a custom or unconfined policy. This restricts syscalls without requiring a profile file on the node.

Why this answer

Setting `seccompProfile.type: RuntimeDefault` in the pod's securityContext instructs the container runtime (e.g., containerd, CRI-O) to apply its own default seccomp profile, which is typically a restrictive profile that blocks a large set of syscalls. This is the recommended approach for enabling seccomp without needing to define a custom profile, and it is available in Kubernetes v1.19+.

Exam trap

The CKS exam often tests the distinction between `RuntimeDefault`, `Localhost`, and `Unconfined` — the trap here is confusing `RuntimeDefault` with a custom profile or thinking it requires special capabilities, when in fact it is a simple, runtime-provided default that requires no extra privileges.

How to eliminate wrong answers

Option A is wrong because `RuntimeDefault` explicitly uses the runtime's built-in default profile, not a custom one; a custom profile would be specified with `type: Localhost` and a `localhostProfile` path. Option B is wrong because `RuntimeDefault` enables seccomp enforcement using the runtime's default profile, it does not disable seccomp; disabling seccomp would be `type: Unconfined`. Option C is wrong because no special capability like `CAP_SYS_ADMIN` is required to use `RuntimeDefault`; the seccomp profile is applied by the runtime without requiring additional privileges in the pod's security context.

Full explanation →

121

MCQmedium

A pod is created with the following security context: securityContext: seccompProfile: type: Localhost localhostProfile: profiles/audit.json Where must the 'audit.json' file be placed on the node?

A./etc/kubernetes/seccomp/profiles/audit.json

B./var/lib/kubelet/audit.json

C./var/lib/kubelet/seccomp/profiles/audit.json

D./var/lib/containerd/seccomp/audit.json

AnswerC

This is the correct location because the kubelet's default `--seccomp-profile-root` is `/var/lib/kubelet/seccomp`, and the standard practice is to place profile JSON files in a `profiles` subdirectory beneath that root. When a pod references `seccompProfile.type: Localhost` with `localhostProfile: profiles/audit.json`, the kubelet resolves the path to exactly `/var/lib/kubelet/seccomp/profiles/audit.json` and passes the file to the container runtime via CRI. This aligns with Kubernetes documentation and distribution defaults, making it the only viable path for the kubelet to find the profile.

Why this answer

When a pod uses a `seccompProfile` of type `Localhost` with `localhostProfile: profiles/audit.json`, the file path is relative to the kubelet's seccomp root directory, which defaults to `/var/lib/kubelet/seccomp`. Therefore, the complete path on the node must be `/var/lib/kubelet/seccomp/profiles/audit.json`. This is the only location where the kubelet will look for the seccomp profile when `type: Localhost` is specified.

Exam trap

The CNCF CKS exam often tests the default seccomp profile root path (`/var/lib/kubelet/seccomp`) and the fact that `localhostProfile` is relative to that root, not an absolute path or a path under `/etc/kubernetes` or containerd directories.

How to eliminate wrong answers

Option A is wrong because `/etc/kubernetes/seccomp/profiles/audit.json` is not the default root for seccomp profiles; the kubelet uses `/var/lib/kubelet/seccomp` as its base directory. Option B is wrong because `/var/lib/kubelet/audit.json` places the file directly under the kubelet directory, but the seccomp profile must be inside the `seccomp/profiles/` subdirectory relative to the kubelet's seccomp root. Option D is wrong because `/var/lib/containerd/seccomp/audit.json` is a containerd-specific path, not the kubelet's seccomp profile directory; the kubelet does not look for seccomp profiles in containerd's data directory.

Full explanation →

122

Multi-Selecthard

Which THREE of the following are best practices for securing a Kubernetes cluster using OPA Gatekeeper? (Choose three.)

Select 3 answers

A.Enforce that containers set runAsNonRoot: true.

B.Enforce that containers do not mount hostPath volumes with read-write access.

C.Allow privileged containers for system-critical workloads.

D.Allow containers to use hostNetwork for easier service discovery.

E.Enforce that containers set seccompProfile.type to RuntimeDefault or Localhost.

AnswersA, B, E

Setting runAsNonRoot: true is a core Pod Security Standard (PSS) restricted requirement. It forces the container process to run with a non-zero UID, which reduces the likelihood of privilege escalation if the container is compromised, because root inside a container often maps to host root. However, it assumes the container image already defines a non-root user, so the image must be built accordingly. This control is fundamental to least privilege and is commonly enforced via Pod Security Admission or policy engines like OPA/Gatekeeper.

Why this answer

Enforcing `runAsNonRoot: true` via OPA Gatekeeper ensures that containers run with a non-root user ID, mitigating the risk of privilege escalation attacks. This aligns with the Kubernetes Pod Security Standards (PSS) 'restricted' profile and is a key control for minimizing microservice vulnerabilities.

Exam trap

The CKS exam often tests the misconception that privileged containers are acceptable for 'critical' workloads, but the CKS exam expects a zero-trust approach where no containers run privileged, and hostNetwork is restricted to only explicitly authorized system pods.

Full explanation →

123

Multi-Selecthard

Which TWO of the following are valid methods to enforce mTLS in an Istio service mesh? (Select 2)

Select 2 answers

A.Create a ServiceEntry for internal services

B.Create a VirtualService with tls termination

C.Create a PeerAuthentication resource with mtls.mode: STRICT

D.Set global.mtls.enabled: true in IstioConfigMap

E.Create a DestinationRule with tls.mode: ISTIO_MUTUAL

AnswersC, E

PeerAuthentication is a native Istio security policy that defines how sidecar proxies accept inbound traffic. Setting mtls.mode: STRICT enforces that the server side requires mutual TLS, rejecting any plaintext or non-mutual TLS requests. This works at the sidecar proxy level and applies per namespace, workload, or globally through the mesh root, making it the canonical server-side enforcement mechanism.

Why this answer

A PeerAuthentication resource with `mtls.mode: STRICT` enforces mutual TLS at the service-to-service communication level within the Istio mesh. This setting ensures that all traffic between sidecar proxies uses mTLS, rejecting any plaintext connections, which directly minimizes the risk of unauthorized access or eavesdropping.

Exam trap

Candidates often confuse the legacy global settings (like `global.mtls.enabled` in ConfigMap) with the modern, granular Istio security resources (PeerAuthentication and DestinationRule), leading them to mistakenly select the deprecated option D.

Full explanation →

124

Drag & Dropmedium

Order the steps to configure and use Falco for runtime security in a Kubernetes cluster.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Falco installation, configuration, deployment as DaemonSet, monitoring alerts, and tuning are the key steps.

Full explanation →

125

MCQmedium

A security audit reveals that a service account in the 'default' namespace has been granted cluster-admin privileges via a ClusterRoleBinding. What is the best mitigation?

A.Disable the service account token automount

B.Delete the service account

C.Modify the ClusterRoleBinding to use a less privileged role

D.Set --authorization-mode=AlwaysDeny

AnswerC

This is the correct mitigation because it directly removes the excessive permissions by changing the subject of the ClusterRoleBinding to a least-privilege ClusterRole or by using namespace-scoped RoleBindings. RBAC decisions are evaluated at request time, so the change takes effect immediately, preserving the service account for legitimate workloads while eliminating its global cluster-admin capabilities.

Why this answer

The best practice is to apply the principle of least privilege: instead of deleting the service account or disabling its token, you should modify the ClusterRoleBinding to bind the service account to a ClusterRole with only the permissions it actually needs. This retains the service account's functionality while removing excessive cluster-admin privileges, which grant unrestricted access to all cluster resources.

Exam trap

The trap here is that candidates often think disabling the token automount or deleting the service account removes the RBAC permissions, but in reality, the ClusterRoleBinding itself must be updated or deleted to actually revoke the granted privileges.

How to eliminate wrong answers

Option A is wrong because disabling the service account token automount (e.g., via automountServiceAccountToken: false) prevents the token from being mounted into pods, but it does not revoke the already-granted cluster-admin privileges; the ClusterRoleBinding remains in effect. Option B is wrong because deleting the service account removes the identity, but any pods or workloads that depend on it will fail, and the ClusterRoleBinding would become orphaned (pointing to a non-existent subject), which is a disruptive and incomplete fix. Option D is wrong because setting --authorization-mode=AlwaysDeny on the API server would deny all requests cluster-wide, breaking all administrative and workload operations, and is not a targeted mitigation for an over-privileged binding.

Full explanation →

126

MCQmedium

You are reviewing RBAC permissions and notice a ClusterRoleBinding that binds the cluster-admin role to a service account in the 'monitoring' namespace. What is the best practice recommendation?

A.Keep the binding as it is required for monitoring

B.Delete the service account

C.Replace cluster-admin with a custom Role granting only necessary permissions

D.Change the binding to a RoleBinding in the monitoring namespace

AnswerC

Replace the ClusterRoleBinding referencing cluster-admin with a custom ClusterRole that contains only the API verbs and resources required for monitoring, such as get, list, and watch on pods, nodes, events, and related metrics. This follows the principle of least privilege and limits the blast radius if the service account credentials are compromised. If monitoring needs to inspect non-namespaced resources like nodes, use a ClusterRole with a ClusterRoleBinding; if it only needs one namespace, a Role and RoleBinding suffice.

Why this answer

The principle of least privilege dictates that a service account should only have the permissions necessary for its function. The cluster-admin role grants superuser access across the entire cluster, which is excessive for a monitoring service account. Replacing it with a custom Role that includes only the required API operations (e.g., get, list, watch on pods and nodes) reduces the attack surface and aligns with Kubernetes security best practices.

Exam trap

CNCF often tests the misconception that a RoleBinding can replace a ClusterRoleBinding for cluster-scoped tasks, but a RoleBinding cannot grant access to cluster-scoped resources like nodes or persistent volumes, so candidates must recognize when a ClusterRoleBinding is necessary even after reducing permissions.

How to eliminate wrong answers

Option A is wrong because keeping a cluster-admin binding for a monitoring service account violates the principle of least privilege and unnecessarily exposes the cluster to privilege escalation if the service account is compromised. Option B is wrong because deleting the service account would break the monitoring functionality; the correct approach is to adjust its permissions, not remove it entirely. Option D is wrong because changing to a RoleBinding in the monitoring namespace would restrict permissions to that namespace only, but the monitoring service account likely needs cluster-scoped access (e.g., to read node metrics) and a RoleBinding cannot grant cluster-scoped permissions.

Full explanation →

127

MCQmedium

A security admin runs 'trivy image --severity CRITICAL,HIGH myrepo/myapp:latest' and sees many CVEs. The admin wants to ensure that only images with no CRITICAL or HIGH severity vulnerabilities are deployed to the cluster. Which admission controller should be configured to enforce this policy?

A.PodSecurityPolicy

B.ValidatingAdmissionWebhook

C.MutatingAdmissionWebhook

D.ImagePolicyWebhook

AnswerD

ImagePolicyWebhook is the Kubernetes-native admission controller that delegates image policy decisions to an external backend service. When a Pod is created, it sends an ImagePolicyReview containing the container image references to a configured HTTPS backend, which returns an allow or deny response based on the organization's policy—such as rejecting images that Trivy flagged as critical or high. This is the correct mechanism to integrate image vulnerability scanning into the admission path, and it is the only option listed that is purpose-built for this exact scenario.

Why this answer

The ImagePolicyWebhook admission controller is specifically designed to evaluate container images against an external policy backend before they are admitted into the cluster. By configuring it to reject images with CRITICAL or HIGH severity vulnerabilities (as reported by Trivy), the admin can enforce that only compliant images are deployed. This controller intercepts Pod creation requests and queries an external webhook to decide whether to allow or deny the image based on the policy.

Exam trap

The CKS exam often tests the distinction between generic admission webhooks (ValidatingAdmissionWebhook, MutatingAdmissionWebhook) and the purpose-built ImagePolicyWebhook, leading candidates to choose a generic webhook when the question explicitly asks for the controller designed for image policy enforcement.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) enforces security context constraints on Pods (e.g., privileged containers, host namespaces), not image vulnerability policies. Option B is wrong because ValidatingAdmissionWebhook can be used to validate arbitrary resources, but it is a generic mechanism that requires writing a custom webhook; the question specifically asks for the admission controller designed for image policy enforcement, which is ImagePolicyWebhook. Option C is wrong because MutatingAdmissionWebhook modifies resources during admission (e.g., injecting sidecars), but it does not perform image vulnerability checks or enforce image policies based on severity.

Full explanation →

128

MCQeasy

Which of the following is the correct command to load an AppArmor profile from a file named 'my-profile'?

A.apparmor_load my-profile

B.apparmor_parser my-profile

C.apparmor_parser -R my-profile

D.systemctl start apparmor my-profile

AnswerB

apparmor_parser my-profile is the correct way to load an AppArmor profile: it reads the profile file, validates its syntax, compiles it into binary policy, and writes it to the kernel's AppArmor securityfs interface. Once loaded, the kernel enforces the profile's rules against the target process. This command is the standard tool for both loading and replacing profiles (the -a flag explicitly adds a profile).

Why this answer

The correct command to load an AppArmor profile from a file is `apparmor_parser my-profile`. The `apparmor_parser` tool is used to load, replace, or remove AppArmor profiles into the kernel. When invoked without flags, it loads the profile from the specified file into the kernel's AppArmor security module, enforcing the defined access controls.

Exam trap

The trap here is that candidates confuse `apparmor_parser` with a hypothetical `apparmor_load` command or misuse the `-R` flag, thinking it stands for 'run' or 'reload' instead of 'remove'.

How to eliminate wrong answers

Option A is wrong because `apparmor_load` is not a valid command; the correct tool is `apparmor_parser`. Option C is wrong because `apparmor_parser -R my-profile` removes (unloads) the profile from the kernel, not loads it. Option D is wrong because `systemctl start apparmor my-profile` is invalid syntax; `systemctl` manages the AppArmor service itself (e.g., `systemctl start apparmor`), not individual profiles, and passing a profile name as an argument is not supported.

Full explanation →

129

Multi-Selecthard

Which THREE of the following are required to secure etcd in a Kubernetes cluster?

Select 3 answers

A.Configure RBAC for etcd

B.Allow anonymous access for monitoring

C.Require client certificate authentication

D.Enable encryption at rest for secrets

E.Use TLS for peer and client communication

AnswersC, D, E

Requiring client certificate authentication ensures that every request to etcd comes from a verified client, such as the Kubernetes API server. The etcd server validates the client's certificate against a trusted CA, preventing unauthorized or forged clients from connecting. This mutual TLS authentication is a foundational requirement because without it, attackers could directly query or alter cluster data, bypassing API server controls.

Why this answer

Etcd requires client certificate authentication to verify the identity of clients (such as kube-apiserver) connecting to it. Without mutual TLS (mTLS), an attacker could impersonate a legitimate client and read or modify cluster state, including secrets and configuration data.

Exam trap

CNCF often tests the misconception that etcd has its own RBAC or that anonymous access can be safely allowed for monitoring, when in fact etcd relies solely on TLS certificate authentication and encryption at rest is a separate mandatory control.

Full explanation →

130

MCQhard

An administrator wants to use OPA Gatekeeper to enforce that all pods have a resource limits section defined. Which of the following is the correct combination to implement this policy?

A.Create a NetworkPolicy to block pods without limits.

B.Create a MutatingWebhookConfiguration to add resource limits automatically.

C.Create a ValidatingWebhookConfiguration that calls an external service to validate pod limits.

D.Create a ConstraintTemplate with a Rego policy that checks for 'spec.containers[*].resources.limits', then create a Constraint targeting pods.

AnswerD

OPA Gatekeeper enforces policies through two CRDs: ConstraintTemplate, which defines a policy using Rego (e.g., checking that `spec.containers[*].resources.limits` exists), and Constraint, which instantiates that template for a specific target like pods. The Rego rule iterates over all containers and generates a violation if any container lacks limits, causing the admission controller to reject the pod. This is the canonical and prescribed method for using Gatekeeper to enforce resource-limit requirements.

Why this answer

OPA Gatekeeper enforces policies via two Kubernetes custom resources: a ConstraintTemplate that contains the Rego policy logic (here, checking that every container has spec.containers[*].resources.limits), and a Constraint that instantiates the template and scopes it to specific resources (e.g., Pods). Together they register a ValidatingWebhookConfiguration behind the scenes to reject noncompliant pods.

Exam trap

The trap is confusing the underlying mechanism (ValidatingWebhookConfiguration) with the user-facing abstraction (ConstraintTemplate + Constraint); candidates who know Gatekeeper uses a webhook often pick the webhook option instead of the correct CRD-based answer.

How to eliminate wrong answers

Option A is wrong because NetworkPolicy operates at L3/L4 to control pod traffic; it has no visibility into pod spec fields like resource limits. Option B is wrong because a MutatingWebhookConfiguration modifies requests (e.g., injecting limits) rather than enforcing a validation policy; Gatekeeper's purpose here is to reject, not mutate. Option C is wrong because while Gatekeeper does use a ValidatingWebhookConfiguration internally, manually creating one that calls an external service is not how Gatekeeper policies are authored — the correct abstraction is ConstraintTemplate + Constraint.

Full explanation →

131

MCQmedium

An organization uses Kyverno to enforce policies. Which Kyverno rule action would you use to require that all images come from a specific registry?

A.verifyImages

B.generate

C.mutate

D.validate

AnswerD

The validate action checks incoming resources against a matching rule and rejects those that fail, so a rule requiring images from a specific registry blocks any pod whose image path does not match. Mutate would rewrite rather than enforce, and generate only creates supporting resources.

Why this answer

The `validate` action in Kyverno is used to enforce policies that check resource attributes against specified rules. To require that all images come from a specific registry, you would use a `validate` rule with a pattern or deny clause that inspects the image field (e.g., `spec.containers[*].image`) and rejects any that do not match the allowed registry prefix. This ensures non-compliant resources are blocked at admission time.

Exam trap

A common trap is confusing `validate` (which rejects non-compliant resources) with `mutate` (which modifies resources). For requiring a specific registry, only `validate` can block disallowed images at admission time.

How to eliminate wrong answers

Option A is wrong because `verifyImages` is used for image signature verification (e.g., checking cosign signatures or attestations), not for enforcing a specific registry source. Option B is wrong because `generate` creates new resources based on a trigger resource (e.g., creating a NetworkPolicy when a Namespace is created), not for validating existing resource fields. Option C is wrong because `mutate` modifies resources to meet policy requirements (e.g., adding labels or sidecars), but it does not block non-compliant images; it only alters them, which is insufficient for enforcing a mandatory registry.

Full explanation →

132

MCQmedium

A pod is running with AppArmor enabled using a profile named 'k8s-apparmor-profile'. You want to verify that the profile is loaded and set to enforce mode. Which command should you run on the node?

A.aa-status

B.aa-profile --status

C.aa-enabled

D.cat /sys/kernel/security/apparmor/profiles

AnswerA

aa-status enumerates every loaded AppArmor profile and reports whether each is in enforce or complain mode. Running it on the node confirms both that k8s-apparmor-profile is loaded into the kernel and that it is actively enforcing, satisfying the verification requirement.

Why this answer

`aa-status` is the standard AppArmor utility that displays the status of AppArmor, including which profiles are loaded and their enforcement mode (enforce, complain, or unconfined). Running this command on the node will show whether 'k8s-apparmor-profile' is loaded and set to enforce mode, which directly answers the verification requirement.

Exam trap

The trap here is that candidates may confuse `aa-enabled` (which only checks if AppArmor is enabled) with `aa-status` (which shows loaded profiles and their modes), or they may think the raw kernel interface file is the correct answer, but the CKS exam expects knowledge of the standard user-space tool `aa-status` for verification.

How to eliminate wrong answers

Option B is wrong because `aa-profile --status` is not a valid AppArmor command; the correct command to check profile status is `aa-status` or `apparmor_status`. Option C is wrong because `aa-enabled` only checks if AppArmor is enabled on the system (returns 0 if enabled, 1 if not), but it does not list loaded profiles or their enforcement mode. Option D is wrong because while `cat /sys/kernel/security/apparmor/profiles` does list loaded profiles and their modes, it is a raw kernel interface that may not be available in all environments (e.g., containers or systems without securityfs mounted) and is less user-friendly than `aa-status`; the question asks for a command to run, and `aa-status` is the standard, reliable tool.

Full explanation →

133

MCQhard

A security policy requires that all communication to etcd be encrypted. Which two components must be configured with TLS certificates to achieve this? (Select two)

A.kubelet

B.kube-apiserver

C.kube-scheduler

D.kube-controller-manager

E.etcd

AnswerB, E

The API server connects to etcd as a client.

Why this answer

The kube-apiserver is the only control plane component that directly communicates with etcd. To encrypt this communication, TLS certificates must be configured on both the kube-apiserver (as client) and etcd (as server). The other components (kubelet, kube-scheduler, kube-controller-manager) do not directly interact with etcd, so they do not need etcd-specific TLS configuration.

Exam trap

The trap here is that candidates often assume all control plane components (scheduler, controller-manager) communicate directly with etcd, but in reality only the kube-apiserver interacts with etcd, while the others only talk to the apiserver.

How to eliminate wrong answers

Option A is wrong because the kubelet communicates with the kube-apiserver, not directly with etcd, so its TLS configuration is for node-to-apiserver encryption, not etcd communication. Option C is wrong because the kube-scheduler communicates only with the kube-apiserver via HTTPS, not directly with etcd, and thus does not require TLS certificates for etcd encryption. Option D is wrong because the kube-controller-manager also communicates solely with the kube-apiserver, not with etcd directly, so its TLS setup is irrelevant to encrypting etcd traffic.

Full explanation →

134

MCQhard

A Kubernetes cluster uses the ImagePolicyWebhook admission controller to enforce image signature verification. The administrator notices that pods are being admitted even when the webhook backend is unreachable. The cluster is configured with defaultAllow: true in the admission configuration. What is the most likely cause of this behavior?

A.The webhook backend is not configured with a valid TLS certificate, causing the API server to skip the webhook.

B.The defaultAllow: true setting in the admission configuration causes the API server to allow pods when the webhook fails to respond.

C.The ImagePolicyWebhook admission controller is not enabled in the API server's --enable-admission-plugins flag.

D.The webhook backend is returning an allow response for all requests due to a misconfiguration in its policy logic.

AnswerB

The defaultAllow field in the ImagePolicyWebhook configuration determines the fallback behavior when the webhook backend cannot be reached. When set to true, the API server allows the pod to be admitted if the webhook call fails (e.g., due to network issues or backend downtime). This explains why pods are admitted despite the webhook being unreachable. Setting it to false would deny pods on webhook failure.

Why this answer

The defaultAllow field in the ImagePolicyWebhook admission configuration controls whether pods are admitted when the webhook backend is unreachable. When set to true, the API server allows pods on webhook failure, which explains the observed behavior. The other options either do not apply because the webhook is configured and attempted, or they describe different failure modes.

Exam trap

The trap here is assuming that a webhook failure always results in denial, but the defaultAllow setting can override that to allow.

Full explanation →

135

Multi-Selectmedium

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

Select 3 answers

A.Sign images with Cosign after building

B.Generate an SBOM for each image

C.Scan container images for vulnerabilities using Trivy

D.Use a non-minimal base image to ensure all libraries are available

E.Store secrets in the Dockerfile as build args

AnswersA, B, C

Cosign signing produces a verifiable signature binding the image digest to a trusted identity, enabling admission policies to reject unsigned artefacts. This satisfies the supply-chain requirement by proving provenance and integrity from build through deployment.

Why this answer

Option A is correct because signing images with Cosign (part of the Sigstore project) after building produces a cryptographic signature that allows downstream consumers and admission controllers to verify image provenance and integrity, preventing tampered or unauthorized images from being deployed. Option B is correct because generating a Software Bill of Materials (SBOM) for each image provides a machine-readable inventory of components and dependencies, enabling rapid vulnerability triage and license/compliance auditing when new CVEs emerge. Option C is correct because scanning container images with Trivy detects known CVEs in OS packages and application dependencies before the image is promoted, catching vulnerabilities early in the CI/CD pipeline.

Option D is incorrect because best practice favors minimal base images (e.g., distroless or Alpine) to reduce attack surface, not bloated images with unnecessary libraries. Option E is incorrect because storing secrets in a Dockerfile as build args embeds them in image layers and build history, exposing them to anyone who can pull the image; secrets should instead come from a vault or secret manager at runtime.

Exam trap

CNCF-CKS often tests the misconception that a larger base image is more secure because it includes more libraries, when in fact minimal images (e.g., distroless or scratch) reduce the attack surface and are a supply chain best practice.

Full explanation →

136

MCQmedium

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

A.--audit-log-path and --audit-log-maxage

B.--audit-policy-file and --audit-log-maxbackup

C.--audit-log-path and --audit-policy-file

D.--audit-log-path and --authorization-mode=RBAC

AnswerC

Both flags are required for functional audit logging: --audit-log-path tells the kube-apiserver where to write the audit log file, and --audit-policy-file supplies a YAML manifest that specifies which events (e.g., RequestResponse, Metadata) should be logged and at which stages. Without either one, the audit subsystem either lacks a destination or lacks the filtering rules that determine what to capture; together they form the minimal set needed to enable audit logging effectively.

Why this answer

To enable audit logging in the Kubernetes API server, you must specify both an audit policy file (using --audit-policy-file) to define which events should be logged and at what level, and a log file path (using --audit-log-path) to specify where the audit logs should be written. Without the policy file, the API server does not know which requests to audit; without the log path, the audit events have no output destination.

Exam trap

CNCF often tests the distinction between mandatory flags (--audit-log-path and --audit-policy-file) and optional retention flags (--audit-log-maxage, --audit-log-maxbackup, --audit-log-maxsize), leading candidates to select options that include only retention flags or mix authorization flags with audit flags.

How to eliminate wrong answers

Option A is wrong because --audit-log-maxage is an optional flag that controls the maximum number of days to retain old audit log files, but it is not required to enable audit logging; the two mandatory flags are --audit-log-path and --audit-policy-file. Option B is wrong because --audit-log-maxbackup is also an optional flag that sets the maximum number of old audit log files to retain, and it does not replace the need for --audit-log-path or --audit-policy-file. Option D is wrong because --authorization-mode=RBAC is used to enable Role-Based Access Control for authorization, not for audit logging; audit logging requires the policy file and log path flags.

Full explanation →

137

MCQhard

A DevOps team wants to enforce that all Deployments must have a specific label 'app.kubernetes.io/name'. Which tool can be used to validate this in the admission controller stage?

A.Trivy

B.Cosign

C.Kyverno

D.Syft

AnswerC

Kyverno is a Kubernetes-native admission controller that validates resources against policies written as YAML, so a rule can require the app.kubernetes.io/name label on Deployments and reject non-compliant manifests at admission time, satisfying the stem's enforcement requirement.

Why this answer

Kyverno is a Kubernetes-native policy engine that can validate, mutate, and generate resources using admission webhooks. It can enforce that all Deployments carry the label 'app.kubernetes.io/name' by defining a 'validate' rule in a ClusterPolicy, which checks the resource during the admission controller stage before it is persisted to etcd.

Exam trap

This exam often tests the distinction between tools that operate on container images (Trivy, Cosign, Syft) versus tools that enforce policies on Kubernetes resources at admission time (Kyverno, OPA/Gatekeeper), leading candidates to confuse image scanning with admission control.

How to eliminate wrong answers

Option A is wrong because Trivy is a vulnerability scanner for container images, filesystems, and Git repositories; it does not enforce admission policies on Kubernetes resources. Option B is wrong because Cosign is a tool for signing and verifying container images using Sigstore, not for validating Kubernetes object metadata like labels. Option D is wrong because Syft is a software bill of materials (SBOM) generator that analyzes container images and filesystems, not an admission controller policy engine.

Full explanation →

138

Multi-Selecthard

Which THREE of the following are recommended steps during incident response for a compromised pod? (Choose three.)

Select 3 answers

A.Take a memory dump of the container for analysis

B.Delete the entire namespace containing the pod

C.Use kubectl logs and kubectl exec to collect forensic data

D.Apply a NetworkPolicy to deny egress traffic from the pod

E.Immediately restart the pod to stop the attack

AnswersA, C, D

Taking a memory dump preserves volatile artifacts—such as running processes, network socket states, environment variables, and injected attack code—that disappear permanently when the container stops. Capturing this snapshot before any other forensic or remediation action allows investigators to run offline analysis against the exact memory image, potentially revealing the initial exploit and any in-memory resident payloads. Using tooling like `docker exec` with `/proc` access or dedicated memory capture utilities ensures the live state is frozen without altering the container.

Why this answer

Option A is correct because capturing a memory dump of the container preserves volatile evidence such as running processes, injected code, and in-memory credentials before the pod is terminated or restarted. Option C is correct because kubectl logs retrieves container stdout/stderr history and kubectl exec allows live inspection of the filesystem, processes, and network state for forensic collection. Option D is correct because applying a NetworkPolicy that denies egress traffic contains the compromised pod, preventing data exfiltration or command-and-control communication while investigation continues.

Option B is not recommended because deleting the entire namespace destroys evidence and may disrupt unrelated workloads. Option E is not recommended because restarting the pod immediately destroys volatile memory and runtime artifacts needed for root-cause analysis.

Exam trap

CKS often tests the tension between containment and evidence preservation — candidates are tempted by 'restart the pod' or 'delete the namespace' as quick fixes, but these destroy forensic evidence and violate incident response best practices.

Full explanation →

139

MCQeasy

Which kubectl command checks the CIS Benchmark compliance of a cluster node using the kube-bench tool?

A.kubectl apply -f job.yaml

B.kubectl kube-bench

C.kubectl run kube-bench --image=aquasec/kube-bench

D.kube-bench run --targets=node

AnswerA

Applying job.yaml (typically from Aqua Security's kube-bench repository) creates a Kubernetes Job that runs the kube-bench container as a pod, executing the CIS Kubernetes benchmark checks against the current cluster's node configuration. The Job specification includes necessary hostPath mounts, service account, and tolerations, enabling the pod to read host configuration files and run on control-plane nodes, making kubectl apply the standard containerized method. Results are captured in the pod logs, which is the intended workflow for in-cluster benchmarking.

Why this answer

Kube-bench runs as a Kubernetes Job, and the standard way to execute it against a cluster node is to apply a Job YAML manifest that runs the aquasec/kube-bench image. This Job performs CIS Benchmark checks on the node where it is scheduled, and the results are output to the Job's logs. The `kubectl apply -f job.yaml` command deploys the pre-configured Job, which is the recommended method for running kube-bench in a cluster context.

Exam trap

The trap here is that candidates confuse running a container directly with `kubectl run` versus deploying a proper Job manifest, or they assume `kubectl` has a native kube-bench subcommand, when in fact kube-bench must be run as a Kubernetes workload (typically a Job) to comply with the CIS Benchmark scanning methodology.

How to eliminate wrong answers

Option B is wrong because `kubectl kube-bench` is not a valid kubectl subcommand; kubectl does not have a built-in kube-bench plugin, and this command would fail. Option C is wrong because `kubectl run kube-bench --image=aquasec/kube-bench` creates a Pod, not a Job, and kube-bench is designed to run as a Job to properly handle completion and logging; a Pod may not terminate correctly or provide the expected output format. Option D is wrong because `kube-bench run --targets=node` is a direct command-line invocation of the kube-bench binary, not a kubectl command, and the question specifically asks for a kubectl command.

Full explanation →

140

MCQmedium

A pod with the following annotation is created: 'container.apparmor.security.beta.kubernetes.io/webserver: localhost/k8s-apparmor-profile'. However, the pod remains in 'Pending' state and the node logs show 'AppArmor not available'. What is the most likely cause?

A.The annotation should be on the pod's securityContext, not as an annotation

B.AppArmor is not loaded or enabled on the node kernel

C.The AppArmor profile name is misspelled

D.The pod is using a privileged security context

AnswerB

This error is raised by the container runtime (or kubelet) when the node's kernel was not booted with AppArmor support (missing CONFIG_SECURITY_APPARMOR) or the apparmor kernel module is not loaded. Even if profiles are correctly referenced, the kernel must have AppArmor enabled, and profiles must be loaded with apparmor_parser before enforcement can occur. The specific 'AppArmor is not available' error indicates the runtime cannot find the AppArmor subsystem at all, so no profile can be applied.

Why this answer

The node logs explicitly state 'AppArmor not available', which indicates that the AppArmor kernel security module is either not loaded or not enabled on the node's operating system. Without AppArmor support in the kernel, the kubelet cannot enforce the profile specified in the pod annotation, causing the pod to remain in 'Pending' state. This is a prerequisite condition for AppArmor profiles to work in Kubernetes.

Exam trap

CNCF often tests the distinction between a profile being misconfigured (e.g., wrong name) versus the underlying kernel module not being available; the trap here is that candidates may assume a spelling error (Option C) when the node logs clearly point to a missing kernel feature.

How to eliminate wrong answers

Option A is wrong because the AppArmor profile is correctly specified as a pod annotation per the Kubernetes beta API (container.apparmor.security.beta.kubernetes.io/<container_name>), not in the securityContext. Option C is wrong because the node logs do not indicate a profile name mismatch; they explicitly state 'AppArmor not available', which is a kernel-level issue, not a name misspelling. Option D is wrong because a privileged security context does not prevent AppArmor from being available; it may bypass AppArmor enforcement, but the error here is about the kernel module not being present, not about privilege escalation.

Full explanation →

141

MCQeasy

Which YAML field in a Deployment specifies the container user should not run as root?

A.spec.containers[].securityContext.readOnlyRootFilesystem

B.spec.containers[].securityContext.runAsUser: 0

C.spec.containers[].securityContext.runAsNonRoot

D.spec.containers[].securityContext.allowPrivilegeEscalation

AnswerC

runAsNonRoot is a Boolean field in the container's securityContext that enforces non-root execution. When set to true, the kubelet checks that the container's user ID is non-zero, and if the image or a runAsUser setting would cause the process to run as UID 0, the pod is denied with an error. This is the standard mechanism to guarantee the container does not run as root, either by validating an existing non-root USER in the image or by pairing with a non-zero runAsUser value.

Why this answer

`spec.containers[].securityContext.runAsNonRoot: true` explicitly enforces that the container's user ID is non-zero, preventing the container from running as root. This is a key Pod Security Standard (PSS) control for the 'Restricted' profile, ensuring compliance with the principle of least privilege. The field rejects the container if the user is set to root (UID 0) or if no user is specified and the image defaults to root.

Exam trap

The CKS exam often tests the distinction between `runAsNonRoot` (which enforces a non-root user) and `runAsUser: 0` (which explicitly sets root), and candidates mistakenly think setting `runAsUser` to a non-zero value is equivalent to `runAsNonRoot`, but `runAsNonRoot` is a boolean enforcement that rejects root regardless of the image's default user.

How to eliminate wrong answers

Option A is wrong because `readOnlyRootFilesystem` only makes the container's root filesystem read-only, which prevents writes to the filesystem but does not restrict the user ID; a root user can still run with UID 0. Option B is wrong because `runAsUser: 0` explicitly sets the container to run as root (UID 0), which is the opposite of preventing root execution. Option D is wrong because `allowPrivilegeEscalation` controls whether a process can gain more privileges than its parent (e.g., via setuid binaries), but it does not prevent the container from running as root initially.

Full explanation →

142

MCQeasy

A DevOps team uses a CI/CD pipeline to build container images and push them to a private registry. To minimize the risk of supply chain attacks, which of the following is the most effective security control to implement?

A.Scan all images for vulnerabilities using Trivy before pushing to the registry.

B.Restrict access to the registry using Kubernetes RBAC and service accounts.

C.Implement network policies to restrict traffic to the registry endpoint.

D.Sign all container images using a private key and verify the signature before deployment.

AnswerD

Signing container images with a private key (e.g., using cosign or Docker Content Trust) and verifying the signature before deployment provides a cryptographic guarantee that the image's digest matches the signed digest and that the signing key belongs to a trusted publisher. Verification typically happens during admission control—for example, through MutatingAdmissionWebhooks or policy engines like Kyverno or OPA Gatekeeper—so that only images bearing a valid signature from an authorized key are allowed to run. This directly mitigates supply chain tampering because any alteration to the image after signing invalidates the signature, and it also proves the image's origin, which vulnerability scanning, RBAC, and network policies cannot do.

Why this answer

Signing container images with a private key and verifying the signature before deployment ensures image integrity and authenticity, directly mitigating supply chain attacks where an attacker could tamper with images in transit or at rest. This control, often implemented using tools like Notary or Cosign (part of the Sigstore project), provides cryptographic proof that the image was produced by a trusted source and has not been altered. Without signature verification, even a vulnerability-scanned image could be replaced with a malicious one, bypassing other controls.

Exam trap

The trap here is that candidates often confuse vulnerability scanning (which detects known flaws) with image signing (which ensures integrity and provenance), and mistakenly choose scanning as the primary defense against supply chain attacks, overlooking that a scanned image can still be replaced or tampered with.

How to eliminate wrong answers

Option A is wrong because vulnerability scanning (e.g., with Trivy) only identifies known CVEs in the image content; it does not prevent an attacker from replacing the image with a different, malicious one after scanning or during transit. Option B is wrong because restricting registry access via Kubernetes RBAC and service addresses only controls who can push or pull images, but does not verify the integrity or origin of the image itself—an authorized user could still push a tampered image. Option C is wrong because network policies limit traffic to the registry endpoint but do not protect against image tampering; an attacker who gains access to the registry or intercepts traffic could still modify images without detection.

Full explanation →

143

MCQmedium

An administrator discovers that a container has been running with root privileges despite a PodSecurityPolicy that should prevent it. What is the most likely cause?

A.The PodSecurityPolicy is applied in the wrong order and a less restrictive policy overrides it.

B.The pod's service account lacks RBAC permissions to use the PSP.

C.The PodSecurityPolicy admission controller is not enabled in the kube-apiserver.

D.The PodSecurityPolicy resource is misconfigured with an empty allowPrivilegeEscalation field.

AnswerC

The PodSecurityPolicy admission controller is a Kubernetes admission plugin that must be explicitly enabled via the kube-apiserver's `--enable-admission-plugins` flag. If it is not enabled, `PodSecurityPolicy` objects can exist in the cluster but are completely ignored during pod creation and update. The kube-apiserver will allow a privileged or root-running container through because no admission plugin applies the policy constraints, even if RBAC roles and bindings for the PSP are correctly configured. This is the core root cause: PSPs are only enforceable when their admission controller is active.

Why this answer

The PodSecurityPolicy (PSP) admission controller must be explicitly enabled in the kube-apiserver's `--enable-admission-plugins` flag. Without it, PSP resources are stored in etcd but never enforced, allowing any pod to run with root privileges regardless of PSP definitions.

Exam trap

CNCF often tests the distinction between creating a policy resource and actually enabling the admission controller that enforces it, tricking candidates into focusing on RBAC or policy content rather than the fundamental admission plugin flag.

How to eliminate wrong answers

Option A is wrong because PSPs are evaluated in an additive manner; the most restrictive policy is applied, not the least restrictive, and order does not override. Option B is wrong because RBAC permissions for PSPs control which service accounts can use a PSP, but if the admission controller is not enabled, no PSP is enforced at all. Option D is wrong because an empty `allowPrivilegeEscalation` field defaults to `true` in Kubernetes, but this only matters if the PSP admission controller is active; without it, the field is irrelevant.

Full explanation →

144

MCQhard

A CI/CD pipeline uses cosign attest to add an SBOM attestation to an image. Later, during deployment, which command verifies the attestation?

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

B.cosign attest --key cosign.key --predicate sbom.json myimage:latest

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

D.cosign download attestation myimage:latest

AnswerC

cosign verify-attestation is specifically designed to cryptographically verify that the image's attestations are valid and signed by the trusted public key. It decodes the DSSE envelope, checks the in-toto statement's signature, and outputs the payload only if authentication succeeds. This is the only command here that directly addresses the SBOM attestation's integrity and the signer's identity, making it the correct choice for a pipeline's verification step.

Why this answer

`cosign verify-attestation` is the specific command designed to verify an in-toto attestation (such as an SBOM) attached to a container image. It checks the signature on the attestation using the provided public key (`--key cosign.pub`) and validates that the attestation's payload matches the image digest, ensuring the SBOM was generated and signed by the trusted party.

Exam trap

The CKS exam often tests the distinction between `cosign verify` (for image signatures) and `cosign verify-attestation` (for attestations), and the trap here is that candidates mistakenly choose `cosign verify` thinking it covers all signed artifacts, but it does not handle the in-toto attestation envelope.

How to eliminate wrong answers

Option A is wrong because `cosign verify` verifies the image's signature (typically a simple digest signature), not an attestation payload like an SBOM; it does not parse or validate the in-toto envelope. Option B is wrong because `cosign attest` is the command used to create and attach an attestation (the action performed in the CI/CD pipeline), not to verify it; it requires a private key and a predicate file. Option D is wrong because `cosign download attestation` only retrieves the raw attestation data from the registry without performing any cryptographic verification of the signature or the attestation's integrity.

Full explanation →

145

MCQeasy

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

A.Syft

B.Kubesec

C.Checkov

D.Trivy

AnswerA

Syft is a purpose-built CLI tool from Anchore that generates Software Bills of Materials (SBOMs) for container images and filesystems. It inventories all installed packages, libraries, and application dependencies, emitting them in standardized formats such as SPDX and CycloneDX for downstream security analysis. Because SBOM generation is its core function, Syft directly answers the question.

Why this answer

Syft is an open-source 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 (e.g., dpkg, RPM, APK, Python, Java) and outputs the SBOM in formats like CycloneDX or SPDX, which are the industry standards for supply chain transparency. This makes Syft the correct tool for generating an SBOM from a container image.

Exam trap

The CNCF CKS exam often tests the distinction between a dedicated SBOM generator (Syft) and a multi-purpose security scanner (Trivy), leading candidates to pick Trivy because they know it can produce SBOMs, but the question explicitly asks for the tool 'used to generate' an SBOM, and Syft is the correct, specialized answer.

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 (Checkov) is wrong because it is a policy-as-code scanner for infrastructure-as-code (e.g., Terraform, CloudFormation, Kubernetes YAML), not an SBOM generator. Option D (Trivy) is wrong because while Trivy can detect vulnerabilities and has an SBOM generation feature (via `trivy image --format cyclonedx`), its primary purpose is vulnerability scanning, and the question specifically asks for the tool used to generate an SBOM; Syft is the dedicated, purpose-built tool for SBOM generation, whereas Trivy's SBOM capability is secondary to its vulnerability scanning.

Full explanation →

146

MCQmedium

A security team wants to detect any attempt to read the /etc/shadow file inside a container. Which Falco rule condition would trigger an alert for such an event?

A.evt.type=open and proc.name=bash and fd.name=/etc/shadow

B.evt.type=open and fd.name contains /etc

C.evt.type=open and fd.name=/etc/shadow and evt.arg.flags contains O_WRONLY

D.evt.type=open and fd.name=/etc/shadow and evt.arg.flags contains O_RDONLY

AnswerD

This is the correct Falco rule: it captures the open syscall specifically on /etc/shadow, uses the exact file path to avoid false positives from /etc subdirectories, and filters on the O_RDONLY flag to select only read-only opens. Attackers almost always open the shadow file with O_RDONLY to dump its contents, so this rule reliably surfaces those attempts while ignoring legitimate administrative writes that use O_WRONLY or O_RDWR. The result is a focused, high-signal detection rule.

Why this answer

Reading /etc/shadow requires the open syscall with the O_RDONLY flag. Falco's rule condition `evt.type=open and fd.name=/etc/shadow and evt.arg.flags contains O_RDONLY` precisely matches an attempt to open the file for reading, which is the event that should trigger an alert for unauthorized read access.

Exam trap

The CKS exam often tests the distinction between read and write flags in syscall arguments, and candidates mistakenly choose O_WRONLY (option C) thinking any access to /etc/shadow is malicious, but the question specifically asks for read attempts.

How to eliminate wrong answers

Option A is wrong because it restricts the triggering process to `proc.name=bash`, which would miss attempts by other processes (e.g., cat, less, or a malicious binary) to read /etc/shadow. Option B is wrong because `fd.name contains /etc` is too broad — it would trigger on any file under /etc (e.g., /etc/passwd, /etc/hosts), not specifically /etc/shadow, leading to excessive false positives. Option C is wrong because `evt.arg.flags contains O_WRONLY` matches write operations, not read operations; opening /etc/shadow for writing is a different (and less common) event, and the question asks specifically for detecting read attempts.

Full explanation →

147

MCQhard

A security team wants to ensure that only approved container images can run in their production cluster. Which admission controller should be configured in the kube-apiserver to enforce this policy?

A.PodSecurityPolicy

B.AlwaysPullImages

C.NodeRestriction

D.ImagePolicyWebhook

AnswerD

ImagePolicyWebhook is an admission controller that sends a request to an external HTTPS webhook before a pod is admitted, allowing the webhook to approve or reject the creation/update based on image metadata, registry, digest, or custom policy. Since the webhook can integrate with external trust systems (e.g., OPA, cosign), it provides flexible, policy-driven validation of image sources. This is the correct mechanism for enforcing approved-container-image admission.

Why this answer

The ImagePolicyWebhook admission controller allows a cluster to enforce a policy that only approved container images can run by sending image admission requests to an external webhook backend. This webhook can validate images against an allowlist, a trusted registry, or a custom policy engine, and it returns an admission decision (allow or deny) before the pod is created. This directly meets the requirement of restricting which container images are permitted in the cluster.

Exam trap

The trap here is that candidates confuse PodSecurityPolicy (which restricts pod security attributes) with image admission control, or they assume AlwaysPullImages can enforce image approval because it forces a fresh pull, but it never checks the image source or registry allowlist.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (PSP) is a deprecated admission controller that enforces security context constraints (e.g., privilege escalation, host namespaces) on pods, not image approval or registry allowlisting. Option B is wrong because AlwaysPullImages forces the kubelet to pull images with the specified pull policy every time a pod is created, but it does not validate whether the image is from an approved source or registry. Option C is wrong because NodeRestriction limits the permissions of kubelet nodes to modify their own node and pod objects via the Kubernetes API, and it has no role in image admission control.

Full explanation →

148

MCQhard

A security team wants to detect any attempt to read /etc/shadow from within a container using Falco. Which condition in a Falco rule would match this behavior?

A.proc.name contains "shadow" and evt.type=read

B.evt.type=read and fd.name contains "shadow"

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

D.container and fd.name=/etc/shadow

AnswerC

The open syscall is the actual attempt to access a file; checking evt.type=open with an exact fd.name=/etc/shadow ensures the rule fires when any process tries to open the shadow password file, whether or not the subsequent read occurs. This catches both successful reads and denied attempts, making it the precise detection predicate.

Why this answer

Reading /etc/shadow from a container requires opening the file first, so the Falco rule must match the `open` system call (evt.type=open) and the exact file path (fd.name=/etc/shadow). The `open` syscall is the entry point for file access, and Falco captures it before any read or write occurs, making it the appropriate event type to detect an attempt to read the shadow file.

Exam trap

A common misconception in CKS is that reading a file is detected via the `read` syscall, but the correct approach is to detect the `open` syscall because that is when the file access is initiated and Falco's rule engine is designed to catch the opening event.

How to eliminate wrong answers

Option A is wrong because `proc.name contains 'shadow'` matches processes with 'shadow' in their name (e.g., a process named 'shadowd'), not the file being accessed; also, `evt.type=read` alone would miss the initial open that triggers the read. Option B is wrong because `evt.type=read` and `fd.name contains 'shadow'` would only match after the file is already opened and a read syscall is made, but Falco typically triggers on the open syscall for file access detection, and using `contains` instead of exact match could produce false positives (e.g., matching '/etc/shadow.bak'). Option D is wrong because it lacks an event type filter (evt.type), so it would match any event (including close, write, etc.) with fd.name=/etc/shadow, which is too broad and may generate noise or miss the specific open attempt.

Full explanation →

149

MCQhard

A security engineer is using cosign to sign a container image. The engineer runs 'cosign sign --key cosign.key registry.example.com/app:1.0' and receives an error: 'Error: signing [registry.example.com/app:1.0]: getting signer: reading key: PEM decode failed: invalid pem block'. What is the most likely cause of this error?

A.The cosign.key file was encrypted and requires a password that was not provided.

B.The image reference is invalid because it lacks a digest.

C.The private key file cosign.key is not in the correct PEM format or is corrupted.

D.The image registry requires authentication, and the engineer has not logged in.

AnswerC

The error message indicates a PEM decode failure, meaning Cosign could not parse the private key file. This typically happens if the file is not a valid PEM-encoded private key, perhaps due to corruption, incorrect file contents, or using the wrong file. The engineer should ensure that cosign.key contains a valid private key generated by cosign generate-key-pair.

Why this answer

The error 'PEM decode failed: invalid pem block' indicates that Cosign could not parse the private key file. This is most likely because the file is not a valid PEM-encoded key, perhaps due to corruption, wrong file, or incorrect format. The other options would produce different errors related to registry authentication, image reference, or key decryption.

Exam trap

The trap here is assuming that signing errors are always due to registry or image issues, but key file problems are a common cause of PEM decode failures.

Full explanation →

150

MCQhard

You are a security engineer for a financial services company running a Kubernetes cluster on-premises. The cluster uses kubeadm for bootstrapping and Calico for network policy. Recently, a compliance audit revealed that all nodes in the cluster have the kubelet port 10250 open to the public network, allowing unauthenticated access to the kubelet API. This poses a severe security risk. The cluster has 10 worker nodes and 3 control plane nodes. You need to remediate this without disrupting running workloads. The nodes are behind a corporate firewall, but the internal network is considered untrusted. You have access to the node's iptables and can modify configuration files. Which course of action best secures the kubelet port while maintaining cluster functionality?

A.Use iptables on each node to allow incoming connections to port 10250 only from the cluster's CIDR (e.g., 10.0.0.0/8).

B.Configure a Calico GlobalNetworkPolicy to block inbound traffic to port 10250 on all nodes.

C.Change the kubelet port to a non-standard port (e.g., 10260) and update all kubelet configurations.

D.Set the --anonymous-auth flag to false on each kubelet and restart them one by one.

AnswerA

The kubelet serves its API on port 10250 bound to all node interfaces, and the Kubernetes control plane accesses it for operations like exec, logs, and metrics. An iptables rule filtering by cluster CIDR at each node is an effective host-level network boundary control: it lets matching traffic from the API server and other nodes reach the kubelet while preventing arbitrary external hosts from even connecting to this sensitive endpoint. For robustness, you would combine this with kubelet authentication and authorization, but the firewall rule is what actually blocks network exposure to the outside.

Why this answer

Using iptables to restrict access to port 10250 to only the cluster's internal CIDR (e.g., 10.0.0.0/8) directly addresses the audit finding by blocking unauthenticated public access while allowing necessary kubelet API communication from within the cluster. This approach does not disrupt running workloads, as it only modifies firewall rules without restarting kubelet or changing its configuration. It leverages the existing network infrastructure (iptables) and is consistent with the principle of least privilege for an untrusted internal network.

Exam trap

The trap here is that candidates often confuse Kubernetes network policies (like Calico) with host-level firewall rules, assuming they can block node ports, when in fact network policies only apply to pod-to-pod traffic and cannot control access to the kubelet's host network interface.

How to eliminate wrong answers

Option B is wrong because Calico GlobalNetworkPolicy operates at the Kubernetes network policy layer, which applies to pods and their traffic, not to node-level ports like the kubelet API (port 10250) which is a host network service; Calico policies cannot block traffic to the node's own kubelet endpoint. Option C is wrong because changing the kubelet port to a non-standard port (e.g., 10260) does not address the root cause of unauthenticated access; it only obscures the port, and the new port would still be open to the public network unless additional firewall rules are applied, plus it requires restarting kubelet which could disrupt workloads. Option D is wrong because setting --anonymous-auth to false only disables anonymous requests but does not block unauthenticated access from other sources (e.g., requests with valid but compromised credentials); the audit finding specifically highlights unauthenticated access, and this flag does not prevent network-level exposure of the port.

Full explanation →

Certified Kubernetes Security Specialist CKS (CKS) — Questions 76–150