Certified Kubernetes Security Specialist CKS CKS Questions 451–525 | Page 7/12

451

MCQmedium

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

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

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

C.trivy image --format table myimage:tag

D.trivy image --severity HIGH myimage:tag

AnswerB

This is the correct command because it targets the container image (`trivy image`), restricts results to only critical-severity vulnerabilities with `--severity CRITICAL`, and outputs machine-readable JSON via `--output json`. The JSON format is ideally suited for CI/CD automation, allowing the pipeline to parse vulnerability data programmatically (e.g., with jq) and enforce policy based on exact vulnerability IDs. It directly matches the requirement to scan the built image and flag critical issues.

Why this answer

`trivy image` scans a container image. Use `--severity CRITICAL` to filter only critical vulnerabilities and `--format json` to produce machine-parseable JSON output. This lets the pipeline parse the JSON and fail on critical vulnerabilities.

Note: `--output` specifies an output file path, not the report format.

Exam trap

The trap is confusing `trivy fs` with `trivy image`, and confusing `--format` (which controls output format, such as JSON) with `--output` (which specifies a file path). The command must use `--format json`, not `--output json`.

How to eliminate wrong answers

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

Full explanation →

452

Multi-Selectmedium

A security team is implementing supply chain security for their Kubernetes cluster. They want to ensure that only container images that have been signed and verified are deployed. They are evaluating admission controllers and tools. Which TWO of the following are valid approaches to enforce image signature verification at admission time? (Choose two.)

Select 2 answers

A.Use the PodSecurity admission controller with the restricted profile to enforce image signing.

B.Use the NodeRestriction admission controller to restrict which images can be pulled by kubelets.

C.Use the AlwaysPullImages admission controller to ensure images are always pulled and verified by the container runtime.

D.Use the ImagePolicyWebhook admission controller with a custom webhook that calls cosign verify.

E.Use a Kyverno policy that verifies image signatures using the verifyImages rule.

AnswersD, E

The ImagePolicyWebhook admission controller allows an external webhook to make admission decisions based on image policies. By implementing a webhook that uses cosign verify to check signatures, the cluster can enforce that only signed images are admitted. This is a valid and flexible approach, though it requires deploying and maintaining the webhook service.

Why this answer

Enforcing image signature verification at admission time can be achieved through the ImagePolicyWebhook admission controller with a custom webhook that calls cosign verify, or through a Kyverno policy that uses the verifyImages rule. Both approaches intercept pod creation and validate image signatures before allowing the pod. The other options do not provide signature verification capabilities.

Exam trap

The trap here is assuming that pod security or image pull policies can enforce signature verification, but they operate at different layers and do not validate cryptographic signatures.

Full explanation →

453

MCQmedium

A security engineer runs the following command to inspect a pod's security context: kubectl get pod secure-pod -o jsonpath='{.spec.containers[0].securityContext.capabilities}' The output is: {"drop":["ALL"]} What does this indicate?

A.The container has all Linux capabilities dropped

B.The output is invalid because capabilities should be in add field

C.The container has no capability restrictions

D.The container has only the NET_ADMIN capability added

AnswerA

The capabilities field shows drop: ["ALL"], meaning every Linux capability is removed from the container's effective, permitted and inheritable sets. The container therefore runs with no capabilities, which is the hardened posture the security engineer intended to verify.

Why this answer

The output `{"drop":["ALL"]}` indicates that the container's security context explicitly drops all Linux capabilities via the `drop` field. This is a common security hardening practice to reduce the attack surface by removing all privileged operations, such as `CAP_NET_ADMIN` or `CAP_SYS_ADMIN`, from the container's effective capability set.

Exam trap

The CKS exam often tests the misconception that the `drop` field is invalid or that dropping all capabilities leaves some capabilities intact, when in fact `drop:["ALL"]` is a valid and restrictive configuration that removes every Linux capability.

How to eliminate wrong answers

Option B is wrong because the `drop` field is a valid part of the capabilities specification in Kubernetes security contexts; capabilities can be both added and dropped, and the output is perfectly valid. Option C is wrong because dropping all capabilities means the container has maximum restrictions, not no restrictions; a container with no capability restrictions would have an empty or absent `capabilities` field or an `add` field with specific capabilities. Option D is wrong because the output shows `drop:["ALL"]`, which removes all capabilities, including `NET_ADMIN`, and there is no `add` field present to indicate any added capabilities.

Full explanation →

454

MCQhard

An OPA/Gatekeeper constraint is configured to allow only images from 'trusted-registry.io'. A pod is created with image 'trusted-registry.io/app:v1' but is denied. Which is the MOST likely cause?

A.The constraint is only applied in the default namespace

B.The image tag is not pinned to a digest

C.The image is not signed

D.The constraint uses regex and the image does not match the pattern

AnswerD

The constraint is built with a regex pattern (or a glob converted to regex) that defines exactly which image registry paths are allowed, and Gatekeeper uses this pattern to match against the full image reference. If the image reference omits a required path segment, uses a different registry host, or otherwise fails to satisfy the regex anchors, the constraint fails and blocks the image. So the denial happens because the image string does not match the precise pattern that the constraint's `allowedPattern` (or similar field) enforces.

Why this answer

The most likely cause is that the OPA/Gatekeeper constraint uses a regex pattern to match allowed image registries, and the image 'trusted-registry.io/app:v1' does not match that pattern. Gatekeeper constraints often rely on Rego rules that check image strings against regex patterns; if the pattern is too restrictive or incorrectly defined (e.g., requiring a trailing slash or specific path), valid images can be denied. This is a common misconfiguration where the regex does not account for the full image reference format.

Exam trap

The CNCF-CKS exam often tests the misconception that image signing or digest pinning is required for registry-based constraints, when in fact the issue is typically a regex mismatch in the OPA policy.

How to eliminate wrong answers

Option A is wrong because Gatekeeper constraints are cluster-scoped by default and apply to all namespaces unless explicitly scoped via a namespaceSelector; a constraint that only applies to the default namespace would not deny pods in other namespaces, but the question does not specify a namespace restriction. Option B is wrong because pinning to a digest is a best practice for immutability but is not required by a constraint that only checks the registry; the constraint would still allow 'trusted-registry.io/app:v1' if the registry matches. Option C is wrong because image signing (e.g., with cosign or notary) is a separate security control; Gatekeeper constraints do not inherently verify signatures unless a custom rule is written to check attestations, and the question does not mention signature verification.

Full explanation →

455

MCQeasy

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

A.NodeSelector

B.PodSecurity

C.NodeRestriction

D.AlwaysPullImages

AnswerC

NodeRestriction is a special admission controller in kube-apiserver that limits what a kubelet can modify through the Node API. It uses the kubelet's `system:node:<nodeName>` identity (derived from its certificate/TLS identity) to ensure the kubelet can only update its own Node object, and cannot add/remove taints or labels that would affect scheduling of all pods (some taints/labels are blocked). It also restricts the kubelet from creating Node objects not named after itself. This directly mitigates the described scenario where a kubelet modifies node metadata.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

456

Multi-Selecteasy

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

Select 2 answers

A.Use Kubernetes Secrets with encryption at rest enabled

B.Store secrets in ConfigMaps and use them in pods

C.Commit secrets to a private Git repository

D.Store secrets directly in the application code

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

AnswersA, E

Kubernetes Secrets can be encrypted at rest via the EncryptionConfiguration resource, where the kube-apiserver encrypts matching resources (e.g., secrets, configmaps) before writing them to etcd. Supported providers include AES-CBC, AES-GCM, and KMS for envelope encryption, which allows key management via cloud KMS or on-premises HSMs. Without this configuration, Secrets are stored as plaintext base64 in etcd, so enabling EncryptionConfiguration is a critical hardening step to protect Secret data at rest. Remember that this protects data on disk, but you still need RBAC and network policies to restrict access to Secrets in transit and at runtime.

Why this answer

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

Exam trap

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

Full explanation →

457

Multi-Selecthard

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

Select 3 answers

A.Trivy fs

B.Notary

C.Syft

D.Cosign verify

E.ImagePolicyWebhook

AnswersB, D, E

Notary is an open-source project that implements The Update Framework (TUF), providing a secure mechanism for publishing and verifying signed collections of content, including container images. It uses signed metadata files that list the cryptographic digests of image manifests and layers, enabling clients to confirm that the image came from the expected publisher and has not been altered. This makes Notary a valid, standards-based approach to image integrity and authenticity verification.

Why this answer

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

Exam trap

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

Full explanation →

458

MCQmedium

You need to apply a seccomp profile to all containers in a pod. The profile is named 'custom-profile.json' and is stored on each node at /var/lib/kubelet/seccomp/. Complete the following YAML snippet: ```yaml apiVersion: v1 kind: Pod metadata: name: secure-pod spec: securityContext: seccompProfile: type: Localhost localhostProfile: ??? ``` What should replace ???

A.custom-profile.json

B.localhost/custom-profile.json

C.profile: custom-profile.json

D./var/lib/kubelet/seccomp/custom-profile.json

AnswerA

With `type: Localhost`, the kubelet resolves `localhostProfile` relative to its configured seccomp root directory, `/var/lib/kubelet/seccomp/`. Supplying `custom-profile.json` therefore points to the exact node path given in the stem. Absolute paths or directory prefixes would fail, since the field expects a path relative to that root.

Why this answer

When using a seccomp profile of type Localhost in Kubernetes, the `localhostProfile` field must specify only the filename of the profile (e.g., `custom-profile.json`). The kubelet automatically prepends the default seccomp profile path (`/var/lib/kubelet/seccomp/`) to the filename, so providing the full path would be incorrect.

Exam trap

The trap here is that candidates often assume they must provide the full absolute path to the profile file, but Kubernetes requires only the filename (or relative path) because the kubelet automatically prepends the default seccomp directory.

How to eliminate wrong answers

Option B is wrong because `localhost/custom-profile.json` is not a valid value for `localhostProfile`; the field expects just the filename, not a path with a `localhost/` prefix. Option C is wrong because `profile: custom-profile.json` is not a valid syntax for the `localhostProfile` field; the field is a string, not a key-value pair. Option D is wrong because `/var/lib/kubelet/seccomp/custom-profile.json` includes the full absolute path, but the kubelet already prepends `/var/lib/kubelet/seccomp/` to the value of `localhostProfile`, so specifying the full path would result in a double path (e.g., `/var/lib/kubelet/seccomp//var/lib/kubelet/seccomp/custom-profile.json`), causing the profile to not be found.

Full explanation →

459

MCQmedium

Which of the following is a best practice for Dockerfiles to improve supply chain security?

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

B.Run the container as root by default

C.Use a distroless base image

D.Hardcode secrets directly in the Dockerfile

AnswerC

Distroless images ship only the application and its runtime dependencies, omitting package managers, shells and utilities. This shrinks the attack surface and removes tooling attackers commonly abuse after exploiting a container, strengthening supply chain security.

Why this answer

Distroless base images contain only the application and its runtime dependencies, significantly reducing the attack surface by eliminating package managers, shells, and other utilities that could be exploited. This aligns with the principle of minimalism in supply chain security, as fewer components mean fewer potential vulnerabilities and a smaller blast radius in case of compromise.

Exam trap

CKS often tests the misconception that 'latest' is safe because it's up-to-date, but the trap is that 'latest' is a mutable tag that undermines supply chain integrity and reproducibility, while distroless images are a concrete security hardening technique.

How to eliminate wrong answers

Option A is wrong because using the latest tag introduces unpredictability; the image can change without notice, potentially pulling in unverified or vulnerable versions, breaking reproducibility, and making it impossible to audit the exact base image used. Option B is wrong because running containers as root by default violates the principle of least privilege; if the container is compromised, an attacker gains root access on the host (via kernel namespace escape), and Kubernetes security contexts should enforce non-root users. Option D is wrong because hardcoding secrets directly in the Dockerfile embeds sensitive data in image layers, making them visible to anyone with access to the image registry or history, and violates best practices for secret management (e.g., using Kubernetes Secrets or external vaults).

Full explanation →

460

MCQmedium

To verify a signed container image, which command should be used?

A.cosign verify myimage:latest

B.trivy verify myimage:latest

C.kubectl verify myimage:latest

D.cosign validate myimage:latest

AnswerA

cosign verify validates a container image's signature against the specified public key or keyless identity, confirming the image was signed by a trusted party and has not been tampered with. This is the standard Sigstore command for signature verification in supply-chain security workflows.

Why this answer

The `cosign verify` command is the correct tool for verifying the cryptographic signature of a signed container image stored in an OCI-compliant registry. Cosign, part of the Sigstore project, uses public-key or keyless signing to ensure image integrity and authenticity. The command checks the signature against the image manifest and the provided public key or Fulcio certificate, confirming that the image has not been tampered with since signing.

Exam trap

The CNCF-CKS exam often tests the distinction between `cosign verify` and `cosign validate` (or similar-sounding commands), where candidates confuse signature verification with attestation verification or assume a generic 'validate' verb exists, leading them to pick a plausible but incorrect option.

How to eliminate wrong answers

Option B is wrong because `trivy verify` is not a valid command; Trivy is a vulnerability scanner, not a signature verification tool, and it does not implement the Cosign verification protocol. Option C is wrong because `kubectl verify` does not exist; kubectl is for managing Kubernetes resources, not for verifying container image signatures. Option D is wrong because `cosign validate` is not a real subcommand; Cosign uses `verify` for signature verification, while `validate` is used in other tools like `cosign validate` for attestation verification (which is a different operation) or does not exist in the standard Cosign CLI.

Full explanation →

461

MCQhard

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

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

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

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

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

AnswerA

Gatekeeper, built on the OPA admission controller, can enforce a Constraint that rejects any Pod whose spec does not set readOnlyRootFilesystem: true. By configuring the Constraint's match to exclude a specific label placed on the exception Pod or its namespace, administrators gain per-workload exemptions without weakening the overall policy. This approach is declarative, versionable in Git, and applies at admission time, so the exemption is explicit and auditable. It is fundamentally different from a mutating default because the policy actively denies non-compliant Pods while allowing known exceptions.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

462

Multi-Selectmedium

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

Select 2 answers

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

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

C.Use the default service account for all workloads

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

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

AnswersA, D

Setting automountServiceAccountToken: false in the Pod spec prevents the kubelet from mounting the service account token into the container filesystem. This is a critical least-privilege control because many workloads (e.g., batch jobs, worker processes) never interact with the Kubernetes API, and an unneeded token is an attack surface — if the container is compromised, the token can be exfiltrated and used to impersonate the service account. By disabling automount at the Pod level, you ensure that even if a service account has RBAC permissions, those permissions cannot be leveraged from that specific pod. This is the correct approach for pods that do not require API access.

Why this answer

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

Exam trap

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

Full explanation →

463

MCQmedium

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

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

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

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

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

AnswerA

The restricted Pod Security Standard (PSS) explicitly forbids any capability additions beyond the default set; a container that adds NET_BIND_SERVICE (or any other Linux capability) violates the 'capabilities' constraint, which requires that the effective capability set match the default and that all capabilities be dropped. Since this pod adds a capability rather than merely retaining defaults, it fails the restricted profile's validation and is rejected.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

464

MCQhard

A Falco rule has the following condition: spawned_process and container and proc.name = bash and proc.pname != sshd. What does this rule detect?

A.Any process named bash on the host

B.A bash shell started in a container via SSH

C.An SSH connection to a container

D.A bash shell started in a container from a non-SSH parent process

AnswerD

The rule fires on process-spawn events inside containers where the executable is bash and the parent process name is not sshd. This matches interactive shells launched by kubectl exec, docker exec, or exploited entrypoints, satisfying the stem's condition that the parent process is anything other than sshd.

Why this answer

The Falco rule condition `spawned_process and container and proc.name = bash and proc.pname != sshd` specifically detects a bash shell process that is spawned inside a container, where the parent process is not sshd. This means the bash shell was started from a non-SSH parent process, such as a shell or an application, rather than via an SSH session. The rule excludes SSH-triggered bash shells by checking that the parent process name is not sshd.

Exam trap

The trap here is that candidates may misinterpret `proc.pname != sshd` as detecting SSH connections or SSH-triggered shells, when in fact it excludes them, and they may overlook the `container` condition, thinking the rule applies to host processes.

How to eliminate wrong answers

Option A is wrong because the rule includes the `container` condition, so it only detects processes running inside a container, not on the host. Option B is wrong because the rule explicitly checks `proc.pname != sshd`, which excludes bash shells started via SSH; thus, it detects bash shells that are NOT started via SSH. Option C is wrong because the rule detects a bash shell process, not an SSH connection; SSH connections are typically detected by rules monitoring network connections or sshd processes, not by a spawned_process and proc.name condition.

Full explanation →

465

MCQmedium

A DevOps engineer wants to ensure that all pods in a namespace have seccomp set to RuntimeDefault unless explicitly overridden. Which approach should be used to enforce this?

A.Add a PodSecurityPolicy that sets seccomp to RuntimeDefault

B.Use a cronjob to audit and modify pods that do not have seccomp set

C.Add a seccomp profile to the kubelet configuration

D.Configure the namespace with the label 'pod-security.kubernetes.io/enforce: restricted'

AnswerD

Applying the label `pod-security.kubernetes.io/enforce: restricted` to the namespace enables Pod Security Admission in enforce mode, which is a built-in admission controller. The `restricted` level of the Pod Security Standards requires Pods to set `securityContext.seccompProfile.type` to `RuntimeDefault` or `Localhost`, among other hardened settings. Any Pod that fails these requirements is immediately rejected at admission time, ensuring that all Pods in the namespace have seccomp enabled. This is the declarative, namespace-scoped mechanism that replaced PodSecurityPolicy.

Why this answer

The 'restricted' Pod Security Standard enforces seccomp to RuntimeDefault as a baseline requirement. By labeling the namespace with 'pod-security.kubernetes.io/enforce: restricted', the built-in Pod Security Admission controller automatically rejects any pod that does not set seccomp to RuntimeDefault (or a custom profile), without needing a separate policy or manual auditing.

Exam trap

The trap here is that candidates confuse kubelet-level seccomp configuration (which affects the kubelet, not pods) with pod-level enforcement, or they mistakenly think deprecated PSPs are still a valid solution for seccomp enforcement.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (PSP) is deprecated in Kubernetes 1.21 and removed in 1.25, so it cannot be used in modern clusters; also, PSP does not natively enforce seccomp profiles by default. Option B is wrong because a cronjob that audits and modifies pods is reactive, not proactive, and violates the principle of enforcement—pods without seccomp would already be running before the cronjob acts. Option C is wrong because kubelet configuration sets a seccomp profile for the kubelet process itself, not for pods; pod seccomp is controlled via securityContext in the pod spec or admission controllers.

Full explanation →

466

MCQeasy

Which command creates a validating webhook configuration that checks all pods in the cluster?

A.kubectl create mutatingwebhookconfiguration my-webhook --from-file=webhook.yaml

B.kubectl run webhook --image=webhook

C.kubectl create validatingwebhookconfiguration my-webhook --from-file=webhook.yaml

D.kubectl apply -f webhook.yaml --validating

AnswerC

The `kubectl create validatingwebhookconfiguration` subcommand registers a ValidatingWebhookConfiguration object, which the API server consults before admitting any pod. Because the webhook's `rules` field can scope to `pods` across all namespaces, it satisfies the stem's requirement to check every pod cluster-wide, unlike namespace-scoped alternatives.

Why this answer

`kubectl create validatingwebhookconfiguration` is the specific command to create a ValidatingWebhookConfiguration resource from a YAML file, which can be configured to intercept and validate pod creation requests across the cluster. This resource allows you to define a webhook that checks all pods before they are admitted, enforcing custom validation logic.

Exam trap

The CKS exam often tests the distinction between mutating and validating webhooks. Candidates may confuse `kubectl create mutatingwebhookconfiguration` with the validating variant, or assume `kubectl apply` with a flag can create a validating webhook.

How to eliminate wrong answers

Option A is wrong because `kubectl create mutatingwebhookconfiguration` creates a MutatingWebhookConfiguration, which mutates objects before admission, not a validating webhook that checks pods. Option B is wrong because `kubectl run webhook --image=webhook` simply runs a pod from an image named 'webhook'; it does not create any webhook configuration or validate pods. Option D is wrong because `kubectl apply -f webhook.yaml --validating` is invalid syntax; the `--validating` flag does not exist for `kubectl apply`, and ValidatingWebhookConfigurations are created via `kubectl create` or `kubectl apply` without such a flag.

Full explanation →

467

Multi-Selectmedium

Which TWO of the following are recommended practices for securing the Kubernetes dashboard?

Select 2 answers

A.Avoid exposing the dashboard to the public internet

B.Expose the dashboard via a NodePort service for easy access

C.Enable anonymous access to the dashboard

D.Use RBAC to restrict dashboard permissions

E.Run the dashboard as a DaemonSet

AnswersA, D

Exposing the Kubernetes Dashboard to the public internet is dangerous because it is a highly privileged web interface that often operates with administrative service account tokens. Even with authentication enabled, public exposure expands the attack surface, allowing attackers to attempt credential brute-force, exploit known CVEs, or abuse misconfigured authorization rules, potentially leading to full cluster takeover. The dashboard should be accessed only through trusted channels such as `kubectl proxy`, an SSH tunnel, or a strictly controlled internal network with TLS encryption and strong identity verification.

Why this answer

Exposing the Kubernetes dashboard to the public internet significantly increases the attack surface, making it a prime target for credential theft, API abuse, and cluster compromise. The dashboard should only be accessible via internal networks, VPNs, or using kubectl proxy with authentication, never directly over the internet.

Exam trap

CNCF often tests the misconception that NodePort or anonymous access are acceptable for convenience in a lab environment, but the CKS exam strictly requires production-hardened configurations where any public exposure or unauthenticated access is automatically incorrect.

Full explanation →

468

MCQmedium

A pod manifest is shown. What security issue remains in this configuration?

A.The container runs as root (user 0)

B.The container has a writable root filesystem

C.The container has dangerous capabilities

D.The container can escalate privileges

AnswerB

Without readOnlyRootFilesystem set to true in the container's securityContext, the container can write to its root filesystem. This leaves the pod able to modify its own image layers, which is the remaining security issue in the manifest.

Why this answer

The pod manifest does not set `readOnlyRootFilesystem: true` in the container's security context. Without this setting, the container's root filesystem is writable by default, allowing an attacker who compromises the container to modify binaries, configuration files, or write malicious scripts to persistent storage, thereby increasing the attack surface and potentially enabling persistence or privilege escalation.

Exam trap

The trap here is that candidates often assume the default security context is secure, but CNCF tests the specific omission of `readOnlyRootFilesystem: true` as a distinct hardening requirement, even when other settings like `runAsNonRoot: true` are present.

How to eliminate wrong answers

Option A is wrong because the question does not specify that the container runs as root; the manifest may not set `runAsUser: 0`, and even if it did, running as root is not inherently a security issue if other controls (like dropping capabilities and read-only rootfs) are in place. Option C is wrong because the manifest does not show any added capabilities; by default, containers run with a restricted set of capabilities, and dangerous capabilities like CAP_SYS_ADMIN are not present unless explicitly added. Option D is wrong because the manifest does not set `allowPrivilegeEscalation: true`; by default, this is false in Kubernetes 1.24+ and prevents processes from gaining more privileges than their parent, so no escalation risk is introduced by the manifest as shown.

Full explanation →

469

MCQhard

You are a security engineer for a financial services company running a Kubernetes cluster with 50 nodes. The cluster uses containerd as the container runtime and Calico for networking. The security team has detected unusual outbound network connections from a pod running in the 'payments' namespace to an external IP address known to be a command-and-control server. The pod is part of a Deployment named 'payment-processor' with 3 replicas. The cluster has a Falco daemonset deployed with default rules, and audit logging is enabled for the API server. You need to quickly identify the compromised container and contain the threat. Which action should you take FIRST?

A.Use 'kubectl exec -it <pod> -- bash' to inspect the container, then kill the malicious process from within

B.Scale the 'payment-processor' Deployment to 0 replicas to immediately stop all pods

C.Check the Falco logs for an alert containing the pod name, then use 'kubectl delete pod' to remove the compromised pod

D.Identify the node hosting the suspicious pod using 'kubectl get pod -o wide', then SSH to that node and use 'crictl ps' to list containers, then 'crictl stop' the container

AnswerD

This is the correct approach because it precisely identifies the node and the exact container instance running the malicious workload, then uses the CRI tool crictl to stop that specific container without impacting other replicas or the Deployment's configuration. Stopping the container preserves the pod object and node state for forensic collection, while the runtime's crictl stop sends a clean stop signal and allows you to capture the container's ID and runtime state for later analysis. It is the least destructive and most targeted method to halt the malicious process while maintaining the ability to investigate.

Why this answer

It follows the proper incident response workflow for a compromised container: first identify the node hosting the suspicious pod using `kubectl get pod -o wide`, then SSH to that node and use `crictl ps` (the containerd CLI) to list running containers and their IDs, then use `crictl stop` to immediately halt the compromised container. This approach directly isolates the threat at the container runtime level without relying on potentially compromised in-pod tools or deleting the pod (which could be recreated by the Deployment controller).

Exam trap

CNCF often tests the misconception that `kubectl delete pod` is sufficient for containment, but the trap here is that a Deployment controller will immediately recreate the pod, so you must either scale the Deployment to 0 (which destroys evidence) or directly stop the container at the runtime level using `crictl stop`.

How to eliminate wrong answers

Option A is wrong because using `kubectl exec -it <pod> -- bash` to inspect the container assumes the container has a shell and that the shell is not compromised; the attacker may have disabled or replaced `bash`, and any commands run inside could be tampered with or alert the attacker. Option B is wrong because scaling the Deployment to 0 replicas deletes all pods, destroying forensic evidence and potentially triggering the Deployment's restart policy or a ReplicaSet recreation, and it does not isolate the specific compromised container for investigation. Option C is wrong because Falco logs may not contain the exact pod name if the default rules do not capture outbound C2 traffic or if the alert is not triggered; additionally, `kubectl delete pod` will cause the Deployment controller to immediately recreate the pod, failing to contain the threat.

Full explanation →

470

MCQmedium

A pod is running with a custom seccomp profile located at /var/lib/kubelet/seccomp/my-profile.json. Which securityContext configuration correctly applies this profile?

A.seccompProfile: { type: RuntimeDefault }

B.seccompProfile: { type: Localhost, localhostProfile: my-profile.json }

C.seccompProfile: { type: Localhost, localhostProfile: /var/lib/kubelet/seccomp/my-profile.json }

D.seccompProfile: { type: Unconfined }

AnswerB

seccompProfile: { type: Localhost, localhostProfile: my-profile.json } is correct because Localhost explicitly tells Kubernetes to load a seccomp profile from a file on the node, and localhostProfile names that file relative to the kubelet's seccomp root directory, which defaults to /var/lib/kubelet/seccomp/. As long as my-profile.json is placed in that directory, Kubernetes constructs the absolute path /var/lib/kubelet/seccomp/my-profile.json and applies it to the container. This is the intended way to reference a custom profile, and the exact filename must match the file that exists on the node.

Why this answer

When using a custom seccomp profile stored on the node, the `type` must be `Localhost` and the `localhostProfile` field must specify only the filename (not the full path). Kubernetes automatically prepends the default seccomp profile path `/var/lib/kubelet/seccomp/` to the `localhostProfile` value, so `my-profile.json` resolves to the correct location.

Exam trap

The trap here is that candidates mistakenly provide the full absolute path in `localhostProfile`, not realizing that Kubernetes automatically prepends the default seccomp directory, leading to a double-path error.

How to eliminate wrong answers

Option A is wrong because `RuntimeDefault` uses the container runtime's default seccomp profile, not the custom profile at `/var/lib/kubelet/seccomp/my-profile.json`. Option C is wrong because `localhostProfile` should contain only the profile filename (e.g., `my-profile.json`), not the full absolute path; specifying the full path would cause Kubernetes to look for the file at `/var/lib/kubelet/seccomp//var/lib/kubelet/seccomp/my-profile.json`, which does not exist. Option D is wrong because `Unconfined` disables seccomp entirely, which is the opposite of applying a custom seccomp profile and violates the principle of least privilege.

Full explanation →

471

MCQmedium

You need to encrypt etcd data at rest using AES-CBC. Which encryption provider should you specify in the EncryptionConfiguration?

A.aesgcm

B.aescbc

C.aes-256-cbc

D.secretbox

AnswerB

aescbc is the exact, built-in provider name for AES-CBC encryption at rest in Kubernetes. It uses AES in CBC mode with a random initialization vector prepended to the ciphertext and PKCS#7 padding, and requires a 32-byte key for AES-256 strength. This provider is explicitly supported in EncryptionConfiguration and is the correct answer for encrypting etcd data with AES-CBC.

Why this answer

(aescbc) is correct because Kubernetes supports AES-CBC encryption via the 'aescbc' provider in the EncryptionConfiguration. This provider uses AES in Cipher Block Chaining mode with a 32-byte key for encryption at rest, as specified in the Kubernetes documentation for encrypting etcd data.

Exam trap

The trap here is that candidates confuse the Kubernetes provider name 'aescbc' with the generic algorithm name 'aes-256-cbc' or other encryption modes like 'aesgcm', but the exam expects exact knowledge of the Kubernetes-specific provider identifiers as defined in the official documentation.

How to eliminate wrong answers

Option A (aesgcm) is wrong because AES-GCM is an authenticated encryption mode that requires a unique nonce per key and is not recommended for encrypting etcd data at rest due to nonce reuse risks and lack of support as a standalone provider in Kubernetes EncryptionConfiguration. Option C (aes-256-cbc) is wrong because Kubernetes does not recognize 'aes-256-cbc' as a valid provider name; the correct identifier is 'aescbc', and the key length is determined by the key file, not the provider string. Option D (secretbox) is wrong because Secretbox is a NaCl-based encryption scheme using XSalsa20-Poly1305, which is not a built-in provider in Kubernetes; it would require a custom implementation or is used in other contexts like libsodium.

Full explanation →

472

Matchingmedium

Match each Kubernetes admission controller to its role in security.

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

Concepts

Matches

Limits the Node and Pod objects a kubelet can modify

Ensures images are always pulled, preventing use of local images

Denies pods with certain security context settings (deprecated)

Implements automation for service accounts

Enforces namespace-level node selector restrictions

Why these pairings

Admission controllers intercept requests to the API server and can enforce security policies.

Full explanation →

473

Multi-Selectmedium

Which TWO of the following are valid methods to ensure only signed images are deployed in a Kubernetes cluster?

Select 2 answers

A.Configure ImagePolicyWebhook to require signatures

B.Set imagePullPolicy: Always

C.Run 'cosign verify' manually before every deployment

D.Use Kyverno policy to verify image signatures

E.Use NodeRestriction admission controller

AnswersA, D

This admission controller intercepts Pod creation requests and sends the image reference to an external webhook endpoint that performs signature verification (e.g., using sigstore/cosign) before returning an admission response. If the webhook rejects the image as unsigned, the API server refuses to admit the Pod, enforcing the policy cluster-wide at admission time. Because the check happens automatically during the API request lifecycle, it cannot be skipped by operators or developers.

Why this answer

The ImagePolicyWebhook admission controller can be configured to reject pods that reference images without valid signatures. It works by sending an admission review request to an external webhook service (e.g., using Cosign or Notary) that validates the image signature before allowing the pod to be created. This enforces signature verification at admission time, preventing unsigned images from running in the cluster.

Exam trap

CNCF CKS often tests the distinction between admission control mechanisms and runtime or manual verification; the trap here is that candidates may think manual verification (Option C) or pull policies (Option B) are sufficient for cluster-wide enforcement, when in fact only admission controllers or policy engines that intercept pod creation can guarantee that only signed images are deployed.

Full explanation →

474

Multi-Selecthard

Which THREE of the following are common indicators of a container compromise that Falco can detect? (Select 3)

Select 3 answers

A.Unexpected outbound network connections

B.Reading sensitive files like /etc/shadow

C.High CPU usage

D.Spawning a shell inside a container

E.Pod restarting in a loop

AnswersA, B, D

Falco monitors the connect() syscall as applications initiate TCP or UDP outbound traffic, so an unexpected destination IP, port, or domain pattern for a given container image can signal data exfiltration or command-and-control activity. Unlike high-level metrics, this is a definitive, event-level behavioral indicator because it captures the exact moment a new network connection is established, and allows correlation with process context.

Why this answer

Falco is a runtime security tool that monitors system calls and container behavior. Unexpected outbound network connections are a classic indicator of compromise, such as a reverse shell or data exfiltration, and Falco can detect these by monitoring syscalls like `connect()` and `sendto()` against a rule set that flags connections to suspicious destinations or on unusual ports.

Exam trap

The CKS exam often tests the distinction between runtime security monitoring (syscall-based) and cluster-level or resource-level metrics, so the trap here is confusing operational issues like pod restarts or high CPU with actual security events that Falco is designed to detect.

Full explanation →

475

MCQhard

A security team wants to use OPA/Gatekeeper to enforce that all namespaces must have a label 'security-tier' with value 'high' or 'medium'. What is the correct approach?

A.Write a MutatingWebhookConfiguration that adds the label automatically.

B.Use kubectl label command with a --validate flag.

C.Create a ValidatingWebhookConfiguration that directly contains the Rego policy.

D.Create a ConstraintTemplate with Rego that denies namespaces missing the label, then create a Constraint referencing that template.

AnswerD

This is the canonical OPA Gatekeeper workflow. A ConstraintTemplate defines a reusable Rego policy (e.g., detecting a missing required label) and specifies the target resource kind, such as namespaces. A Constraint then instantiates that template, setting the required label parameter and enforcing it against all namespaces. When a label-less namespace creation is attempted, the Gatekeeper admission webhook evaluates the Rego and rejects it, satisfying the 'deny namespaces missing the label' requirement.

Why this answer

OPA/Gatekeeper enforces policies via a two-part model: a ConstraintTemplate defines the Rego logic (e.g., denying a namespace if it lacks the required label), and a Constraint instantiates that template with specific parameters (e.g., 'security-tier' with values 'high' or 'medium'). This decouples policy definition from enforcement, allowing Gatekeeper's admission webhook to reject non-compliant resources at creation or update time.

Exam trap

The key distinction in OPA/Gatekeeper is between mutation (MutatingWebhookConfiguration) and validation (ValidatingWebhookConfiguration), and that policies must be defined via ConstraintTemplates and Constraints, not embedded directly in webhook configurations.

How to eliminate wrong answers

Option A is wrong because MutatingWebhookConfiguration can add labels automatically, but the question requires enforcement (denial), not mutation; also, OPA/Gatekeeper uses ValidatingWebhookConfiguration, not MutatingWebhookConfiguration, for policy enforcement. Option B is wrong because kubectl label with a --validate flag does not exist; kubectl validate is not a native command for enforcing OPA policies. Option C is wrong because a ValidatingWebhookConfiguration cannot directly contain Rego policy; it only registers the webhook endpoint (e.g., Gatekeeper's service), while the actual Rego logic resides in ConstraintTemplates and Constraints.

Full explanation →

476

MCQhard

A pod is stuck in Pending state. You run 'kubectl describe pod' and see the event: '0/3 nodes are available: 3 Insufficient cpu'. What is the likely cause?

A.The pod's image pull policy is set to Always and the registry is unreachable

B.The pod's CPU request exceeds the available CPU capacity on all nodes

C.The cluster has a taint that the pod does not tolerate

D.The scheduler is misconfigured and not running

AnswerB

The scheduler computes the sum of CPU requests for existing pods and compares it against each node's allocatable CPU capacity. If the requested CPU for this pod is greater than any node's available (allocatable minus already requested) CPU, the scheduler emits a FailedScheduling event with 'Insufficient cpu' and lists the nodes that could not fit. As a result, the pod remains Pending until a node's resources change or the request is reduced. This is exactly the situation indicated by an Insufficient cpu event.

Why this answer

The event '0/3 nodes are available: 3 Insufficient cpu' directly indicates that the scheduler attempted to place the pod on each of the three nodes but found that none had enough allocatable CPU to satisfy the pod's CPU request. This means the sum of CPU requests across all pods on each node, plus the new pod's request, exceeds the node's capacity. The pod remains in Pending state because no node can accommodate its resource requirements.

Exam trap

In the CKS exam, you must carefully read the event message to distinguish between resource insufficiency (Insufficient cpu) and other scheduling issues like taints/tolerations or node selectors.

How to eliminate wrong answers

Option A is wrong because an unreachable registry would cause ImagePullBackOff or ErrImagePull events, not 'Insufficient cpu' — the scheduler does not check image availability before scheduling. Option C is wrong because taint/toleration mismatches produce events like '0/3 nodes are available: 3 node(s) had taint {key:value}, that the pod didn't tolerate', not a CPU insufficiency message. Option D is wrong because if the scheduler were misconfigured or not running, the pod would remain in Pending state without any scheduling events at all, or you would see 'no matching node' errors, not a specific resource insufficiency message.

Full explanation →

477

MCQmedium

In a CI/CD pipeline, at which stage should container image scanning be performed?

A.Only when a vulnerability is reported

B.After deployment to production

C.Before code commit

D.After building the image but before pushing to registry

AnswerD

Scanning after the image is built but before it is pushed to the registry is the earliest and most effective security gate because the image has been fully assembled into its final layered form. This stage lets you catch vulnerabilities in the base OS packages, application dependencies, and any added binaries before the image is stored in a trusted registry and made available for deployment. By blocking the push of non-compliant images, you keep vulnerable artifacts out of the supply chain entirely, ensuring that only vetted images reach Kubernetes clusters or runtime environments.

Why this answer

Container image scanning should be performed after building the image but before pushing it to the registry (Option D). This ensures that vulnerabilities are detected before the image is stored and distributed, preventing insecure images from being deployed. Scanning at this stage integrates security into the CI/CD pipeline, allowing teams to fail the build or trigger remediation before the image reaches production.

Exam trap

The CKS exam tests the concept of 'shift left' in security, and the trap here is that candidates may think scanning before code commit (Option C) is valid, but container images are not built until after the commit, so scanning must occur on the built image artifact.

How to eliminate wrong answers

Option A is wrong because scanning only when a vulnerability is reported is reactive and leaves the pipeline open to known vulnerabilities that could have been caught earlier. Option B is wrong because scanning after deployment to production violates the principle of shifting security left, as vulnerabilities are already running in the live environment, increasing risk and remediation cost. Option C is wrong because scanning before code commit is impractical—container images don't exist yet at that stage; scanning should occur on the built artifact, not source code.

Full explanation →

478

MCQmedium

Which of the following is the correct way to drop all Linux capabilities for a container?

A.capability: drop: ["ALL"]

B.capabilities: drop: ["NET_RAW", "CHOWN"]

C.capabilities: drop: ["ALL"]

D.capabilities: add: ["ALL"]

AnswerC

This is the correct and idiomatic way to drop all Linux capabilities in a Kubernetes container. The plural `capabilities` field is recognized by the securityContext schema, and the special case-insensitive token `ALL` (conventionally uppercase) instructs the runtime to remove every capability from the container's effective, permitted, and inherited sets. The result is a process with no capabilities, ideal for least-privilege workloads.

Why this answer

In a Kubernetes Pod security context, the `capabilities` field is a list of capabilities to add or drop. Dropping `ALL` removes all Linux capabilities from the container, which is the most restrictive and secure approach. The correct YAML syntax uses `capabilities:` (plural) with a `drop:` list containing `"ALL"`.

Exam trap

CNCF often tests the distinction between singular `capability` and plural `capabilities` in the YAML field name, as well as the difference between `drop: ["ALL"]` and `add: ["ALL"]`, to catch candidates who misremember the exact syntax or confuse dropping with adding capabilities.

How to eliminate wrong answers

Option A is wrong because it uses `capability:` (singular) instead of the correct `capabilities:` (plural) field name in the Pod security context. Option B is wrong because it drops only specific capabilities (`NET_RAW` and `CHOWN`) rather than all capabilities, which does not achieve the goal of dropping all Linux capabilities. Option D is wrong because it adds `ALL` capabilities, which grants every capability to the container, the opposite of what is required.

Full explanation →

479

MCQmedium

You want to run a container with gVisor (runsc) runtime for sandboxing. Which resource is required to use a non-default runtime?

A.PodSecurityPolicy

B.ContainerRuntime resource

C.RuntimeClass resource

D.Node runtime configuration only

AnswerC

RuntimeClass is the correct mechanism because it is a cluster-scoped resource that maps a runtime handler name (for example, runsc) to a specific CRI runtime available on nodes. A pod opts into that runtime by setting the runtimeClassName field in its spec. The kubelet reads this field and launches the pod using the corresponding handler, which for gVisor means the runsc OCI runtime executes the container inside a user-space kernel. This abstraction allows you to mix sandboxed and regular pods on the same cluster and update the runtime implementation without changing pod specs.

Why this answer

In Kubernetes, to use a non-default runtime like gVisor (runsc), you must define a RuntimeClass resource that references the runtime handler (e.g., 'runsc') configured on the node. The RuntimeClass acts as a bridge between the Pod spec and the node's container runtime configuration, allowing the scheduler to select the appropriate runtime for sandboxing. Without a RuntimeClass, the default runtime (typically runc) is used, which does not provide the same isolation level.

Exam trap

The CKS exam often tests the misconception that node-level runtime installation alone is sufficient to use a non-default runtime, but the CKS exam emphasizes that a RuntimeClass resource must be created and referenced in the Pod spec to enable runtime selection.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (deprecated in v1.21 and removed in v1.25) controls security contexts and pod-level permissions, not the selection of container runtimes. Option B is wrong because there is no native 'ContainerRuntime' resource in Kubernetes; runtime selection is handled via RuntimeClass, not a dedicated resource for the runtime itself. Option D is wrong because node runtime configuration alone is insufficient; while the node must have the runtime installed and configured, the Pod must explicitly reference a RuntimeClass to opt into using that non-default runtime.

Full explanation →

480

MCQeasy

Which command is used to load an AppArmor profile into the kernel?

A.aa-status

B.apparmor_parser

C.aa-load

D.aa-enforce

AnswerB

`apparmor_parser` compiles an AppArmor profile from its text source and loads it into the kernel, satisfying the requirement to activate a profile. It is the standard userspace tool for this task, unlike `aa-status`, which only reports loaded profiles, or `apparmor_status`, which merely displays enforcement state.

Why this answer

The `apparmor_parser` command is used to load AppArmor profiles into the kernel by parsing the profile file and adding it to the kernel's security module. This is the standard utility for loading, reloading, and removing AppArmor profiles, making option B correct.

Exam trap

The trap here is that candidates confuse `aa-enforce` (which changes the mode of an already loaded profile) with loading a profile, or they assume `aa-load` is a real command due to its intuitive name.

How to eliminate wrong answers

Option A is wrong because `aa-status` is used to check the status of AppArmor profiles (e.g., which profiles are loaded or enforced), not to load them into the kernel. Option C is wrong because `aa-load` is not a valid AppArmor command; the correct command for loading profiles is `apparmor_parser`. Option D is wrong because `aa-enforce` is used to set an already loaded profile to enforce mode, not to load the profile itself.

Full explanation →

481

MCQmedium

An admin runs 'kubectl describe pod secure-pod' and sees 'seccompProfile: RuntimeDefault' under the container's security context. Which seccomp profile is being used?

A.A custom seccomp profile from '/var/lib/kubelet/seccomp/' is used

B.The container runtime's default seccomp profile is applied

C.The container runtime's seccomp profile is set to 'Unconfined'

D.Seccomp is disabled for this container

AnswerB

When the pod's seccomp profile is set to `RuntimeDefault`, the container runtime (e.g., containerd or CRI-O) applies its own default seccomp filter, which restricts a known set of dangerous or unnecessary system calls while still allowing normal container operations. This is a deliberate security configuration that enables seccomp enforcement without requiring an operator to craft and distribute a custom profile. It is the recommended baseline for secure pods because it blocks a larger attack surface than leaving seccomp unconfined.

Why this answer

When `seccompProfile` is set to `RuntimeDefault` in a container's security context, Kubernetes instructs the container runtime (e.g., containerd, CRI-O) to apply its own default seccomp profile. This profile is typically a restrictive set of syscalls that blocks dangerous or unnecessary system calls while allowing common operations. It is not a custom profile from the node's filesystem, nor does it disable seccomp or set it to unconfined.

Exam trap

The trap here is that candidates confuse `RuntimeDefault` with a custom profile stored on the node's filesystem, or mistakenly think it disables seccomp entirely, when in fact it instructs the runtime to apply its own pre-configured default seccomp filter.

How to eliminate wrong answers

Option A is wrong because `RuntimeDefault` does not reference a custom profile from `/var/lib/kubelet/seccomp/`; that path is used for `Localhost` profiles only. Option C is wrong because `RuntimeDefault` explicitly applies the runtime's default profile, not `Unconfined`, which would disable seccomp entirely. Option D is wrong because `RuntimeDefault` means seccomp is enabled and enforced by the runtime's default rules, not disabled.

Full explanation →

482

MCQeasy

You have deployed a pod and set `securityContext.readOnlyRootFilesystem: true`. The pod is failing to start with an error about writing to `/tmp`. What is the most likely cause?

A.The `securityContext` is misspelled

B.The pod is missing an emptyDir volume mounted at `/tmp`

C.The container image does not have `/tmp` directory

D.The container is running as a non-root user

AnswerB

The correct fix is to create a dedicated emptyDir volume and mount it at /tmp. When readOnlyRootFilesystem is true, the container's root filesystem is mounted with the MS_RDONLY flag, so every write attempt to any path on that filesystem returns EROFS — regardless of permissions. An emptyDir volume provides a separate, writable filesystem (initially empty, typically backed by the node's disk or tmpfs) that can be mounted exactly where the application expects to write temporary data, allowing the container to work while preserving the immutability of the root filesystem.

Why this answer

When `securityContext.readOnlyRootFilesystem: true` is set, the container's root filesystem becomes read-only. Many applications, including those that write temporary files, expect to write to `/tmp`. Without a writable volume mounted at `/tmp`, the container fails to start because it cannot write to that directory.

Mounting an `emptyDir` volume at `/tmp` provides a writable location that is ephemeral and tied to the pod's lifecycle, resolving the issue.

Exam trap

The exam often tests the misconception that a read-only root filesystem prevents all writes, but candidates may overlook the need for an explicit writable volume mount like emptyDir for directories such as /tmp that applications expect to be writable.

How to eliminate wrong answers

Option A is wrong because `securityContext` is a valid Kubernetes field and is not misspelled; the error is about filesystem permissions, not a syntax issue. Option C is wrong because the container image does have a `/tmp` directory (it is part of the Linux filesystem hierarchy), but it is read-only due to the security context. Option D is wrong because running as a non-root user does not prevent writing to `/tmp` if the directory is writable; the problem is the read-only root filesystem, not the user ID.

Full explanation →

483

MCQeasy

Which annotation is used to apply an AppArmor profile to a pod in Kubernetes?

A.seccomp.security.alpha.kubernetes.io/pod

B.apparmor.security.beta.kubernetes.io/profile

C.container.apparmor.security.beta.kubernetes.io/<container_name>

D.container.apparmor.kubernetes.io/<container_name>

AnswerC

This is the correct annotation for applying an AppArmor profile to an individual container. The key embeds the container name, letting the kubelet map the profile to the container's processes, and the value uses forms like `runtime/default`, `localhost/<profile>`, or `unconfined`. It is a beta annotation but remains the standard way to enforce AppArmor on clusters that predate the newer structured `appArmorProfile` field.

Why this answer

The annotation `container.apparmor.security.beta.kubernetes.io/<container_name>` is the standard annotation used to apply an AppArmor profile to a specific container within a pod. The `<container_name>` placeholder must be replaced with the actual container name, and the annotation value specifies the profile (e.g., `localhost/profile-name` or `runtime/default`). This annotation is in the `security.beta.kubernetes.io` API group, reflecting its beta status in Kubernetes.

Exam trap

Candidates often confuse the annotation format for AppArmor with that of seccomp or forget the `container.` prefix and the required `security.beta` subdomain, leading them to pick Option B or D.

How to eliminate wrong answers

Option A is wrong because `seccomp.security.alpha.kubernetes.io/pod` is the annotation for applying seccomp profiles, not AppArmor profiles. Option B is wrong because `apparmor.security.beta.kubernetes.io/profile` is a malformed annotation; the correct annotation requires the `container.` prefix and the container name as a suffix, not just `/profile`. Option D is wrong because `container.apparmor.kubernetes.io/<container_name>` omits the required `security.beta` subdomain, which is part of the official annotation key for AppArmor support in Kubernetes.

Full explanation →

484

Multi-Selectmedium

Which TWO actions are effective for detecting and preventing container breakout attempts using runtime security tools?

Select 2 answers

A.Set 'securityContext.seccompProfile.type: Unconfined' to allow all syscalls.

B.Enable Kubernetes audit logging to capture exec commands.

C.Use PodSecurityPolicy to deny privileged containers.

D.Deploy Falco with rules that alert on 'syscall' events like 'clone' or 'unshare'.

E.Apply a seccomp profile that blocks unneeded syscalls for each container.

AnswersD, E

Falco is a runtime security tool that monitors system calls using kernel instrumentation (e.g., eBPF) and can emit real-time alerts when suspicious syscalls occur. Rules that alert on `clone`, `unshare`, `setns`, or similar syscalls are specifically designed to detect container breakout attempts, such as a process creating a new namespace to gain host-level visibility, or attaching to a host process. This detection is proactive: it catches the early stages of an attack and enables immediate response, rather than passively logging events. Falco's syscall-based alerting directly addresses the container-container and container-host boundaries, making it an effective detection mechanism for potential compromises.

Why this answer

Falco is a CNCF runtime security tool that uses eBPF or kernel modules to intercept system calls. By alerting on sensitive syscalls like 'clone' (used to spawn new processes) or 'unshare' (used to create new namespaces), Falco can detect container breakout attempts where an attacker tries to escape the container's isolation. This provides real-time detection of anomalous behavior indicative of a breakout.

Exam trap

CNCF often tests the distinction between admission control (e.g., PodSecurityPolicy, OPA/Gatekeeper) and runtime security (e.g., Falco, seccomp, AppArmor), leading candidates to select admission-based options like PodSecurityPolicy when the question explicitly asks for runtime security tools.

Full explanation →

485

MCQmedium

A security team wants to detect any attempt to spawn an interactive shell inside a container. Which Falco rule condition would be appropriate?

A.container.id != host and evt.type = read and fd.name = /etc/shadow

B.evt.type = connect and container.id != host

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

D.container.id != host and evt.type = execve and proc.name = bash

AnswerD

This is the exact Falco rule needed: it combines the execve syscall (new process execution), proc.name = bash (the shell binary), and container.id != host (restricting to container events). The combination logically isolates the moment a bash shell is spawned from inside a container while excluding host-level bash runs, giving a high-fidelity signal for interactive shell activity. Because it checks the syscall that actually creates the process, it correctly captures shell starts rather than related but distinct activities like file reads or network connections.

Why this answer

Falco uses syscall events. The condition container.id != host and evt.type = execve and proc.name = bash detects a bash exec in a container, which is a common interactive shell.

Full explanation →

486

MCQeasy

Given the following PodSecurityPolicy (PSP) snippet, which statement about the allowed containers is correct?

A.Containers can run in privileged mode

B.Containers cannot use ConfigMap volumes

C.Containers must run as the root user

D.Containers cannot add any Linux capabilities

AnswerD

The PSP uses `requiredDropCapabilities: ['ALL']` and does not define `allowedCapabilities`, meaning every Linux capability is dropped and none can be added. Containers therefore cannot add any Linux capabilities. This option accurately describes the policy's effect, making it the correct answer.

Why this answer

The PodSecurityPolicy snippet does not include `allowedCapabilities` or sets it to an empty list, and the `defaultAddCapabilities` is not specified, meaning no Linux capabilities are added by default. Additionally, the `requiredDropCapabilities` field is not present, but the absence of any allowed capabilities effectively prevents containers from adding any Linux capabilities beyond the default set, which is restricted by the PSP's `allowedCapabilities: []` or lack thereof. This enforces a strict security posture where containers cannot gain extra privileges via capabilities.

Exam trap

The trap here is that candidates often assume the absence of `allowedCapabilities` means all capabilities are allowed, but in PSP, an empty or missing `allowedCapabilities` list actually denies all non-default capabilities, which is a subtle but critical distinction tested in the CKS exam.

How to eliminate wrong answers

Option A is wrong because the PSP snippet does not set `privileged: true`; by default, `privileged` is false, preventing containers from running in privileged mode. Option B is wrong because ConfigMap volumes are allowed by default unless explicitly denied via `volumes` field; the snippet does not list ConfigMap in a `volumes` blacklist or restrict it. Option C is wrong because the PSP does not specify `runAsUser: rule: MustRunAsNonRoot` or `runAsUser: rule: RunAsAny`; without a `runAsUser` rule, containers are not forced to run as root, and the default behavior allows any user ID unless constrained.

Full explanation →

487

Multi-Selecthard

Which THREE of the following are effective methods to preserve evidence during a container security incident?

Select 3 answers

A.Delete the pod immediately

B.Take a memory dump of the container

C.Run kubectl exec to explore and modify files

D.Create a forensic snapshot of the container filesystem

E.Capture container logs

AnswersB, D, E

Taking a memory dump preserves the ephemeral volatile data that exists only inside the running container's user-space processes and its shared host kernel view. Tools like `gcore` on the container PID, or CRIU-based dump, capture open file descriptors, decrypted secrets, injected shellcode, and active network socket states that vanish when the container stops. This is critical for detecting in-memory-only attacks (e.g., process hollowing) that leave no disk footprint, and it should be performed before the container is terminated or filesystem is altered.

Why this answer

Taking a memory dump of the container captures volatile data (processes, network connections, encryption keys) that is lost when the container stops. This preserves runtime evidence critical for forensic analysis, as memory artifacts are not persisted to disk and must be collected before the container is terminated.

Exam trap

A common trap is confusing incident response containment (which may require isolating the pod via network policies or cordoning the node) with evidence preservation (which requires capturing data before deletion). Immediate pod deletion destroys evidence and should be avoided until forensic data is collected.

Full explanation →

488

MCQmedium

An administrator runs 'crictl ps' and sees no containers listed, but kubectl shows running pods. What is the most likely cause?

A.crictl is not configured to connect to the correct container runtime socket

B.The images have not been pulled yet

C.The containers are running in a different namespace

D.The kubelet is not running

AnswerA

crictl is a CLI that communicates with a CRI-compliant runtime via a gRPC endpoint, and it must be told where that runtime's socket lives via the --runtime-endpoint flag or a configuration file such as /etc/crictl.yaml. If it points to a default or stale socket (for example /var/run/dockershim.sock instead of /run/containerd/containerd.sock), it will not see the containers managed by the actual containerd or CRI-O runtime. Even though pods are running, a misconfigured runtime endpoint commonly produces a misleading empty list or a connection error, so this is the correct explanation.

Why this answer

The most likely cause is that crictl is not configured to connect to the correct container runtime socket. crictl is a command-line tool for interacting with CRI-compatible container runtimes. If it is not pointed to the correct socket (e.g., /var/run/containerd/containerd.sock or /var/run/crio/crio.sock), it will not see any containers, even though kubectl (which communicates with the kubelet) shows running pods. This is a common misconfiguration when multiple runtimes are installed or when the default socket path differs.

Exam trap

CKS often tests the distinction between kubectl and crictl; candidates might think crictl is namespace-aware or that it relies on the kubelet, but it directly queries the container runtime, so socket misconfiguration is a common trap.

How to eliminate wrong answers

Option B is wrong because if images have not been pulled, the containers would not be running, and kubectl would not show running pods. Option C is wrong because crictl operates at the node level and is not namespace-aware in the Kubernetes sense; it lists all containers regardless of Kubernetes namespaces. Option D is wrong because if the kubelet were not running, kubectl would not show running pods (assuming kubectl is communicating with the cluster and the node is not ready).

Full explanation →

489

MCQmedium

An administrator needs to apply a seccomp profile to a Pod. The profile is defined in a file named audit.json located on each node at /var/lib/kubelet/seccomp/profiles/audit.json. The cluster is running Kubernetes 1.25. Which seccomp type should be used in the Pod's securityContext to reference this profile?

A.Localhost

B.Unconfined

C.RuntimeDefault

D.DockerDefault

AnswerA

The Localhost seccomp type allows referencing a profile file that resides on the node's filesystem. The path is relative to the kubelet's seccomp profile root directory, typically /var/lib/kubelet/seccomp. Given the file at /var/lib/kubelet/seccomp/profiles/audit.json, the correct localhostProfile value would be profiles/audit.json, and the type must be Localhost.

Why this answer

To use a custom seccomp profile stored on the node, the seccomp type must be set to Localhost, and the localhostProfile field must specify the path relative to the kubelet's seccomp root directory. RuntimeDefault uses a predefined profile, Unconfined disables seccomp, and DockerDefault is not a valid Kubernetes seccomp type. Therefore, Localhost is the correct choice.

Exam trap

The trap here is assuming that RuntimeDefault can be customized with a file path; only Localhost supports referencing a profile file on the node.

Full explanation →

490

MCQeasy

Which audit stage is logged after the request is fully processed and the response is sent?

A.Panic

B.ResponseComplete

C.ResponseStarted

D.RequestReceived

AnswerB

ResponseComplete is emitted after the API server has sent the entire HTTP response, including the body, to the client. This stage means all processing phases — authentication, authorization, admission, and any mutation or storage operations — have finished and the complete response payload has been transmitted. It is the definitive final audit stage for a fully processed request, making it the correct answer.

Why this answer

The ResponseComplete audit stage is logged after the request is fully processed and the response is sent. It includes the final status and any response data. This stage is the last in the audit logging sequence, following RequestReceived, ResponseStarted, and Panic (if applicable).

Exam trap

CKS often tests the order of audit stages, confusing ResponseStarted with ResponseComplete, leading candidates to pick the wrong stage for after response is sent.

How to eliminate wrong answers

Option A is wrong because Panic is logged when a panic occurs during request processing, not after the response is sent. Option C is wrong because ResponseStarted is logged when the response headers are sent but before the response body is fully sent. Option D is wrong because RequestReceived is logged when the request is first received, before processing.

Full explanation →

491

MCQmedium

You need to detect any attempt to run a shell inside a container using Falco. Which macro or condition should you use?

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

B.evt.type=execve and proc.name in (bash, sh)

C.evt.type=clone and proc.name=bash

D.evt.type=open and fd.name=/bin/bash

AnswerB

This rule is correct because 'execve' is the fundamental Linux syscall that executes a new program by replacing the caller's memory image. In Falco, for an 'execve' event, 'proc.name' is the basename of the new executable, so filtering for 'bash' or 'sh' directly matches the execution of those shell binaries. This aligns exactly with the intended goal of detecting an attempt to run a shell, and it intentionally ignores file access and process creation events that do not themselves indicate shell execution.

Why this answer

Detecting a shell inside a container requires monitoring the execution of shell binaries. Falco's `evt.type=execve` captures process execution events, and `proc.name in (bash, sh)` filters for common shell programs. This combination directly identifies when a shell process is started, which is a strong indicator of interactive access or potential compromise.

Exam trap

The CKS exam often tests the distinction between file access events (open, read) and process execution events (execve), leading candidates to pick options that detect file operations on shell binaries or configuration files instead of actual shell execution.

How to eliminate wrong answers

Option A is wrong because reading `/etc/passwd` is a file access event, not a shell execution; it could indicate reconnaissance but not a shell itself. Option C is wrong because `clone` is the syscall for creating processes or threads, but `proc.name=bash` would match only if the parent process is named bash, not the spawned shell; also, `clone` is too broad and not specific to shell execution. Option D is wrong because opening the `/bin/bash` binary file is a file open event, not execution; it could happen during file copying or inspection without actually running a shell.

Full explanation →

492

MCQmedium

A pod is running in the 'default' namespace with a container that has an immutable root filesystem (readOnlyRootFilesystem: true). The application writes logs to /var/log/app.log. What will happen?

A.The container will be automatically restarted by the kubelet

B.The write succeeds because logs are written to a temporary filesystem

C.The write to /var/log/app.log fails, and the container may crash or log an error

D.Kubernetes will create an emptyDir volume to hold the logs

AnswerC

With readOnlyRootFilesystem: true, any write to a path outside a mounted writable volume returns EROFS (read-only file system). Since /var/log/app.log is inside the container's root filesystem and no volume is mounted at /var/log, the application cannot create or append to that file. The application may catch the error and continue, log to stderr, or exit if log failure is fatal, which would cause the container to crash or be marked as failed.

Why this answer

When a container is configured with `readOnlyRootFilesystem: true`, its entire root filesystem is mounted as read-only. Since `/var/log/app.log` resides within the root filesystem, any attempt to write to it will fail with a permission error. This can cause the application to crash or log an error, depending on how the application handles write failures.

Exam trap

The CKS exam often tests the misconception that Kubernetes automatically handles logging by providing writable space, but in reality, the user must explicitly mount a writable volume when using a read-only root filesystem.

How to eliminate wrong answers

Option A is wrong because the kubelet does not automatically restart a container solely due to a write failure on a read-only filesystem; restarts only occur if the container exits with a non-zero exit code or fails a liveness probe. Option B is wrong because there is no temporary filesystem mounted at `/var/log` by default; the write goes directly to the read-only root filesystem and fails. Option D is wrong because Kubernetes does not automatically create an emptyDir volume to hold logs; the user must explicitly define an emptyDir volume and mount it at the desired path.

Full explanation →

493

Multi-Selecteasy

Which THREE of the following are valid flags for the 'trivy image' command to output results in different formats?

Select 3 answers

A.--format table

B.--format sarif

C.--format xml

D.--format yaml

E.--format json

AnswersA, B, E

The --format table flag explicitly selects the default human-readable output format for Trivy. It prints a tabular view with columns such as Library, Vulnerability, Severity, and Installed Version, making it ideal for terminal inspection but unsuitable for automated parsing. Using this flag is redundant if no format is specified, but it is valid and often used for clarity in scripts.

Why this answer

The `trivy image` command supports multiple output formats via the `--format` flag. The valid formats include `table`, `sarif`, and `json`, which are explicitly documented in Trivy's CLI help. `table` produces a human-readable summary, `sarif` outputs results in the SARIF (Static Analysis Results Interchange Format) standard, and `json` provides structured data for programmatic consumption.

Exam trap

The CKS exam often tests the distinction between Trivy's supported output formats and common but unsupported formats like XML or YAML, exploiting the assumption that any common data serialization format would be valid.

Full explanation →

494

MCQeasy

Which audit policy level logs all requests and responses, including the request body and response body?

A.None

B.Request

C.Metadata

D.RequestResponse

AnswerD

The `RequestResponse` audit level logs the request metadata, the request body, and the response body for matching requests, providing a complete record of the API interaction. This is the only level that enables full reconstruction of what was sent and what the API server returned, including the exact object created, updated, or returned in error. Because it includes potentially sensitive data from both sides, it should be applied selectively (e.g., to Secrets or `exec` endpoints) and is the most resource-intensive level in terms of storage and performance.

Why this answer

RequestResponse logs both the request object and the response object, including bodies. Request logs only the request object. Metadata logs only metadata.

None logs nothing.

Full explanation →

495

MCQmedium

A ValidatingWebhookConfiguration is not working as expected. The webhook server is running and accessible. What is a common misconfiguration that would cause the webhook to not be called?

A.The webhook server uses HTTP instead of HTTPS

B.The webhook service is of type ClusterIP

C.The webhook server returns a 502 status code

D.The 'clientConfig.service.namespace' does not match the namespace of the webhook service

AnswerD

The API server resolves the webhook's address by combining clientConfig.service.name and clientConfig.service.namespace to form a ClusterIP service DNS name (e.g., <service>.<namespace>.svc). If the namespace field does not match the actual namespace where the webhook Service object is created, the API server tries to connect to a non-existent service, DNS resolution fails, and the request never reaches the webhook server. This is a classic misconfiguration that silently prevents admission requests from being sent, and it is the only listed option that directly blocks the call.

Why this answer

The ValidatingWebhookConfiguration's `clientConfig.service.namespace` field must exactly match the namespace where the webhook's Kubernetes Service object resides. If this namespace is misconfigured, the API server cannot resolve the service endpoint to call the webhook, causing the webhook to be silently skipped or fail to be invoked.

Exam trap

In the CKS exam, a common trap is to assume that any HTTP error or connectivity issue would prevent webhook invocation. However, a misconfigured namespace in the `clientConfig.service.namespace` field results in the API server being unable to resolve the service endpoint, causing the webhook to not be called at all, often without any explicit error. This is distinct from issues like TLS misconfiguration that would produce connection errors.

How to eliminate wrong answers

Option A is wrong because the Kubernetes API server requires webhook servers to use HTTPS with a valid TLS certificate; HTTP is not supported and would cause a connection error, not a silent failure. Option B is wrong because a ClusterIP service type is perfectly valid for webhook communication, as the API server can reach it via the cluster network. Option C is wrong because a 502 status code indicates the webhook was called but returned an error; the question states the webhook is 'not being called,' so a response code is irrelevant.

Full explanation →

496

MCQmedium

A security auditor wants to verify that the AppArmor profile 'my-profile' is in enforce mode on a running container. Which command should they run inside the node?

A.cat /proc/<pid>/attr/current

B.dmesg | grep apparmor

C.apparmor_parser -r my-profile

D.cat /proc/<pid>/environ

AnswerA

This is the authoritative per-process interface. The kernel exposes the current AppArmor security label for each task via /proc/<pid>/attr/current; it returns the profile name and mode, such as 'worker-profile (enforce)' or 'unconfined'. Reading this file directly reveals the live confinement state, making it the correct audit check.

Why this answer

The file `/proc/<pid>/attr/current` contains the current AppArmor confinement status for a given process. Reading this file for a container's PID inside the node will show the profile name and mode (e.g., `my-profile (enforce)`), directly confirming that the profile is in enforce mode.

Exam trap

The trap here is that candidates might confuse system-wide AppArmor status commands (like `dmesg` or `apparmor_status`) with the per-process verification method required to check a specific container's enforcement mode.

How to eliminate wrong answers

Option B is wrong because `dmesg | grep apparmor` shows kernel log messages related to AppArmor events (e.g., denials or loading), but it does not show the current enforcement state of a specific profile on a running container. Option C is wrong because `apparmor_parser -r my-profile` reloads the profile from its definition file, but it does not query the current mode of a running process. Option D is wrong because `cat /proc/<pid>/environ` displays the environment variables of a process, which has no relation to AppArmor profile status.

Full explanation →

497

MCQmedium

You need to ensure that all pods in a namespace can only communicate via mTLS. In Istio, which resource should you apply?

A.PeerAuthentication with mode: STRICT

B.DestinationRule with tls: ISTIO_MUTUAL

C.PeerAuthentication with mode: DISABLE

D.PeerAuthentication with mode: PERMISSIVE

AnswerA

PeerAuthentication with mode: STRICT is the correct choice because it enforces mutual TLS at the workload level, requiring every connection to be authenticated via both client and server certificates. In this mode, the sidecar proxy rejects any plaintext or unauthenticated traffic, guaranteeing that all pod-to-pod communication in the namespace uses mTLS. This is the standard Istio mechanism for mandating strict mTLS across a namespace or mesh.

Why this answer

PeerAuthentication with mode: STRICT is the correct resource to enforce mTLS for all pods in a namespace. It configures the Istio sidecar proxy to require mutual TLS for all inbound and outbound traffic within the mesh, rejecting any plaintext connections. This ensures that all inter-pod communication is encrypted and authenticated using X.509 certificates, aligning with the goal of minimizing microservice vulnerabilities.

Exam trap

In the CKS exam, candidates often confuse PeerAuthentication (which enforces mTLS at the server side) and DestinationRule (which configures client-side TLS settings), leading to mistakenly choosing DestinationRule when the question asks for enforcing mTLS across all pods.

How to eliminate wrong answers

Option B is wrong because DestinationRule with tls: ISTIO_MUTUAL configures the client-side TLS settings for traffic to a specific host, but it does not enforce mTLS on the server side or across all pods in a namespace; it works in conjunction with PeerAuthentication but alone cannot mandate mTLS for all traffic. Option C is wrong because PeerAuthentication with mode: DISABLE explicitly disables mTLS, allowing plaintext traffic, which is the opposite of the requirement. Option D is wrong because PeerAuthentication with mode: PERMISSIVE allows both plaintext and mTLS traffic, which does not ensure that all pods communicate only via mTLS; it is typically used during migration to avoid breaking existing connections.

Full explanation →

498

Multi-Selecthard

Which THREE of the following are recommended practices for securing Kubernetes Dashboard?

Select 3 answers

A.Disable anonymous access to Dashboard

B.Expose Dashboard via NodePort service on all nodes

C.Use RBAC to grant Dashboard service account only necessary permissions

D.Avoid exposing Dashboard over the public internet

E.Create a ClusterRole with full cluster admin access for Dashboard

AnswersA, C, D

The Dashboard's bundled v1.7 and earlier manifests historically bound the service account to cluster-admin and permitted unauthenticated access, which lets anyone who can reach the Dashboard URL control the cluster. Disabling anonymous access forces every request through Kubernetes authentication, ensuring the Dashboard's TLS endpoint rejects unauthenticated users before any API action is attempted. This directly closes the known CVE-2018-18264 vector where anonymous users could leverage Dashboard's service account to execute commands in pods.

Why this answer

The Kubernetes Dashboard, by default, may allow unauthenticated access if not explicitly configured. Disabling anonymous access ensures that all requests to the Dashboard are authenticated, preventing unauthorized users from viewing or manipulating cluster resources. This is typically done by setting the `--enable-skip-login` flag to false or configuring the Dashboard deployment to require authentication tokens.

Exam trap

CNCF often tests the principle of least privilege by presenting options that seem convenient (like full admin access or NodePort exposure) but violate security best practices, and the trap here is that candidates may think exposing the Dashboard via NodePort is acceptable for internal access, ignoring that it bypasses authentication layers and network segmentation.

Full explanation →

499

Multi-Selectmedium

Which TWO of the following are best practices for hardening Kubernetes Dashboard?

Select 2 answers

A.Grant minimal RBAC permissions to Dashboard service account

B.Do not expose Dashboard via a public LoadBalancer Service

C.Use HTTP to avoid certificate management

D.Use the default service account with cluster-admin binding

E.Enable anonymous access for simplicity

AnswersA, B

Granting minimal RBAC permissions to the dashboard service account enforces the principle of least privilege. Instead of a cluster-admin binding, create a dedicated Role and RoleBinding that only allows read-only access to specific resources, like pods and logs, within a single namespace. This limits the blast radius if the dashboard or its service account token is compromised, preventing an attacker from deleting or modifying cluster-wide resources.

Why this answer

The Kubernetes Dashboard should run with the least privilege necessary. Granting minimal RBAC permissions to the Dashboard's service account follows the principle of least privilege, reducing the attack surface if the Dashboard is compromised. The default installation often creates a service account with excessive permissions, which should be scoped down to only what the Dashboard needs to function.

Exam trap

CNCF often tests the misconception that 'more permissions make the Dashboard work better' or that 'HTTP is simpler and acceptable for internal use,' but the correct approach is to always enforce TLS and minimal RBAC, as the exam expects you to prioritize security over convenience.

Full explanation →

500

MCQeasy

A Kubernetes administrator is reviewing the cluster's RBAC configuration and notices that a ClusterRoleBinding grants the cluster-admin role to the system:anonymous user. What is the most immediate and appropriate action to harden the cluster?

A.Add an RBAC rule to deny all actions for system:anonymous.

B.Enable the NodeRestriction admission controller to limit anonymous access.

C.Delete the ClusterRoleBinding to revoke anonymous cluster-admin access.

D.Modify the ClusterRoleBinding to bind to a specific user instead of system:anonymous.

AnswerC

Deleting the ClusterRoleBinding immediately removes the excessive privileges granted to the system:anonymous user, preventing unauthenticated users from performing administrative actions. This is the most direct and critical remediation step to close the security hole. Leaving it in place would allow anyone to take full control of the cluster, so removal is essential for hardening.

Why this answer

The most immediate action is to delete the ClusterRoleBinding that grants cluster-admin to system:anonymous. This binding allows unauthenticated users to have full administrative privileges, which is a severe security risk. Removing it eliminates the exposure.

Other options either do not address the binding or rely on incorrect RBAC mechanics.

Exam trap

The trap here is assuming that RBAC supports deny rules or that other admission controllers can override excessive permissions, when in fact RBAC is purely additive and the binding must be removed.

Full explanation →

501

Multi-Selectmedium

Which THREE of the following security context settings help mitigate container breakout attacks? (Select 3)

Select 3 answers

A.readOnlyRootFilesystem: true

B.privileged: true

C.allowPrivilegeEscalation: false

D.capabilities: add: ['NET_ADMIN']

E.runAsNonRoot: true

AnswersA, C, E

Setting `readOnlyRootFilesystem: true` mounts the container’s root filesystem as read-only, preventing any process inside the container from writing to or modifying system binaries, libraries, or configuration files. This directly mitigates container breakout attacks by blocking a common vector: overwriting a setuid binary or injecting a malicious shared object (e.g., via `LD_PRELOAD`) to escalate privileges or escape the container’s namespace isolation.

Why this answer

Option A (readOnlyRootFilesystem: true) is correct because mounting the container's root filesystem read-only prevents an attacker who gains code execution from writing malicious binaries, scripts, or modifying system files needed to escalate or persist during a breakout attempt. Option C (allowPrivilegeEscalation: false) is correct because it sets the kernel's no_new_privs flag on the container process, blocking setuid/setgid binaries and file capabilities from granting the process more privileges than its parent — a key vector for escaping to the host. Option E (runAsNonRoot: true) is correct because it forces the container to run as a non-root UID, so even if the process escapes the container boundary it lacks root privileges on the host, dramatically reducing the impact of a breakout.

Option B (privileged: true) is not correct because privileged containers get all Linux capabilities and direct device access, which is precisely what enables breakouts rather than mitigating them. Option D (capabilities: add: ['NET_ADMIN']) is not correct because adding NET_ADMIN expands the container's kernel attack surface (e.g., manipulating network interfaces, iptables), increasing breakout risk instead of reducing it.

Exam trap

A common misconception in the CKS exam is that `privileged: true` is a security hardening option, when in reality it is the most permissive setting and directly enables breakout attacks; candidates may also mistakenly think adding capabilities like `NET_ADMIN` is a mitigation, but it actually expands the attack surface.

Full explanation →

502

Multi-Selectmedium

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

Select 2 answers

A.RequestResponse

B.Verbose

C.Response

D.All

E.Metadata

AnswersA, E

RequestResponse is a valid audit level that captures the full request and response objects, including the body content, in addition to all metadata. It is one of the four levels defined by Kubernetes (None, Metadata, Request, RequestResponse) and is the most verbose level available. This level is useful for deep debugging but can produce a large volume of logs, so it should be used selectively.

Why this answer

In Kubernetes audit policy, the valid audit levels are None, Metadata, Request, and RequestResponse, so option A (RequestResponse) is correct because it logs the request metadata and body plus the response metadata and body, providing the most complete audit record. Option E (Metadata) is also correct because it logs only the request metadata (such as the user, timestamp, resource, and verb) without request or response bodies, which is one of the officially supported audit levels. The unmarked options do not belong: Verbose is not a Kubernetes audit level, Response is not a standalone audit level (response logging is part of RequestResponse), and All is not a valid audit policy level in Kubernetes.

Exam trap

The trap here is confusing audit policy levels with general logging verbosity terms like 'Verbose' or 'All', or assuming 'Response' is a standalone level when the actual level is RequestResponse.

Full explanation →

503

MCQmedium

To protect kernel defaults on a node, which flag should be set on the kubelet?

A.--hardening=true

B.--protect-kernel-defaults=true

C.--protect-kernel-parameters=true

D.--kernel-security=true

AnswerB

The `--protect-kernel-defaults=true` flag is the correct option, as it instructs the kubelet to verify that security-sensitive kernel parameters—such as `vm.overcommit_memory` and `kernel.panic`—are set to their expected default values and to avoid modifying them. When enabled, the kubelet is also unable to change these parameters, and it will refuse to start if the host kernel does not already match the required defaults, preventing accidental weakening of the kernel's security posture.

Why this answer

The `--protect-kernel-defaults=true` flag on the kubelet ensures that the kubelet will not start if any kernel tunables (e.g., `vm.overcommit_memory`, `kernel.panic`) differ from their default values. This is a security hardening measure to prevent misconfigured nodes from running with weakened kernel settings, as required by the CIS Kubernetes Benchmark.

Exam trap

The trap here is that candidates confuse the exact flag name with plausible-sounding alternatives like 'protect-kernel-parameters' or 'kernel-security', but the CKS exam expects precise recall of the actual kubelet flag `--protect-kernel-defaults=true` as defined in the CIS Benchmark.

How to eliminate wrong answers

Option A is wrong because `--hardening=true` is not a valid kubelet flag; there is no such flag in the kubelet configuration. Option C is wrong because `--protect-kernel-parameters=true` is not a real kubelet flag; the correct flag uses the term 'defaults' not 'parameters'. Option D is wrong because `--kernel-security=true` is not a valid kubelet flag; kernel security is enforced through other mechanisms like AppArmor or seccomp, not a dedicated kubelet flag.

Full explanation →

504

MCQeasy

An administrator runs 'kubectl get pods' and sees that a pod is in 'Pending' state. What is the most likely reason for this state?

A.The pod has been deleted

B.The container inside the pod is crashing

C.The pod is waiting to be scheduled to a node

D.The pod has completed its execution

AnswerC

Pending is a valid pod phase indicating that the pod has been accepted by the API server but has not yet been scheduled to a node. The scheduler may be waiting for resources, evaluating constraints such as taints/tolerations or node affinity, or the pod could be stuck due to a lack of suitable nodes. Until the scheduler binds the pod to a node, the phase remains Pending, making this the correct interpretation.

Why this answer

A pod enters the 'Pending' state when it has been accepted by the API server but is not yet running. The most common reason is that the scheduler has not yet assigned the pod to a node, often due to insufficient resources (CPU/memory), node selector mismatches, taints/tolerations, or a failed scheduler itself. This is the initial phase before the pod transitions to 'Running' or 'ContainerCreating'.

Exam trap

CNCF often tests the distinction between 'Pending' (scheduling issue) and 'ContainerCreating' (image pull or container start delay), so the trap here is confusing a pending scheduling state with a container runtime issue.

How to eliminate wrong answers

Option A is wrong because a deleted pod would not appear in 'kubectl get pods' output at all, or would show as 'Terminating' briefly before removal. Option B is wrong because a crashing container inside the pod would result in a 'CrashLoopBackOff' or 'Error' state, not 'Pending'. Option D is wrong because a pod that has completed its execution (e.g., a Job) would show as 'Completed' or 'Succeeded', not 'Pending'.

Full explanation →

505

MCQeasy

A security best practice for Dockerfiles is to avoid hardcoded secrets. Which Dockerfile instruction is MOST likely to contain a hardcoded secret?

A.ENV

B.EXPOSE

C.RUN

D.FROM

AnswerA

ENV is the correct answer because it explicitly bakes environment variables into the image layer, and any secret placed there becomes visible in `docker history`, `docker inspect`, and persists for all containers started from that image. Hardcoded secrets in ENV are a classic anti-pattern because they are exposed to anyone who can pull the image, contrary to using BuildKit's `RUN --mount=type=secret` or secret-build hooks to keep credentials out of the final image.

Why this answer

The ENV instruction in a Dockerfile is used to set environment variables, which are often used to store sensitive data like API keys, passwords, or tokens. Hardcoding secrets in ENV is a security risk because the values persist in the image layers and can be extracted by anyone with access to the image, violating the principle of least privilege and secret management best practices.

Exam trap

A common pitfall is assuming that RUN is the most likely instruction to contain secrets because it executes commands, but the trap is that ENV is the instruction where secrets are most commonly and persistently hardcoded as environment variables, making it the primary security concern in Dockerfiles.

How to eliminate wrong answers

Option B (EXPOSE) is wrong because it only documents which ports the container listens on at runtime; it does not contain or store any secret values. Option C (RUN) is wrong because while it executes commands during build, any secrets passed via shell commands (e.g., using --build-arg) are not hardcoded in the Dockerfile itself; hardcoded secrets in RUN would be visible in the command string but are less common than ENV for persistent secret storage. Option D (FROM) is wrong because it specifies the base image and never contains secrets; it only defines the starting point for the build.

Full explanation →

506

MCQhard

You need to create a ClusterRole that allows listing secrets, but only in namespaces that have a specific label 'security-level=high'. Which approach should you use?

A.Create a ClusterRole and bind it with RoleBindings in each labeled namespace

B.Create a Role in each namespace, then aggregate them into a ClusterRole

C.Create a ClusterRole and bind it with a ClusterRoleBinding; add a namespace condition in the role

D.Create a ClusterRole with a namespaceSelector: matchLabels: security-level: high

AnswerA

A ClusterRole defines a set of permissions that are not tied to any namespace, but when you reference it in a RoleBinding, the binding's namespace becomes the effective scope. This lets you reuse one ClusterRole across selected namespaces by creating a RoleBinding in each namespace that has the target label. The permissions apply only in those namespaces, not cluster-wide, which satisfies the requirement to list secrets only in labeled namespaces.

Why this answer

ClusterRoleBindings grant permissions cluster-wide, but RoleBindings can bind a ClusterRole to subjects within specific namespaces. By creating a ClusterRole with the necessary rules (e.g., 'list secrets') and then creating RoleBindings only in namespaces that have the label 'security-level=high', you effectively restrict the permission to those namespaces. This approach leverages the fact that a ClusterRole can be used with RoleBindings to scope permissions to individual namespaces.

Exam trap

The trap here is that candidates often confuse ClusterRoleBindings with RoleBindings, assuming a ClusterRole must always be bound with a ClusterRoleBinding, or they mistakenly think that a ClusterRole can include a namespace selector to limit its scope, which is not supported in Kubernetes RBAC.

How to eliminate wrong answers

Option B is wrong because aggregating Roles into a ClusterRole does not solve the namespace-scoping requirement; the aggregated ClusterRole would still apply cluster-wide if bound with a ClusterRoleBinding, and if bound with RoleBindings, you would still need to create RoleBindings per namespace, making the aggregation unnecessary. Option C is wrong because a ClusterRoleBinding grants permissions across all namespaces, and Kubernetes RBAC does not support adding a namespace condition inside a ClusterRole; namespace restrictions are enforced only via RoleBindings or by using a Role. Option D is wrong because ClusterRoles do not support a 'namespaceSelector' field; that field is only available in NetworkPolicy and certain admission webhooks, not in RBAC resources.

Full explanation →

507

MCQmedium

A security audit reveals that a container image running in production contains a critical vulnerability (CVE-2024-1234). The image was built from a base image that had the vulnerability. What is the MOST effective long-term solution to prevent such issues?

A.Use a runtime security tool like Falco to detect exploitation attempts.

B.Patch the vulnerability by installing a security update inside the running container.

C.Add an admission controller that rejects images with vulnerabilities.

D.Rebuild the image using a patched base image and integrate vulnerability scanning into the CI pipeline.

E.Switch to a different container runtime that is immune to the vulnerability.

AnswerD

Rebuilding the image from a patched base image directly eliminates the vulnerable package from the image filesystem, ensuring that the vulnerability is no longer present in the artifact itself. Integrating vulnerability scanning into the CI pipeline shifts security left, allowing teams to detect and block vulnerable images before they are pushed to a registry or deployed. This approach is sustainable and reproducible, as every build is validated and known vulnerabilities trigger a pipeline failure, forcing developers to update dependencies promptly. It addresses the source of the issue rather than applying after-the-fact controls.

Why this answer

The most effective long-term solution because it addresses the root cause by rebuilding the image from a patched base image, eliminating the vulnerability at the source. Integrating vulnerability scanning into the CI pipeline ensures that future images are automatically checked for known CVEs before deployment, preventing vulnerable images from reaching production. This aligns with the principle of shifting security left in the software supply chain.

Exam trap

CNCF often tests the distinction between reactive runtime detection (Falco) and proactive supply chain fixes (rebuilding with patched base images), leading candidates to choose a runtime tool instead of addressing the root cause in the CI/CD pipeline.

How to eliminate wrong answers

Option A is wrong because Falco is a runtime security tool that detects exploitation attempts but does not prevent the vulnerable image from being deployed or fix the underlying vulnerability; it only provides detection and alerting. Option B is wrong because patching a running container is a temporary, non-repeatable fix that violates immutable infrastructure principles; the patch will be lost on container restart and does not address the base image issue. Option C is wrong because an admission controller that rejects images with vulnerabilities is a preventive control, but it does not fix the existing vulnerable images already in production and relies on a policy that may block legitimate updates; it also does not address the root cause in the CI pipeline.

Option E is wrong because switching to a different container runtime does not fix the vulnerability in the image; the runtime is not responsible for image content, and the CVE would still be present regardless of the runtime used.

Full explanation →

508

MCQeasy

A cluster is using kubeadm and the control plane components are running as static pods. Where are the static pod manifests for the API server located by default?

A./var/lib/kubelet/

B./etc/kubernetes/manifests/

C./etc/kubernetes/admin.conf

D./etc/kubernetes/

AnswerB

/etc/kubernetes/manifests/ is the default static pod manifest directory in a kubeadm cluster. The kubelet watches this directory for YAML/JSON files and automatically creates and manages the pods they define, which is how the control plane components (kube-apiserver, kube-controller-manager, kube-scheduler, and etcd) are launched. This directory is the correct place for these manifests because the kubelet's staticPodPath is set to this location during kubeadm initialization, making it the source of truth for the control plane pods.

Why this answer

In a kubeadm-deployed cluster, the control plane components (API server, controller manager, scheduler) run as static pods. The kubelet watches a specific directory for pod manifests to create these static pods. By default, kubeadm places the manifests for the API server (and other control plane components) in /etc/kubernetes/manifests/.

This directory is specified via the --pod-manifest-path or staticPodPath in the kubelet configuration.

Exam trap

The trap here is that candidates confuse the static pod manifest directory (/etc/kubernetes/manifests/) with the kubelet's working directory (/var/lib/kubelet/) or the general cluster configuration directory (/etc/kubernetes/), leading them to pick a plausible but incorrect path.

How to eliminate wrong answers

Option A is wrong because /var/lib/kubelet/ is the default directory for kubelet's internal data (e.g., pod volumes, plugins, and the device plugin directory), not for static pod manifests. Option C is wrong because /etc/kubernetes/admin.conf is the kubeconfig file used by kubectl and administrators to authenticate to the cluster, not a directory for manifests. Option D is wrong because /etc/kubernetes/ is the parent directory containing cluster configuration files (like admin.conf, kubelet.conf, and the manifests subdirectory), but the static pod manifests themselves reside specifically in the /etc/kubernetes/manifests/ subdirectory, not directly in /etc/kubernetes/.

Full explanation →

509

MCQmedium

You run 'crictl ps' and see a container with state CONTAINER_RUNNING. What does this indicate?

A.The container has exited

B.The container is paused

C.The container is starting up

D.The container is running normally

AnswerD

CONTAINER_RUNNING is the state crictl reports for a container whose process is active and healthy, matching the stem's observation directly. Unlike CONTAINER_EXITED or CONTAINER_CREATED, it confirms the container runtime has started the workload and it has not terminated, so the container is operating normally.

Why this answer

In crictl, the state CONTAINER_RUNNING indicates that the container's processes are actively executing and the container is in a normal operational state. This corresponds to the container runtime (e.g., containerd) reporting the container as fully started and not in any transitional or halted state.

Exam trap

The trap here is that candidates may confuse CONTAINER_RUNNING with a container that is 'healthy' or 'ready', but crictl only reflects the runtime state, not application health or readiness checks.

How to eliminate wrong answers

Option A is wrong because CONTAINER_RUNNING explicitly means the container has not exited; an exited container would show state CONTAINER_EXITED. Option B is wrong because a paused container would show state CONTAINER_PAUSED, not CONTAINER_RUNNING. Option C is wrong because a container that is starting up would show state CONTAINER_CREATED or CONTAINER_WAITING, not CONTAINER_RUNNING.

Full explanation →

510

MCQeasy

Which annotation is used to apply an AppArmor profile named 'custom-profile' to a container named 'app' in a pod?

A.apparmor.security.beta.kubernetes.io/container.app: localhost/custom-profile

B.security.beta.kubernetes.io/apparmor: localhost/custom-profile

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

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

AnswerD

This is the correct annotation format for applying an AppArmor profile to a specific container. The key is constructed by appending the container name 'app' to the prefix 'container.apparmor.security.beta.kubernetes.io/', and the value 'localhost/custom-profile' refers to a locally loaded AppArmor profile named 'custom-profile'. The kubelet will enforce this profile on the container's process at runtime, providing the desired Mandatory Access Control restrictions.

Why this answer

The annotation for applying an AppArmor profile to a specific container in a pod follows the format `container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_name>`. This annotation targets the container named 'app' with the profile 'custom-profile', which is loaded locally on the node.

Exam trap

The trap here is that candidates confuse the annotation prefix order (e.g., `apparmor.security.beta.kubernetes.io` vs. `container.apparmor.security.beta.kubernetes.io`) or mistakenly use a pod-level annotation instead of the correct container-level annotation.

How to eliminate wrong answers

Option A is wrong because the prefix `apparmor.security.beta.kubernetes.io/container.app` is incorrect; the correct prefix is `container.apparmor.security.beta.kubernetes.io`. Option B is wrong because `security.beta.kubernetes.io/apparmor` is a generic annotation that does not specify a container name, and it is not the correct format for per-container AppArmor profiles. Option C is wrong because `pod.apparmor.security.beta.kubernetes.io/app` uses a `pod.` prefix, which is not a valid annotation; AppArmor annotations are per-container, not per-pod.

Full explanation →

511

Multi-Selectmedium

Which TWO of the following are best practices for Dockerfile security according to CKS guidelines?

Select 2 answers

A.RUN useradd -m myuser && USER root

B.COPY --from=builder /app /app

C.RUN adduser -D myuser && USER myuser

D.FROM scratch

E.FROM alpine:latest

AnswersC, D

This is correct because it creates a non-root user (myuser) without a password (using the -D flag for Alpine Linux) and then switches the active user to that account. All subsequent RUN, CMD, and ENTRYPOINT instructions execute as myuser, limiting the container to the least privileges needed for the application. This follows the security best practice of avoiding root inside containers, reducing the risk of privilege escalation if the application is compromised.

Why this answer

It creates a dedicated non-root user (`adduser -D myuser`) and then switches to that user with `USER myuser`, ensuring the container runs without root privileges. This aligns with the CKS best practice of least privilege, reducing the risk of privilege escalation if the container is compromised. The `-D` flag in Alpine's `adduser` creates a user without a password, which is appropriate for containerized environments.

Exam trap

CKS often tests the misconception that simply creating a user (without switching to it) or using multi-stage builds is sufficient for security, when the key is actually ensuring the container process runs as a non-root user.

Full explanation →

512

MCQmedium

An administrator wants to disable anonymous authentication to the Kubernetes API server. Which flag should be added to the kube-apiserver configuration?

A.--disable-anonymous

B.--authorization-mode=RBAC

C.--anonymous-auth=false

D.--enable-admission-plugins=DenyAnonymous

AnswerC

Setting --anonymous-auth=false on the kube-apiserver rejects requests lacking credentials, closing the unauthenticated access path. Anonymous requests are otherwise mapped to system:anonymous and bound to system:unauthenticated, so disabling the flag forces every client to present valid authentication before authorisation is evaluated.

Why this answer

The `--anonymous-auth=false` flag explicitly disables anonymous authentication to the Kubernetes API server. When set to false, requests without valid authentication credentials are rejected with a 401 Unauthorized error, preventing unauthenticated access. This is the standard Kubernetes mechanism to disable anonymous authentication as documented in the kube-apiserver reference.

Exam trap

The trap here is that candidates confuse authentication flags with authorization modes or admission plugins, and may invent non-existent flags like `--disable-anonymous` or assume `DenyAnonymous` is a valid admission plugin name.

How to eliminate wrong answers

Option A is wrong because `--disable-anonymous` is not a valid kube-apiserver flag; Kubernetes uses `--anonymous-auth` (boolean) to control anonymous access. Option B is wrong because `--authorization-mode=RBAC` controls authorization (what authenticated users can do), not authentication (who can access); anonymous users can still be authorized via RBAC if anonymous authentication is enabled. Option D is wrong because `DenyAnonymous` is not a valid admission plugin name; the correct admission plugin for denying anonymous requests is `DenyServiceExternalIPs` or similar, and anonymous authentication is controlled at the authentication layer, not via admission plugins.

Full explanation →

513

MCQmedium

An administrator wants to enable audit logging for the Kubernetes API server. Which of the following is required?

A.Enable the AuditLogging feature gate

B.Set --audit-log-path and --audit-policy-file flags on the kube-apiserver

C.Create a ClusterRoleBinding with audit permissions

D.Set --audit-log-path flag on the kubelet

AnswerB

Configuring the kube-apiserver with --audit-log-path and --audit-policy-file is the official, required method for enabling audit logging. The --audit-policy-file points to a YAML policy that defines which requests are audited and at what level, while --audit-log-path defines the file where the JSON audit records are written. Without these flags, the audit backend is not initialized even if the API server supports audit logging, so no audit events are ever emitted. Additional options like --audit-log-maxsize and --audit-log-maxbackup can be set for rotation.

Why this answer

Audit logging in Kubernetes is configured directly on the kube-apiserver component. The `--audit-log-path` flag specifies the file path where audit logs are written, and the `--audit-policy-file` flag points to a YAML file that defines which events (e.g., requests, responses, metadata) should be logged and at what level (e.g., Metadata, Request, RequestResponse). These flags are required to enable and control audit logging; no feature gate is needed because audit logging is built-in since Kubernetes 1.8.

Exam trap

The trap here is that candidates may think audit logging requires a feature gate (Option A) or confuse the kube-apiserver's audit flags with kubelet flags (Option D), or mistakenly believe RBAC permissions are needed to enable audit logging (Option C).

How to eliminate wrong answers

Option A is wrong because the AuditLogging feature gate was removed as a beta feature in Kubernetes 1.8 and is now always enabled; no feature gate is required to activate audit logging. Option C is wrong because a ClusterRoleBinding grants RBAC permissions to users or service accounts, but it does not enable or configure audit logging on the API server; audit logging is a server-side configuration, not a permission. Option D is wrong because the kubelet does not serve the Kubernetes API and does not handle audit logging; the `--audit-log-path` flag is only valid for the kube-apiserver, not the kubelet.

Full explanation →

514

Multi-Selecthard

Which THREE of the following are required components to enable audit logging in Kubernetes? (Select three.)

Select 3 answers

A.The --audit-policy-file flag on kube-apiserver

B.The --audit-log-path flag on kube-apiserver

C.An audit policy YAML file

D.The --audit-dynamic-configuration flag

E.An audit webhook backend

AnswersA, B, C

The --audit-policy-file flag tells kube-apiserver where to find the audit policy defining which events to record and at what level. Without it, the API server has no ruleset, so no audit events are generated regardless of any log destination configured.

Why this answer

Option A is correct because the kube-apiserver must be started with the --audit-policy-file flag pointing to the audit policy file; without this flag the API server has no policy to apply and audit logging cannot be enabled. Option B is correct because --audit-log-path tells the kube-apiserver where to write the audit log; specifying this flag is what actually enables the log backend and causes events to be recorded to a file. Option C is correct because an audit policy YAML file defines the rules (levels such as None, Metadata, Request, RequestResponse) that determine which requests are logged and at what detail, and it is the file referenced by --audit-policy-file.

Option D is not required because --audit-dynamic-configuration is an optional feature that allows the audit policy to be changed at runtime without restarting the API server, not a prerequisite for basic audit logging. Option E is not required because an audit webhook backend is only one alternative sink for audit events; file-based logging via --audit-log-path satisfies the requirement without any webhook configuration.

Exam trap

The trap here is that candidates often think a webhook backend or dynamic configuration is required for audit logging, but the CKS exam expects you to know that only the policy file, the policy flag, and the log path flag are the mandatory components for enabling basic audit logging.

Full explanation →

515

MCQeasy

You are tasked with creating a ConstraintTemplate in OPA/Gatekeeper that denies pods running with the 'latest' image tag. Which Rego rule should the ConstraintTemplate include?

A.admit[{"msg": msg}] { ... }

B.violation[{"msg": msg}] { ... }

C.reject[{"msg": msg}] { ... }

D.deny[{"msg": msg}] { ... }

AnswerB

The `violation[{"msg": msg}]` rule is the standard, required Rego rule for denial logic in a Gatekeeper ConstraintTemplate. When the rule body evaluates to true, Gatekeeper adds the message to the violation set and the Kubernetes API server rejects the request. The violation object may also contain a `details` map for additional structured info, but the `msg` field is what gets surfaced to the user in the admission response. Because Gatekeeper's admission hook is built around this rule name, this is the correct option.

Why this answer

In OPA/Gatekeeper ConstraintTemplates, the Rego rule must be named `violation` to define the logic that triggers a denial when a resource violates the constraint. The `violation` rule returns a message in the `msg` field, which Gatekeeper uses to reject the resource. Option B is correct because it follows the required syntax for Gatekeeper constraints, where `violation[{"msg": msg}]` is the standard entry point for enforcing policies.

Exam trap

The CKS exam often tests the distinction between OPA's generic `deny` rule and Gatekeeper's specific `violation` rule, tricking candidates who confuse general OPA syntax with the required Gatekeeper constraint format.

How to eliminate wrong answers

Option A is wrong because `admit` is not a valid rule name in Gatekeeper ConstraintTemplates; it is used in OPA policies for other purposes but not for constraint enforcement. Option C is wrong because `reject` is not a recognized rule name in Gatekeeper; the framework specifically expects `violation` to trigger denial. Option D is wrong because `deny` is a generic OPA keyword used in other contexts (e.g., Kubernetes admission webhooks) but not in Gatekeeper ConstraintTemplates, which require the `violation` rule to return a message.

Full explanation →

516

Multi-Selecthard

Which THREE of the following are valid capabilities that should be dropped for a container running a typical non-privileged application to adhere to the principle of least privilege?

Select 3 answers

A.CHOWN

B.SYS_ADMIN

C.NET_RAW

D.SETUID

E.NET_ADMIN

AnswersB, C, E

SYS_ADMIN is the most dangerous capability a container can possess because it is effectively a near-root superpower that bypasses namespace isolation. It permits a process to perform privileged system calls such as mount(), pivot_root(), setns(), and unshare(), which can directly modify the host kernel and filesystem if exploited. For example, an attacker with SYS_ADMIN could mount the host's filesystem into the container or move a process into the host's PID namespace. Since virtually no containerized application legitimately needs these operations, SYS_ADMIN should always be dropped from a pod's security context (and from the default Docker seccomp profile, where it is disabled by default).

Why this answer

The SYS_ADMIN capability is a highly privileged capability that grants access to a wide range of system administration operations, such as mounting filesystems, namespace manipulation, and kernel settings. For a typical non-privileged application, dropping SYS_ADMIN is essential to adhere to the principle of least privilege, as it prevents the container from performing host-level administrative actions that could compromise isolation.

Exam trap

A common misconception is that CHOWN or SETUID are high-risk capabilities that must be dropped, when in fact they are commonly needed for legitimate application behavior. The capabilities typically dropped for non-privileged containers are SYS_ADMIN, NET_RAW, and NET_ADMIN.

Full explanation →

517

MCQmedium

Which of the following is the correct way to apply an AppArmor profile named 'my-profile' to a pod using the annotation?

A.annotations: { apparmor.security.beta.kubernetes.io/app: 'localhost/my-profile' }

B.annotations: { container.apparmor.security.beta.kubernetes.io/app: 'my-profile' }

C.annotations: { container.apparmor.security.beta.kubernetes.io/app: 'localhost/my-profile' }

D.annotations: { container.seccomp.security.beta.kubernetes.io/app: 'localhost/my-profile' }

AnswerC

This is the correct AppArmor annotation. The key `container.apparmor.security.beta.kubernetes.io/app` targets the container named `app` with the `container.` prefix, and the value `localhost/my-profile` correctly references a node‑local AppArmor profile under `/etc/apparmor.d`. Kubelet loads and applies this profile before launching the container, enforcing the configured restrictions.

Why this answer

The AppArmor profile annotation must follow the format `container.apparmor.security.beta.kubernetes.io/<container_name>`, and the profile value must be prefixed with `localhost/` to indicate a locally loaded profile. This annotation applies the 'my-profile' AppArmor profile to the container named 'app' in the pod.

Exam trap

CNCF often tests the distinction between the `container.` prefix for per-container annotations versus the deprecated pod-level annotation, and the mandatory `localhost/` prefix for locally loaded profiles, causing candidates to omit one or both.

How to eliminate wrong answers

Option A is wrong because it uses the deprecated `apparmor.security.beta.kubernetes.io/app` annotation format (without the `container.` prefix), which is not the correct way to apply a profile to a specific container. Option B is wrong because it omits the required `localhost/` prefix in the profile value, which would cause the profile to be treated as an unqualified name and likely fail to load. Option D is wrong because it uses the `seccomp` annotation (`container.seccomp.security.beta.kubernetes.io/`) instead of the AppArmor annotation, which is a completely different security mechanism.

Full explanation →

518

MCQhard

A microservice container needs to perform DNS lookups using TCP rather than UDP. Which Kubernetes security context setting should be configured to allow this?

A.Add `DAC_OVERRIDE` capability

B.Add `NET_RAW` capability

C.Add `NET_ADMIN` capability

D.Add `NET_BIND_SERVICE` capability

AnswerB

NET_RAW allows raw sockets; TCP DNS uses standard sockets, so this is unnecessary.

Why this answer

TCP DNS lookups use standard TCP sockets, not raw sockets. These are permitted by the default syscall policy, and no additional Linux capability is required. All listed capabilities are unnecessary, as the container already has the ability to create TCP sockets.

Exam trap

The trap is assuming that DNS over TCP requires a special capability. In reality, TCP socket creation is allowed by default, so no capability is needed. Candidates may incorrectly choose NET_RAW, thinking raw sockets are involved, or NET_ADMIN for network control.

How to eliminate wrong answers

Option A is wrong because `DAC_OVERRIDE` capability bypasses file permission checks and has no relevance to network protocol selection for DNS lookups. Option C is wrong because `NET_ADMIN` capability grants broad network administration privileges (e.g., interface configuration, firewall rules) which is excessive and not specifically required for enabling TCP-based DNS queries. Option D is wrong because `NET_BIND_SERVICE` capability allows binding to privileged ports (below 1024) and does not control the ability to use TCP for DNS lookups.

Full explanation →

519

MCQmedium

You have a pod that is in CrashLoopBackOff. You want to inspect the logs from the previous instance of the container. Which flag should you use with kubectl logs?

A.--previous

B.--tail

C.--all-containers

D.--since

AnswerA

The --previous flag instructs kubectl to fetch log output from the previously terminated container instance rather than the current one. In a CrashLoopBackOff scenario, the current container has just restarted and may only show startup messages (if any), while the actual panic or error that caused the crash lives in the previous container's stdout/stderr. This flag is the correct way to retrieve that historical crash output and diagnose the root cause.

Why this answer

When a pod is in CrashLoopBackOff, the current container instance has crashed and restarted, so its logs may be empty or not reflect the crash. The `--previous` flag (or `-p`) tells `kubectl logs` to show logs from the previous instance of the container, which contains the output from the crashed process. This is the correct way to retrieve crash-related logs without waiting for the new instance to produce output.

Exam trap

The exam often tests the misconception that `--tail` or `--since` can retrieve logs from a crashed container, but these flags only filter the current container's logs, not the previous instance's logs.

How to eliminate wrong answers

Option B is wrong because `--tail` specifies the number of recent log lines to display (e.g., `--tail=50`), but it still reads from the current container instance, not the previous one, so it cannot show logs from the crashed instance. Option C is wrong because `--all-containers` is used to stream logs from all containers in a pod (useful for multi-container pods), but it does not access logs from a previous container instance. Option D is wrong because `--since` filters logs by a time duration (e.g., `--since=5m`), but it operates on the current container instance's logs, not the previous one, so it cannot retrieve logs from a terminated container.

Full explanation →

520

MCQmedium

An administrator wants to secure etcd communication. Which of the following is required?

A.Set --etcd-servers to use HTTPS

B.Use SSH tunneling between etcd members

C.Enable TLS with client certificate authentication

D.Enable etcd RBAC

AnswerC

The correct approach is to configure etcd to require TLS and, crucially, mutual TLS by setting --client-cert-auth=true along with a --trusted-ca-file, which forces every client to present a certificate signed by a trusted CA. This authenticates clients cryptographically, prevents man-in-the-middle attacks, and encrypts all data in transit between etcd clients (primarily kube-apiserver) and the etcd server. It is the standard, native mechanism etcd provides for securing client communication.

Why this answer

Etcd, as a distributed key-value store, requires TLS encryption with mutual authentication (client certificates) to secure communication between the API server and etcd, as well as between etcd peers. The `--etcd-servers` flag in kube-apiserver must point to HTTPS endpoints, and `--etcd-certfile` and `--etcd-keyfile` enable client certificate authentication, ensuring that only authenticated clients can access etcd data.

Exam trap

The trap here is that candidates often assume HTTPS alone (Option A) is sufficient for securing etcd, overlooking the requirement for mutual TLS authentication with client certificates to prevent unauthorized clients from connecting to etcd.

How to eliminate wrong answers

Option A is wrong because simply setting `--etcd-servers` to use HTTPS without enabling TLS with client certificate authentication does not secure etcd communication; HTTPS alone only encrypts the channel but does not authenticate the client, leaving etcd vulnerable to unauthorized access. Option B is wrong because SSH tunneling between etcd members is not a standard or recommended practice for securing etcd in Kubernetes; etcd natively supports TLS encryption and mutual authentication, and SSH tunnels add unnecessary complexity and are not part of the Kubernetes security model. Option D is wrong because etcd RBAC controls authorization for etcd operations (e.g., read/write access to keys) but does not encrypt or authenticate the communication channel; TLS with client certificates is required to secure the transport layer.

Full explanation →

521

MCQmedium

You are configuring Kubernetes audit logging. You want to log all requests to the `secrets` resource in the `kube-system` namespace at the `RequestResponse` level, while logging all other requests at the `Metadata` level. Which audit policy configuration achieves this?

A.rules: [- level: RequestResponse, resources: [group: '', resources: [*]], - level: Metadata]

B.rules: [- level: RequestResponse, resources: [group: '', resources: [secrets]], namespaces: [kube-system], - level: Metadata]

C.rules: [- level: Metadata, resources: [group: '', resources: [secrets]], namespaces: [kube-system], - level: RequestResponse]

D.rules: [- level: Metadata, resources: [group: '', resources: [secrets]], namespaces: [kube-system], omitStages: [RequestReceived], - level: RequestResponse]

AnswerB

Audit policy rules are evaluated in order, first match wins. Placing the RequestResponse rule for secrets in kube-system first captures that resource at full detail, while the trailing Metadata rule acts as the catch-all for every other request, satisfying both logging requirements in one policy.

Why this answer

It defines an audit policy rule that matches requests to the `secrets` resource (core API group, empty string) in the `kube-system` namespace and sets the audit level to `RequestResponse`, which logs both the request metadata and the response body. The subsequent `- level: Metadata` rule acts as a catch-all for all other requests, logging only metadata. Audit policy rules are evaluated in order, and the first matching rule applies, so the specific rule for secrets must come before the general rule.

Exam trap

Kubernetes often tests the order of audit policy rules and the specific resource/namespace matching syntax, where candidates mistakenly think a wildcard resource rule can be overridden by a later rule, or confuse the `Metadata` and `RequestResponse` levels.

How to eliminate wrong answers

Option A is wrong because it uses `resources: [*]` which matches all resources, including secrets, and sets the level to `RequestResponse` for everything, then adds a `Metadata` rule that would never be reached due to the order. Option C is wrong because it reverses the levels: it logs secrets at `Metadata` level and all other requests at `RequestResponse` level, which is the opposite of what is required. Option D is wrong because it also logs secrets at `Metadata` level (not `RequestResponse`) and includes `omitStages: [RequestReceived]`, which is unnecessary and does not change the incorrect level assignment.

Full explanation →

522

MCQmedium

An administrator creates a custom seccomp profile and places it at /var/lib/kubelet/seccomp/myprofile.json. Which securityContext field is used to apply this profile to a container?

A.seccompProfile: type: Localhost localhostProfile: "/var/lib/kubelet/seccomp/myprofile.json"

B.seccompProfile: type: Localhost localhostProfile: "myprofile.json"

C.seccompProfile: type: RuntimeDefault localhostProfile: "myprofile.json"

D.seccompProfile: type: Unconfined localhostProfile: "myprofile.json"

AnswerB

This is correct because the localhostProfile value is resolved relative to the kubelet's seccomp profile root (default /var/lib/kubelet/seccomp). So 'myprofile.json' becomes /var/lib/kubelet/seccomp/myprofile.json, which is exactly where the administrator placed the custom profile. The type field is also correctly set to Localhost, indicating that this custom file should be used.

Why this answer

When using a custom seccomp profile stored on the node, the `type` must be `Localhost`, and the `localhostProfile` field must contain only the filename (e.g., `myprofile.json`), not the full path. Kubernetes automatically prepends `/var/lib/kubelet/seccomp/` to the filename, so specifying the full path would cause the profile to be looked up in the wrong location, resulting in a failure to apply the profile.

Exam trap

The trap here is that candidates mistakenly include the full file path in `localhostProfile`, not realizing the kubelet automatically prepends its seccomp directory, leading to a profile-not-found error.

How to eliminate wrong answers

Option A is wrong because it specifies the full path `/var/lib/kubelet/seccomp/myprofile.json` in `localhostProfile`, but Kubernetes expects only the filename (e.g., `myprofile.json`) when `type: Localhost` is used; the full path is automatically constructed from the kubelet's seccomp root directory. Option C is wrong because `type: RuntimeDefault` uses the container runtime's default seccomp profile and does not accept a `localhostProfile` field; specifying one would be ignored or cause a validation error. Option D is wrong because `type: Unconfined` disables seccomp entirely and does not use a `localhostProfile`; providing one is contradictory and invalid.

Full explanation →

523

MCQhard

You are responsible for a production Kubernetes cluster running critical workloads. The cluster uses containerd as the container runtime. The security team has deployed Falco with default rules and it is running as a DaemonSet. Recently, the team noticed that several pods have been unexpectedly terminated by the OOMKiller. You suspect a container is performing a fork bomb attack, exhausting memory. You need to detect and prevent such attacks in real-time. Falco is already installed. Which single action should you take to best address this threat?

A.Enable the Falco rule that detects rapid process creation (fork bomb) and configure an alert.

B.Adjust the OOM score of critical pods to prevent them from being killed.

C.Apply a seccomp profile that blocks the fork and clone syscalls.

D.Set resource quotas on all namespaces to limit memory usage.

AnswerA

Falco's default rules include 'Detect Fork Bomb' (rule: Fork Bomb) which uses a macro to trigger when a process creates an excessive number of child processes within a short time window, typically by monitoring fork, vfork, and clone syscalls. Enabling this rule and configuring an alert (e.g., to stdout, syslog, or a notification channel) provides real-time visibility into the rapid process-creation pattern characteristic of a fork bomb, allowing security teams to respond before system resources are exhausted.

Why this answer

Falco's default rules include a rule for 'Fork Bomb' that detects rapid process creation by monitoring the `clone` and `fork` syscalls. Enabling this rule and configuring an alert allows real-time detection of fork bomb attacks, which is the most direct and effective action to address the threat. This leverages Falco's existing capability to identify anomalous syscall patterns without requiring additional tooling or configuration changes.

Exam trap

The trap here is that candidates may choose option C (blocking fork/clone syscalls) thinking it prevents the attack, but they overlook that this would break essential container functionality, whereas Falco's existing rule provides detection without breaking applications.

How to eliminate wrong answers

Option B is wrong because adjusting the OOM score of critical pods only influences which pod gets killed first when memory pressure occurs, but it does not detect or prevent the fork bomb attack itself; the attack would still exhaust memory and potentially kill other pods. Option C is wrong because applying a seccomp profile that blocks `fork` and `clone` syscalls would break legitimate container operations that rely on process creation (e.g., starting new processes, running scripts), making it an impractical and overly restrictive solution. Option D is wrong because setting resource quotas on namespaces limits total memory usage but does not detect or prevent a fork bomb in real-time; the attack could still cause OOM kills within the quota or affect other pods in the same namespace before the quota is enforced.

Full explanation →

524

MCQhard

You have built a custom seccomp profile at /var/lib/kubelet/seccomp/audit.json. Which YAML snippet correctly applies this profile to a container?

A.securityContext: seccompProfile: type: RuntimeDefault

B.securityContext: seccompProfile: type: Localhost localhostProfile: "profiles/audit.json"

C.securityContext: seccomp: type: Localhost profile: "audit.json"

D.securityContext: seccompProfile: type: Localhost localhostProfile: "audit.json"

AnswerD

This correctly uses the `seccompProfile` field with `type: Localhost` and `localhostProfile: "audit.json"`. The `localhostProfile` path is interpreted relative to the kubelet's seccomp root directory, `/var/lib/kubelet/seccomp`, so it resolves exactly to `/var/lib/kubelet/seccomp/audit.json`, matching the location where you placed the profile. This option is the only one that uses the modern API and the correct path.

Why this answer

The seccomp profile is stored at `/var/lib/kubelet/seccomp/audit.json`. The `localhostProfile` field expects a relative path from the base directory `/var/lib/kubelet/seccomp/`. Therefore, `audit.json` correctly resolves to the full path.

The `seccompProfile` API with `type: Localhost` is the current method for applying custom profiles.

Exam trap

The trap here is that candidates confuse the deprecated `seccomp` field (used in older Kubernetes versions) with the current `seccompProfile` API, or they assume a bare filename like `audit.json` works without the required relative path prefix.

How to eliminate wrong answers

Option A is wrong because `type: RuntimeDefault` applies the container runtime's default seccomp profile, not a custom profile at the specified path. Option C is wrong because it uses the deprecated `seccomp` field and `profile` key instead of the current `seccompProfile` API with `localhostProfile`. Option D is wrong because `localhostProfile: "audit.json"` is a bare filename, not a relative path; Kubernetes requires a relative path (e.g., `profiles/audit.json`) to locate the profile under `/var/lib/kubelet/seccomp/`.

Full explanation →

525

MCQmedium

You need to encrypt secrets at rest in a Kubernetes cluster. What must be configured?

A.Create an EncryptionConfiguration object in the cluster and pass it to kube-apiserver via --encryption-provider-config

B.Set the environment variable ENCRYPT_SECRETS=true on the kube-controller-manager

C.Use a MutatingWebhookConfiguration to encrypt secrets before storage

D.Enable the 'SecretEncryption' feature gate on all control plane components

AnswerA

The Kubernetes API server encrypts resources at the storage layer by reading an EncryptionConfiguration file supplied via the --encryption-provider-config flag. This configuration defines providers — such as aescbc, kms, or secretbox — and which resource types (like secrets) are encrypted before being written to etcd. The API server must be restarted with this flag, and the configuration file must be mounted into the API server pod or accessible on the host.

Why this answer

Kubernetes encrypts secrets at rest by defining an EncryptionConfiguration object that specifies which encryption providers (e.g., AES-CBC, secretbox, or KMS) to use, and then passing the configuration file to the kube-apiserver via the `--encryption-provider-config` flag. This ensures that when the API server writes secrets to etcd, they are encrypted before storage, and decrypted on read, meeting the requirement for encrypting secrets at rest.

Exam trap

The trap here is that candidates may think encryption at rest can be achieved via a webhook or a feature gate, but in reality it requires a specific configuration file passed to the kube-apiserver, and no feature gate or environment variable exists for this purpose.

How to eliminate wrong answers

Option B is wrong because the kube-controller-manager does not handle secret storage or encryption; encryption at rest is solely the responsibility of the kube-apiserver, and there is no `ENCRYPT_SECRETS` environment variable recognized by any control plane component. Option C is wrong because a MutatingWebhookConfiguration can modify resources before they are stored, but it cannot encrypt the data at the storage layer; encryption at rest must be performed by the API server using a configured encryption provider, not by a webhook. Option D is wrong because there is no `SecretEncryption` feature gate in Kubernetes; encryption at rest is configured via the `--encryption-provider-config` flag and does not require enabling any feature gate.

Full explanation →

Certified Kubernetes Security Specialist CKS (CKS) — Questions 451–525