CCNA Cks Microservice Vuln Questions — Page 2 of 3

Multi-Selectmedium

Which TWO of the following are valid ways to securely manage secrets in Kubernetes? (Choose two.)

Select 2 answers

A.Mount Kubernetes Secrets as volumes into the pod.

B.Use environment variables from the pod spec referencing Secret keys.

C.Use an external secrets manager like HashiCorp Vault integrated with the pod.

D.Pass secrets as command-line arguments to the container.

E.Store secrets in ConfigMaps with base64 encoded data.

AnswersA, C

Mounting a Kubernetes Secret as a volume is the most secure built-in method because the kubelet creates an in-memory tmpfs filesystem and writes each secret key as a file, which is not stored on the node's disk. Unlike environment variables, volume-mounted secrets are not visible in /proc/<pid>/environ or container logs, and they support automatic rotation: when the Secret object is updated, the kubelet eventually rewrites the mounted files without requiring a pod restart. You can also set file permissions via defaultMode to restrict access to the specific user in the container, and the secret data never appears in the pod spec beyond the Secret reference.

Why this answer

Mounting Kubernetes Secrets as volumes into the pod ensures that secret data is stored in the pod's filesystem as files, which are created with in-memory tmpfs to avoid writing to disk. This approach leverages Kubernetes' native secret handling, where the secret data is base64-decoded and presented as plaintext files, and access can be controlled via RBAC and PodSecurityPolicies. It also supports automatic rotation when secrets are updated, provided the pod is restarted or the volume is remounted.

Exam trap

Kubernetes often tests the misconception that environment variables are a secure way to inject secrets, when in fact they are vulnerable to exposure through process introspection and logging, making volume mounts or external secret stores the recommended approaches.

Practice this question →

MCQhard

You need to ensure that all pods in a namespace have the label 'security: high' added automatically upon creation. Which admission controller should you use?

A.PodSecurityPolicy (deprecated)

B.ResourceQuota

C.ValidatingAdmissionPolicy

D.MutatingWebhookConfiguration

AnswerD

MutatingWebhookConfiguration is correct because it registers external webhooks that can modify a pod object during the mutating admission phase. A mutating webhook can inspect the pod being created and add a label to its metadata before the object is persisted. This is exactly the mechanism for automatically labeling every pod in a namespace, unlike validation-only admission components.

Why this answer

A MutatingWebhookConfiguration intercepts pod creation requests and can automatically add the label 'security: high' to pods in a namespace. This admission controller mutates the object before it is persisted, ensuring all pods receive the label without manual intervention.

Exam trap

In the CNCF CKS exam, candidates often confuse MutatingAdmissionPolicy with ValidatingAdmissionPolicy. Remember that only mutating admission controllers can modify objects; ValidatingAdmissionPolicy only checks and rejects.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy is deprecated and does not add labels; it enforces security contexts. Option B is wrong because ResourceQuota limits resource consumption, not labels. Option C is wrong because ValidatingAdmissionPolicy only validates requests and cannot mutate objects to add labels.

Practice this question →

MCQhard

You are configuring encryption at rest for Kubernetes secrets. After creating an EncryptionConfiguration with aescbc provider, which additional step is required to enable encryption?

A.Restart the kube-apiserver with --encryption-provider-config flag

B.Apply the EncryptionConfiguration as a ConfigMap

C.Restart the kube-scheduler

D.Recreate all secrets in the cluster

AnswerA

The kube-apiserver reads --encryption-provider-config only at process startup, so the configuration file must be in place and the control plane component restarted for the change to take effect. This flag points to a YAML/JSON file that defines how to encrypt secrets at the etcd level. Without the restart, the apiserver continues using its previous, unencrypted write path. This is the required first step before any existing data can be migrated to encrypted form.

Why this answer

The EncryptionConfiguration resource defines how Kubernetes should encrypt data at rest, but it is not automatically applied. The kube-apiserver must be restarted with the `--encryption-provider-config` flag pointing to the configuration file so that it reads and enforces the encryption settings for all subsequent writes to etcd. Without this flag, the apiserver ignores the EncryptionConfiguration entirely.

Exam trap

A common pitfall is thinking that creating the EncryptionConfiguration resource is sufficient. In reality, the kube-apiserver must be configured with the --encryption-provider-config flag and restarted to activate encryption.

How to eliminate wrong answers

Option B is wrong because an EncryptionConfiguration is a custom resource, not a ConfigMap; applying it as a ConfigMap would not be recognized by the kube-apiserver. Option C is wrong because the kube-scheduler does not handle secret storage or encryption; encryption at rest is managed solely by the kube-apiserver when writing to etcd. Option D is wrong because existing secrets are not automatically re-encrypted; the encryption provider only applies to new or updated secrets, and existing secrets remain unencrypted until they are rewritten.

Practice this question →

Multi-Selectmedium

Which THREE of the following are features of container sandboxing solutions like gVisor or Kata Containers?

Select 3 answers

A.They are compatible with the OCI runtime specification

B.They improve container performance over native runc

C.They can be used with RuntimeClass to select the sandbox runtime per pod

D.They provide an additional layer of isolation between containers and the host kernel

E.They use the host kernel directly for all system calls

AnswersA, C, D

Container sandboxes such as gVisor (runsc) and Kata Containers implement the OCI runtime specification, meaning they expose the same lifecycle commands (create, start, delete) and expect the same OCI image/bundle format. This allows containerd or CRI-O to treat them as drop-in replacements for runc, requiring no changes to the kubelet, container images, or orchestration workflows. OCI compatibility is therefore a core enabler for using these sandboxes in Kubernetes without breaking existing tooling.

Why this answer

Both gVisor and Kata Containers implement the OCI (Open Container Initiative) runtime specification, which allows them to be used as drop-in replacements for runc. This compatibility ensures that container images and tools like containerd can interface with these sandboxed runtimes without modification, as they expose the same runtime lifecycle commands (create, start, delete).

Exam trap

The CKS exam often tests the misconception that sandboxing improves performance, when in reality the added isolation layer (user-space kernel or VM) introduces latency and resource overhead compared to native runc.

Practice this question →

MCQhard

A pod runs with a service mesh sidecar (Istio). The team wants to enforce mutual TLS (mTLS) for all traffic between services in the 'production' namespace. Which resource should be applied?

A.DestinationRule with trafficPolicy: tls: mode: ISTIO_MUTUAL

B.VirtualService with TLS settings

C.PeerAuthentication with mode: STRICT in the namespace

D.ServiceEntry with mTLS enabled

AnswerC

PeerAuthentication is the Istio policy resource specifically designed to control mTLS adoption at mesh, namespace, or workload granularity. Setting mode: STRICT in the production namespace requires every service-to-service communication to be mutual TLS; any plaintext request will be rejected by the sidecar proxies, effectively enforcing the team's requirement. This is the standard and recommended way to enforce mTLS for an entire namespace.

Why this answer

PeerAuthentication with mode: STRICT enforces mutual TLS at the service mesh level by requiring all traffic within the namespace to use TLS certificates for both sides of the connection. This is the correct Istio resource to enforce mTLS for all services in the 'production' namespace, as it sets a namespace-wide policy that overrides any permissive defaults.

Exam trap

CNCF often tests the distinction between PeerAuthentication (which enforces mTLS on the server side) and DestinationRule (which configures client-side TLS), leading candidates to mistakenly choose DestinationRule for namespace-wide mTLS enforcement.

How to eliminate wrong answers

Option A is wrong because DestinationRule with trafficPolicy: tls: mode: ISTIO_MUTUAL configures client-side TLS settings for traffic to specific hosts, but does not enforce server-side mTLS acceptance; it only sets the client's TLS mode and can be bypassed if the server allows plaintext. Option B is wrong because VirtualService is used for traffic routing (e.g., canary deployments, A/B testing) and does not handle TLS authentication or mTLS enforcement; its TLS settings are for ingress gateway TLS termination, not peer authentication. Option D is wrong because ServiceEntry is used to register external services into the mesh and enable mTLS for those endpoints, but it does not enforce mTLS for internal services within the namespace.

Practice this question →

MCQmedium

You want to enable mutual TLS (mTLS) between services in a namespace using Istio. Which custom resource should you configure to enforce STRICT mTLS for all workloads in the namespace?

A.DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL

B.VirtualService with tls.mode: SIMPLE

C.PeerAuthentication with mtls.mode: STRICT

D.ServiceEntry with resolution: NONE

AnswerC

PeerAuthentication is the Istio policy object that controls inbound TLS enforcement on the server side, and mtls.mode: STRICT demands that all traffic arriving at the workload be wrapped in Istio mutual TLS. Any plaintext or non-Istio TLS connection is rejected with a 403 response, so this is the correct way to enable mTLS between services in a namespace. It works alongside DestinationRules, which configure the client side, but enforcement of the policy happens here.

Why this answer

PeerAuthentication is the Istio custom resource specifically designed to define traffic authentication policies between workloads. Setting `mtls.mode: STRICT` enforces that all traffic in the namespace must use mutual TLS (mTLS), rejecting any plain-text or non-mTLS connections. This is the standard way to enforce STRICT mTLS at the namespace level in Istio.

Exam trap

The trap here is confusing DestinationRule's `trafficPolicy.tls.mode: ISTIO_MUTUAL` with PeerAuthentication's `mtls.mode: STRICT`; candidates often mistakenly think DestinationRule enforces mTLS, but it only configures TLS for outbound traffic, not inbound authentication enforcement.

How to eliminate wrong answers

Option A is wrong because DestinationRule controls traffic routing and load balancing policies, not authentication; its `trafficPolicy.tls.mode: ISTIO_MUTUAL` only configures TLS settings for outbound connections to a specific host, not enforcing mTLS on inbound traffic. Option B is wrong because VirtualService is used for traffic routing and manipulation, not authentication; `tls.mode: SIMPLE` is not a valid field in VirtualService and does not relate to mTLS enforcement. Option D is wrong because ServiceEntry is used to register external services into the mesh, not to enforce authentication policies; `resolution: NONE` controls DNS resolution, not TLS mode.

Practice this question →

MCQhard

During a security audit, a team discovers that their microservice application, deployed on Kubernetes, is vulnerable to container breakout attacks. The containers run as root and have many Linux capabilities. Which set of Pod Security Standards (PSS) enforcement modes and policies would best mitigate this risk?

A.Use 'privileged' PSS with Warn mode

B.Use 'baseline' PSS with Audit mode

C.Use 'restricted' PSS with Enforce mode

D.Use 'baseline' PSS with Enforce mode

AnswerC

Restricted profile in Enforce mode is the only combination among the choices that both selects the strongest pod-hardening policy and actually enforces it at admission time. Restricted requires runAsNonRoot=true, sets seccompProfile to RuntimeDefault, drops all capabilities except NET_BIND_SERVICE, and mandates a read-only root filesystem, which together deprive an attacker of the most common kernel exploits. Because Enforce mode rejects non-compliant pods before they are created, there is no opportunity for a restricted-violating pod to run and escape.

Why this answer

The 'restricted' Pod Security Standard with 'Enforce' mode is the correct choice because it mandates the most stringent security controls, including dropping all Linux capabilities and preventing containers from running as root. This directly mitigates container breakout attacks by eliminating the excessive privileges that enable such exploits. 'Enforce' mode actively blocks non-compliant pods, ensuring the policy is applied without relying on user awareness or audit logs.

Exam trap

CNCF often tests the misconception that 'baseline' PSS is sufficient for most security needs, but the trap here is that 'baseline' still allows root and default capabilities, which are exactly the vectors exploited in container breakout attacks, making 'restricted' the only adequate choice for this specific risk.

How to eliminate wrong answers

Option A is wrong because 'privileged' PSS is the least restrictive policy, allowing all capabilities and root access, which would not mitigate breakout risks; 'Warn' mode only alerts but does not block non-compliant pods. Option B is wrong because 'baseline' PSS allows some default capabilities and does not enforce dropping all capabilities or preventing root, and 'Audit' mode only logs violations without enforcement. Option D is wrong because while 'baseline' PSS with 'Enforce' mode blocks some obvious misconfigurations, it still permits containers to run as root and retains default capabilities, leaving significant breakout vectors unaddressed.

Practice this question →

MCQhard

An OPA/Gatekeeper ConstraintTemplate is defined with the following Rego rule: violation[{"msg": msg}] { container := input.review.object.spec.containers[_] container.securityContext.runAsNonRoot != true msg := "Container must run as non-root" } What happens when a pod is submitted with a container that has runAsNonRoot: true?

A.The pod is admitted but an audit log is generated

B.The pod is admitted

C.The pod is denied with a message

D.The pod is mutated to set runAsNonRoot

AnswerB

For a pod that explicitly sets securityContext.runAsNonRoot: true, the Gatekeeper constraint's violation condition (runAsNonRoot != true) evaluates to false. Since the Rego policy only triggers a denial when a violation is found, no violation exists and the admission request is allowed. Thus the pod is admitted without any message, mutation, or further side effects.

Why this answer

The Rego rule `container.securityContext.runAsNonRoot != true` only triggers a violation when the field is not set to `true`. When `runAsNonRoot: true` is explicitly set, the condition evaluates to `false`, so no violation is generated, and the pod is admitted without any denial or mutation. OPA/Gatekeeper by default enforces constraints by denying admission; it does not mutate resources or generate audit logs unless specifically configured for dry-run or audit mode.

Exam trap

The CKS exam often tests the subtle difference between `!= true` and `== false` in Rego — candidates mistakenly think `!= true` catches only `false` values, but it also catches `null` (missing field), and they forget that an explicit `true` passes the check, leading them to choose denial or mutation options.

How to eliminate wrong answers

Option A is wrong because OPA/Gatekeeper does not generate audit logs for admitted pods unless the constraint is explicitly configured in audit mode (e.g., with `spec.sync` and `spec.match`), and the Rego rule here is a validation rule that either denies or allows; it does not produce audit logs on success. Option C is wrong because the pod is not denied; the violation condition is false when `runAsNonRoot: true`, so no denial message is returned. Option D is wrong because OPA/Gatekeeper is a policy engine that validates and denies, not a mutating webhook; it cannot mutate fields like `runAsNonRoot` — mutation requires a separate MutatingAdmissionWebhook or a mutating Gatekeeper feature (e.g., via `modify` rules) which is not used here.

Practice this question →

MCQmedium

An administrator wants to use gVisor to sandbox containers in a Kubernetes cluster. Which resource must be created to enable this?

A.RuntimeClass with handler: runsc

B.DaemonSet to install gVisor on nodes

C.PodSecurityPolicy with gVisor enabled

D.SecurityContext with runtime: gvisor

AnswerA

RuntimeClass is the native Kubernetes primitive for selecting a container runtime. The `.handler` field must match the runtime name configured on the kubelet (e.g., `runsc` for gVisor), and pods opt in via `runtimeClassName`. This is the only Kubernetes-native way to direct a pod to run under gVisor's sandboxed `runsc` runtime.

Why this answer

To use gVisor as a container runtime sandbox in Kubernetes, you must create a RuntimeClass resource with the handler set to 'runsc'. This tells the kubelet which runtime handler to use when running pods that reference this RuntimeClass, enabling gVisor's user-space kernel (runsc) to intercept and sandbox system calls.

Exam trap

The CKS exam often tests the distinction between installing a runtime (DaemonSet) and enabling it via a Kubernetes API object (RuntimeClass), leading candidates to confuse node-level setup with cluster-level resource creation.

How to eliminate wrong answers

Option B is wrong because a DaemonSet can install gVisor binaries on nodes, but the actual enablement requires a RuntimeClass to select the runsc handler at pod creation time. Option C is wrong because PodSecurityPolicy (deprecated in 1.21) controls security contexts and admission, not runtime selection; gVisor is not a PSP feature. Option D is wrong because SecurityContext does not have a 'runtime' field; runtime selection is done via RuntimeClass, not via pod security context settings.

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid ways to enforce that containers cannot run as root in a Kubernetes cluster? (Select TWO.)

Select 2 answers

A.Create a Gatekeeper Constraint that requires runAsNonRoot

B.Use a NetworkPolicy to block root containers

C.Set the kubelet flag --run-non-root

D.Enable the PodSecurity admission controller with the 'restricted' profile

E.Use a ServiceAccount to restrict root

AnswersA, D

Gatekeeper is a validating admission controller that extends Kubernetes with policies written in OPA Rego. A ConstraintTemplate defines the validation logic (e.g., requiring `runAsNonRoot: true`), and a Constraint then applies that rule to objects such as Pods. Because it evaluates every resource at admission time, it can reject any Pod whose security context allows root—enforcing the policy before the Pod is persisted. This makes it a valid, flexible way to enforce non-root execution, going beyond the built-in PodSecurity profiles.

Why this answer

Gatekeeper, using the Open Policy Agent (OPA) framework, can enforce custom policies via ConstraintTemplates. A Constraint requiring `runAsNonRoot: true` in the Pod security context ensures containers cannot run as root, providing a flexible, admission-time control that works across all namespaces.

Exam trap

The exam often tests the distinction between network-layer controls (NetworkPolicy) and identity objects (ServiceAccount) versus admission controllers that enforce security contexts, leading candidates to overestimate the scope of NetworkPolicies or ServiceAccounts.

Practice this question →

MCQhard

You want to run a workload in a sandboxed container using gVisor. You have created a RuntimeClass named 'gvisor' that references the 'runsc' handler. Which of the following Pod specs correctly uses this RuntimeClass?

A.apiVersion: v1 kind: Pod metadata: name: sandbox-pod annotations: runtimeClass: gvisor spec: containers: - name: app image: nginx

B.apiVersion: v1 kind: Pod metadata: name: sandbox-pod spec: runtimeClassName: gvisor containers: - name: app image: nginx

C.apiVersion: v1 kind: Pod metadata: name: sandbox-pod spec: nodeSelector: runtime: gvisor containers: - name: app image: nginx

D.apiVersion: v1 kind: Pod metadata: name: sandbox-pod spec: runtimeClass: name: gvisor containers: - name: app image: nginx

AnswerB

Setting runtimeClassName: gvisor in the pod spec instructs the kubelet to select the gvisor RuntimeClass, which maps to the runsc handler and runs containers through gVisor's user-space kernel for sandboxing. This is the correct field; nodeName or annotations would not engage the sandbox runtime.

Why this answer

The `runtimeClassName` field in the Pod spec is the standard Kubernetes API field used to specify a RuntimeClass for a Pod. The RuntimeClass named 'gvisor' must be defined in the cluster with a handler 'runsc', and setting `runtimeClassName: gvisor` in the Pod spec instructs the kubelet to use the gVisor runtime (runsc) to run the containers in a sandboxed environment, minimizing microservice vulnerabilities.

Exam trap

The CNCF-CKS exam often tests the distinction between `runtimeClassName` (a flat string field) and incorrect nested or annotation-based approaches, as candidates may confuse it with other Pod spec fields like `nodeSelector` or `annotations`.

How to eliminate wrong answers

Option A is wrong because it uses an annotation `runtimeClass: gvisor` instead of the proper `runtimeClassName` field; annotations are not processed by the kubelet for runtime selection. Option C is wrong because `nodeSelector` selects nodes based on labels, not runtime classes; it does not invoke gVisor and would run the container with the default runtime. Option D is wrong because `runtimeClass` is not a nested object with a `name` field; the correct syntax is a flat string field `runtimeClassName`.

Practice this question →

MCQmedium

You have created a ValidatingWebhookConfiguration to reject pods without resource limits. When you try to create a pod without limits, it is created successfully. What is the most likely reason?

A.The webhook is not matching the namespace labels

B.The webhook service is not running or is unreachable

C.The webhook is configured with failurePolicy: Fail

D.The pod is being created by a controller like a Deployment

AnswerB

An unreachable webhook service causes the API server's admission call to fail. With failurePolicy set to Ignore (the default), the API server permits the request, so the pod is created despite the ValidatingWebhookConfiguration. This satisfies the stem's constraint: rejection never occurs because the webhook cannot be evaluated.

Why this answer

The most likely reason a pod without resource limits is created successfully despite a ValidatingWebhookConfiguration is that the webhook service itself is not running or is unreachable. When the API server cannot contact the webhook endpoint, the default behavior (failurePolicy: Ignore) allows the request to proceed, so the pod is created without validation. If the webhook were functioning correctly, it would reject the pod; thus, the failure to reject indicates a connectivity or service issue.

Exam trap

Candidates may incorrectly assume the ValidatingWebhookConfiguration is misconfigured (e.g., missing objectSelector or wrong failurePolicy) when the actual issue is that the webhook backend service is unreachable. In Kubernetes, if the API server cannot reach the webhook server, the failurePolicy (default Ignore) allows the pod creation, so the pod passes through without validation. This is a common pitfall where the webhook service itself is not running or not accessible, rather than a configuration error.

How to eliminate wrong answers

Option A is wrong because the question does not mention namespace labels or any namespaceSelector in the webhook configuration; even if labels were mismatched, the webhook would simply not be invoked for that namespace, but the pod would still be created without limits — however, the most likely reason given the scenario is a service issue, not a label mismatch. Option C is wrong because failurePolicy: Fail would cause the API server to reject the pod if the webhook is unreachable, which contradicts the pod being created successfully; the default failurePolicy is Ignore, which allows the pod through when the webhook is down. Option D is wrong because controllers like Deployments still go through the same admission webhook process; the webhook would reject the pod regardless of whether it is created directly or via a controller.

Practice this question →

MCQeasy

Which of the following is a best practice for storing sensitive data like passwords in Kubernetes?

A.Store them in ConfigMaps

B.Store them in Secrets and mount them as volumes

C.Store them as environment variables in the Pod spec

D.Store them as labels on Pods

AnswerB

Storing Secrets and mounting them as volumes is a best practice because this method exposes data to the container as files on a filesystem, avoiding leakage through environment variables or process listings. Mounted Secrets support file-level permissions (e.g., read-only) and can be updated in place, allowing applications to pick up changes without redeployment. Additionally, the use of Secrets with volume mounts enables fine-grained RBAC controls and integrates with etcd encryption for Secrets, providing defense in depth for sensitive data.

Why this answer

Kubernetes Secrets are designed to store sensitive data such as passwords, API keys, and certificates. Mounting a Secret as a volume ensures the data is written to a tmpfs in-memory filesystem (not to disk), reducing the risk of exposure via host filesystem access. This approach also avoids leaking secrets through environment variable dumps or logs, and supports automatic rotation when the Secret is updated.

Exam trap

A common trap is believing that environment variables are safe for secrets because they are 'not written to disk', but they are exposed via /proc/<pid>/environ, appear in logs, crash dumps, and can be read by any process with access to the container's environment.

How to eliminate wrong answers

Option A is wrong because ConfigMaps store data in plaintext and are intended for non-sensitive configuration, not secrets; they lack encryption at rest by default and are often logged or exposed in etcd snapshots. Option C is wrong because storing secrets as environment variables in the Pod spec makes them visible in the container's environment, accessible via /proc/self/environ, and can be leaked in logs or debugging tools; they also cannot be rotated without Pod restart. Option D is wrong because labels on Pods are metadata used for selection and organization, not for storing sensitive data; they are visible in API responses and logs, and are not encrypted.

Practice this question →

MCQmedium

A pod is configured with securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 The volume mounted at /data is owned by user 1000 and group 2000. The container process inside the pod writes to /data. Which statement about file ownership is true?

A.Files created in /data will be owned by root:root because of the volume mount.

B.Files created in /data will be owned by user 1000 and group 2000.

C.Files created in /data will be owned by user 1000 and group 3000.

D.Files created in /data will be owned by user 1000 and group 1000.

AnswerB

The pod's securityContext defines runAsUser: 1000, so the process UID is 1000. Additionally, fsGroup: 2000 causes the mounted volume to be group-owned by GID 2000 and adds that group to the container's supplementary groups. Therefore, files created in /data are owned by user 1000 and group 2000, as the kernel assigns the effective UID and the volume's group (via setgid) to new files.

Why this answer

The `fsGroup: 2000` in the pod's securityContext causes Kubernetes to recursively change the group ownership of the volume to group 2000 and enable a setgid bit on the mount directory. When the container process (running as user 1000) writes new files to /data, those files inherit the group ownership of the directory (2000) due to the setgid bit, while the user ownership remains 1000 (the runAsUser). Thus, new files are owned by user 1000 and group 2000.

Exam trap

The CKS exam often tests the distinction between runAsGroup (the process's primary group) and fsGroup (the group ownership applied to the volume), leading candidates to incorrectly assume that new files inherit the runAsGroup instead of the fsGroup-controlled directory group.

How to eliminate wrong answers

Option A is wrong because the volume mount does not override the pod's securityContext; the container process runs as user 1000, not root, so files are not owned by root:root. Option C is wrong because the group ownership of new files is determined by the fsGroup (2000) and the setgid bit on the directory, not by the runAsGroup (3000). Option D is wrong because the group ownership is set to fsGroup (2000), not to the user's primary group (1000).

Practice this question →

MCQeasy

Which of the following is the best practice for providing sensitive data like passwords to a pod?

A.Mount secrets as volumes into the pod.

B.Use environment variables to inject secrets directly.

C.Pass secrets via command-line arguments.

D.Hardcode the secret in the container image.

AnswerA

Mounting secrets as volumes provides a filesystem-based interface that keeps the secret out of process listings, environment variables, and command-line arguments. The volume is mounted read-only and backed by tmpfs, so the secret is never written to a container's writable layer. You can also use defaultMode to set strict file permissions, limiting access to the specific UID/GID of the container. This approach also enables secrets to be updated (with some delay) by simply changing the Secret object, without a coordinated environment variable update.

Why this answer

Mounting secrets as volumes into the pod is the best practice because it ensures that secrets are stored in a tmpfs (RAM-backed) filesystem, which is never written to disk and is automatically cleaned up when the pod terminates. This approach also allows the kubelet to update the secret contents in the volume without restarting the pod, and it avoids exposing the secret in process listings, logs, or environment variable dumps.

Exam trap

A common trap is thinking that environment variables are safe because they are not in the image, but they are still exposed in the pod spec, logs, and process listings, making them less secure than volume mounts.

How to eliminate wrong answers

Option B is wrong because environment variables can be leaked through the pod's spec, logs, or /proc filesystem, and they are not automatically rotated when the secret changes. Option C is wrong because command-line arguments are visible in the process table (e.g., via `ps aux`) and are stored in the pod's definition, making them easily accessible to anyone with read access to the pod's metadata. Option D is wrong because hardcoding secrets in a container image embeds them in the image layers, which can be inspected by anyone with access to the registry and violates the principle of immutable infrastructure.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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).

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

100

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.

Practice this question →

101

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.

Practice this question →

102

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.

Practice this question →

103

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.

Practice this question →

104

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.

Practice this question →

105

MCQmedium

You want to drop all Linux capabilities from a container. Which securityContext field should you set?

A.capabilities.allow

B.capabilities.add: ["ALL"]

C.capabilities.drop: ["ALL"]

D.dropCapabilities: true

AnswerC

Setting `capabilities.drop: ["ALL"]` instructs the container runtime to remove every Linux capability from the container's bounding and effective sets, including the default privileges such as CHOWN, DAC_OVERRIDE, and NET_BIND_SERVICE. This is the most hardened posture because the container processes retain only the bare minimum needed to run, and any syscall requiring a capability will fail with EPERM. It is the correct answer because it fully satisfies the requirement to drop all capabilities.

Why this answer

Setting `capabilities.drop: ["ALL"]` in the container's `securityContext` removes all Linux capabilities from the container's process, effectively running it with zero capabilities. This is the standard Kubernetes approach to drop all capabilities, as defined in the Pod Security Standards and the container runtime interface (CRI).

Exam trap

The trap in this question is that candidates may confuse `capabilities.drop` with `capabilities.add`, or expect a boolean field like `dropCapabilities`. However, Kubernetes requires an explicit list of capabilities to drop, and using `["ALL"]` is the correct way to drop all capabilities.

How to eliminate wrong answers

Option A is wrong because `capabilities.allow` is not a valid field in the Kubernetes `securityContext`; the correct field is `capabilities.add` to add capabilities. Option B is wrong because `capabilities.add: ["ALL"]` adds all Linux capabilities to the container, which is the opposite of dropping them and increases the attack surface. Option D is wrong because `dropCapabilities: true` is not a valid Kubernetes field; the correct syntax uses `capabilities.drop` with a list of capability names.

Practice this question →

106

MCQeasy

Which flag enables the PodSecurity admission plugin in kube-apiserver?

A.--enable-admission-plugins=PodSecurity

B.--admission-control=PodSecurity

C.--feature-gates=PodSecurity=true

D.--pod-security-policy=true

AnswerA

The kube-apiserver's admission control chain is configured via the --enable-admission-plugins flag, which accepts a comma-separated list of plugin names. PodSecurity is a built-in admission plugin that, when included in this list, enforces the Kubernetes Pod Security Standards on pod create and update operations. This is the only correct way to enable the plugin in a modern control plane.

Why this answer

The PodSecurity admission plugin is enabled in kube-apiserver by passing the `--enable-admission-plugins=PodSecurity` flag. This flag activates the built-in Pod Security Admission (PSA) controller, which replaced the deprecated PodSecurityPolicy (PSP) in Kubernetes v1.25. The plugin enforces the Pod Security Standards (baseline, restricted, privileged) at the namespace level based on labels.

Exam trap

Candidates often confuse enabling a feature gate with enabling an admission plugin; the trap here is that candidates confuse `--feature-gates=PodSecurity=true` (which only makes the plugin available) with `--enable-admission-plugins=PodSecurity` (which actually activates it), or they mistakenly use the deprecated `--admission-control` flag.

How to eliminate wrong answers

Option B is wrong because `--admission-control` is a legacy flag from older Kubernetes versions (pre-1.10) and is no longer supported; the correct flag is `--enable-admission-plugins`. Option C is wrong because `--feature-gates=PodSecurity=true` only enables the PodSecurity feature gate (which is needed for the plugin to be available), but does not actually activate the admission plugin itself; the plugin must be explicitly added via `--enable-admission-plugins`. Option D is wrong because `--pod-security-policy=true` is not a valid kube-apiserver flag; the PodSecurityPolicy admission controller was enabled via `--enable-admission-plugins=PodSecurityPolicy` (now deprecated and removed in v1.25), and the flag shown does not exist.

Practice this question →

107

MCQmedium

A pod manifests with securityContext: { runAsNonRoot: true, runAsUser: 1001 }. However, the container image expects to run as root (UID 0). What will happen when the pod is created?

A.The container runs as root because runAsUser overrides runAsNonRoot

B.The container fails to start because it cannot run as root

C.The container runs as user 1001

D.The pod runs, but the securityContext is ignored

AnswerC

This is the correct behavior. The securityContext.runAsUser field explicitly sets the UID for the container's main process, overriding any USER directive from the image. Because the value is 1001, which is a non-root UID, it concurrently satisfies the runAsNonRoot constraint. The kubelet applies both settings during container startup: runAsUser determines the actual UID, and runAsNonRoot verifies that the resolved UID is not 0, ensuring the container runs as user 1001.

Why this answer

When `runAsNonRoot: true` is set, Kubernetes enforces that the container cannot run as root (UID 0). However, the pod also specifies `runAsUser: 1001`, which tells Kubernetes to run the container as UID 1001. Since UID 1001 is non-root, the `runAsNonRoot` constraint is satisfied.

The container image's expectation to run as root is irrelevant because Kubernetes overrides the user with the specified `runAsUser`. Therefore, the container will start and run as user 1001.

Exam trap

The trap is that candidates think `runAsNonRoot` alone blocks execution if the image expects root, but they overlook that `runAsUser` can override the image's user to a non-root UID. In this case, the container runs successfully as user 1001, not fails.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot` takes precedence over `runAsUser` when there is a conflict; it does not allow root execution. Option C is wrong because the container image expects to run as root, and the `runAsNonRoot` flag prevents the container from starting at all, so it never runs as user 1001. Option D is wrong because the securityContext is not ignored; it is enforced, and the container fails to start due to the violation.

Practice this question →

108

Multi-Selecteasy

You are asked to secure a set of microservices running in a Kubernetes cluster. Which TWO of the following practices help minimize vulnerabilities in microservices?

Select 2 answers

A.Manually inject sidecar proxies into every pod to enforce mTLS.

B.Run containers in privileged mode to allow them to perform necessary system calls.

C.Ensure containers run with a non-root user.

D.Use a read-only root filesystem for containers.

E.Store secrets directly in container images for easy access.

AnswersC, D

By default, containers in Kubernetes may run as the root user if the image does not declare a non-root USER, and root inside a container shares the kernel and may still access host resources depending on capabilities. Setting runAsNonRoot: true and specifying an unprivileged runAsUser (or using a non-root image USER) makes the container runtime refuse to start the process as UID 0, denying an attacker a wide range of kernel-based privilege escalation and file-permission attacks once the application is compromised. Non-root execution is a fundamental least-privilege control and must be combined with dropped capabilities and a read-only filesystem to meaningfully reduce the blast radius.

Why this answer

Running containers with a non-root user (via the `securityContext.runAsNonRoot: true` field or a specific `runAsUser` directive) prevents privilege escalation and limits the blast radius of a container compromise. This aligns with the principle of least privilege, a core mitigation against container breakout attacks in Kubernetes.

Exam trap

CNCF often tests the misconception that sidecar proxies must be manually injected to enforce mTLS, but the correct approach is to use automated injection via admission controllers to avoid misconfiguration and ensure consistent policy enforcement.

Practice this question →

109

MCQmedium

You are implementing a Gatekeeper policy to deny pods that run as root. Which Rego rule should you include in the ConstraintTemplate?

A.allow[{"msg": msg}] { msg := "container runs as root"; input.spec.containers[_].securityContext.runAsNonRoot == false }

B.deny[msg] { msg := "container runs as root"; not input.spec.containers[_].securityContext.runAsNonRoot }

C.deny[{"msg": msg}] { msg := "container runs as root"; not input.spec.containers[_].securityContext.runAsNonRoot }

D.deny[msg] { input.spec.containers[_].securityContext.runAsNonRoot == false }

AnswerC

This option fails to deny pods that specifically run as root (UID 0). The rule `not input.spec.containers[_].securityContext.runAsNonRoot` only checks for the absence or falsity of the `runAsNonRoot` flag. A container can still run as a non-root user (e.g., UID 1000) even if `runAsNonRoot` is unset, making this rule too broad for the objective of identifying actual root execution. It is tempting because `runAsNonRoot` relates to root prevention. This rule would be correct if the policy required all containers to explicitly declare `securityContext.runAsNonRoot: true` as a security best practise.

Why this answer

Option C uses the correct logic: the 'not' operator handles missing or false 'runAsNonRoot'. It also returns the expected object format {"msg": "..."}, which Gatekeeper requires. While Gatekeeper ConstraintTemplates typically require a rule named 'violation', this option contains the correct pattern and logic for denying containers that do not run as non-root.

Exam trap

A common trap is to assume that a rule named 'deny' is acceptable in Gatekeeper. Gatekeeper requires a rule named 'violation' that returns an object with a 'msg' key. Candidates often mistakenly choose 'deny' rules (options B and D) or use incorrect logic (option A).

How to eliminate wrong answers

Option A is wrong because it uses 'allow' instead of 'deny', which would incorrectly permit pods that run as root rather than denying them. Option B is wrong because it uses 'deny[msg]' without wrapping the message in an object, but Gatekeeper expects violations to be objects with a 'msg' key, so the syntax is invalid. Option D is wrong because it uses 'deny[msg]' without the object wrapper and also lacks the 'not' operator, which would only catch cases where runAsNonRoot is explicitly false, missing cases where the field is missing or undefined.

Practice this question →

110

MCQeasy

Which kubectl command would you use to create a ValidatingWebhookConfiguration from a YAML file?

A.kubectl run webhook --image=webhook --restart=Never

B.kubectl apply -f webhook.yaml

C.kubectl create -f webhook.yaml

D.kubectl expose deployment webhook --port=443

AnswerB

kubectl apply is the standard declarative approach: it sends the entire ValidatingWebhookConfiguration manifest to the API server, which then stores the resource and records the last-applied-configuration so future applies produce a precise three-way merge patch. This idempotent behavior lets you use the same command to both create and update the webhook, which is why it is the recommended method for managing admission webhook resources.

Why this answer

`kubectl apply -f webhook.yaml` is the standard command to create or update Kubernetes resources from a YAML file, including a ValidatingWebhookConfiguration. This command uses declarative management, applying the configuration defined in the file to the cluster, which is the recommended approach for creating admission webhooks.

Exam trap

In the CKS exam, candidates often confuse `kubectl create` and `kubectl apply`. While `kubectl create -f` creates a resource, `kubectl apply -f` is the preferred declarative approach for managing resources like ValidatingWebhookConfiguration because it supports idempotent updates and better handles changes over time.

How to eliminate wrong answers

Option A is wrong because `kubectl run` creates a Pod (or Deployment) from an image, not a ValidatingWebhookConfiguration; it cannot parse a YAML file for custom resource types. Option C is wrong because `kubectl create -f webhook.yaml` would attempt to create resources from the file, but it uses imperative management and may fail if the resource already exists or if the YAML contains complex configurations that require `apply` semantics; more importantly, `kubectl create` is not the typical command for ValidatingWebhookConfiguration as it does not handle updates gracefully. Option D is wrong because `kubectl expose` creates a Service to expose a deployment, not a ValidatingWebhookConfiguration; it has no relation to webhook configuration resources.

Practice this question →

111

MCQeasy

Which kubectl command would you use to create a Secret from a file named 'db-password.txt'?

A.kubectl apply -f db-password.txt

B.kubectl create configmap db-password --from-file=db-password.txt

C.kubectl create secret tls db-password --cert=db-password.txt

D.kubectl create secret generic db-password --from-file=db-password.txt

AnswerD

Correct. `kubectl create secret generic` with `--from-file` creates a generic Secret where the content of the file is stored as a key-value pair. The key defaults to the filename, and the value is the file content.

Why this answer

`kubectl create secret generic` is the command to create a generic (opaque) Secret from a file using the `--from-file` flag. This reads the content of `db-password.txt` and stores it as a key-value pair in the Secret, where the key defaults to the filename. This is the standard method for creating a Secret from a plaintext file in Kubernetes.

Exam trap

The trap here is that candidates confuse `kubectl create secret generic` with `kubectl create configmap` (Option B) or misuse `kubectl apply -f` (Option A) for non-manifest files, failing to recognize that Secrets require explicit creation commands and are distinct from ConfigMaps in purpose and handling.

How to eliminate wrong answers

Option A is wrong because `kubectl apply -f` expects a Kubernetes manifest file (YAML/JSON), not a plain text file like `db-password.txt`; it would fail to parse the content. Option B is wrong because it uses `kubectl create configmap` to create a ConfigMap, not a Secret; ConfigMaps store non-sensitive data, while Secrets are designed for sensitive data like passwords. Option C is wrong because `kubectl create secret tls` is specifically for TLS certificates and requires `--cert` and `--key` flags pointing to PEM-encoded certificate and key files, not a plain password file.

Practice this question →

112

MCQeasy

Which of the following is the correct way to drop all capabilities in a container's security context?

A.securityContext: capabilities: drop: ['ALL']

B.securityContext: capabilities: remove: ['ALL']

C.securityContext: capabilities: []

D.securityContext: capabilities: add: []

AnswerA

Setting securityContext.capabilities.drop to ['ALL'] is the correct Kubernetes syntax for revoking every Linux capability from the container's effective/permitted/bounding sets. This ensures the process starts with no capabilities, and you can selectively re-add specific capabilities using the add field. It is the recognized approach for least privilege and is required by restricted Pod Security Standards.

Why this answer

In Kubernetes, the `securityContext.capabilities.drop` field is used to explicitly remove Linux capabilities from a container. Setting `drop: ['ALL']` removes all capabilities, ensuring the container runs with the least privilege. This is the standard and recommended way to harden container security.

Exam trap

The CKS exam often tests the distinction between `drop` and `add` fields, and candidates may mistakenly think that setting `add: []` or an empty `capabilities` list achieves the same effect as dropping all capabilities.

How to eliminate wrong answers

Option B is wrong because `remove` is not a valid field in the Kubernetes security context; the correct field is `drop`. Option C is wrong because setting `capabilities: []` is invalid syntax—the `capabilities` field must be an object with `add` and/or `drop` arrays, not an empty list. Option D is wrong because `add: []` adds no capabilities but does not drop any existing ones, so the container retains its default capabilities, failing to drop all.

Practice this question →

113

Multi-Selecthard

Which THREE of the following are valid ways to manage secrets in a Kubernetes environment? (Select THREE)

Select 3 answers

A.Use an external secret manager like HashiCorp Vault and inject secrets via sidecar or CSI driver.

B.Store secrets in environment variables directly in the Deployment YAML.

C.Use Kubernetes Secret objects mounted as volumes in pods.

D.Encrypt Secret objects at rest using EncryptionConfiguration.

E.Store secrets in ConfigMaps and reference them in pods.

AnswersA, C, D

Leveraging an external secret manager such as HashiCorp Vault with a sidecar or CSI driver abstracts sensitive data entirely out of etcd. This approach enables dynamic secret rotation, centralized auditing, and fine-grained access policies, while injecting secrets into the pod only at runtime. It also avoids storing even base64-encoded secrets in Kubernetes API objects, significantly reducing the attack surface compared to native Secret objects.

Why this answer

External secret managers like HashiCorp Vault can inject secrets into pods via a sidecar container (e.g., Vault Agent) or a CSI driver (e.g., Secrets Store CSI Driver). This approach avoids storing raw secrets in the cluster, reduces the attack surface, and enables dynamic secret rotation without pod restarts.

Exam trap

A common misconception is that Kubernetes Secrets are inherently secure because they are base64-encoded, but the trap is that base64 is not encryption, and Secrets are stored in plaintext in etcd unless explicitly encrypted with EncryptionConfiguration.

Practice this question →

114

Matchingmedium

Match each Kubernetes network security concept to its definition.

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

Concepts

Matches

Outbound network traffic from a pod to external endpoints

Inbound network traffic to a pod from external sources

Specification of how groups of pods are allowed to communicate

Container Network Interface plugin that implements networking for pods

Infrastructure layer for handling service-to-service communication, often with mTLS

Why these pairings

Correct matches: NetworkPolicy defines ingress/egress rules; Calico network policy extends with advanced features; Ingress rule controls inbound traffic; Egress rule controls outbound traffic; Default deny blocks all unless allowed. Common confusions include swapping ingress and egress definitions and mistaking non-native policies as native.

Practice this question →

115

Multi-Selectmedium

Which TWO of the following are best practices for minimizing microservice vulnerabilities in a Kubernetes cluster?

Select 2 answers

A.Enable mutual TLS (mTLS) for service-to-service communication using a service mesh.

B.Run containers as root to avoid permission issues.

C.Allow all egress traffic from pods to simplify network management.

D.Set resource limits (CPU/memory) on containers to prevent resource exhaustion attacks.

E.Use hostNetwork: true for pods to improve network performance.

AnswersA, D

Mutual TLS (mTLS) in a service mesh cryptographically verifies both the client and server identities before any payload bytes are exchanged, and it encrypts all in-transit data. This eliminates entire classes of attacks such as on-path eavesdropping, request replay, and service impersonation. Mesh-provided identity (e.g., SPIFFE certificates) also gives you per-service authentication that can drive fine-grained authorization policies, making mTLS a foundational zero-trust control.

Why this answer

Mutual TLS (mTLS) encrypts and authenticates all service-to-service traffic within the cluster, preventing eavesdropping, man-in-the-middle attacks, and unauthorized access. A service mesh like Istio or Linkerd transparently enforces mTLS without requiring application code changes, ensuring that only verified services can communicate. This directly minimizes the attack surface for microservice vulnerabilities by enforcing zero-trust network principles.

Exam trap

CNCF often tests the misconception that 'simplifying network management' (e.g., allowing all egress traffic) is a security best practice, when in fact it removes critical network segmentation controls required for microservice isolation.

Practice this question →

116

Multi-Selectmedium

Which TWO of the following are best practices for securing secrets in Kubernetes?

Select 2 answers

A.Storing secrets as environment variables

B.Using the default secret type (Opaque) for all secrets

C.Enabling encryption at rest for secrets

D.Limiting the number of secrets in the cluster

E.Using an external secrets management system like HashiCorp Vault

AnswersC, E

Enabling encryption at rest for secrets is a core hardening measure because by default secrets are stored in etcd in base64-encoded plaintext, and an attacker who compromises etcd can read every secret in the cluster. Configure the kube-apiserver with an encryption provider such as AES-CBC, KMS, or AWS/GCP KMS, ensuring that the encryption keys are managed outside of etcd. This adds a layer of protection so that even if etcd backups or volumes are exposed, the secrets remain unreadable without the decryption keys.

Why this answer

Kubernetes stores secrets in etcd by default without encryption. Enabling encryption at rest (via the EncryptionConfiguration resource with a provider like AES-CBC or KMS) ensures that secret data is encrypted before being written to etcd, protecting it from unauthorized access to the underlying storage. This is a fundamental security control required for compliance and defense-in-depth.

Exam trap

The CKS exam often tests the misconception that storing secrets as environment variables is acceptable because it is 'convenient' or 'standard practice,' but the CKS exam strictly penalizes this as insecure due to exposure in process listings and logs.

Practice this question →

117

MCQmedium

You run 'kubectl auth can-i create pods --as=system:serviceaccount:default:sa1 -n default' and get 'no'. What does this mean?

A.The command is invalid because 'system:serviceaccount' is not a valid user

B.The service account 'sa1' does not exist

C.The service account 'sa1' does not have permission to create pods in the default namespace

D.The service account 'sa1' is not allowed to perform any actions

AnswerC

The 'no' from kubectl auth can-i is the API server's direct RBAC decision for the exact tuple (verb=create, resource=pods, namespace=default) when impersonating system:serviceaccount:default:sa1. This means no RoleBinding or ClusterRoleBinding grants that service account the create permission on pods in that namespace. It is a precise, scoped denial for that action alone.

Why this answer

The command 'kubectl auth can-i create pods --as=system:serviceaccount:default:sa1 -n default' impersonates the service account 'sa1' to check if it has RBAC permissions to create pods in the 'default' namespace. A response of 'no' means that the current RBAC bindings (Role/ClusterRole and RoleBinding/ClusterRoleBinding) do not grant the 'create' verb on 'pods' resources to that service account. This is a direct authorization check against the Kubernetes RBAC system, not an indication of the service account's existence or general capability.

Exam trap

Candidates may mistake the 'no' response as meaning the service account is missing or invalid, but 'kubectl auth can-i' does not verify existence; it only tests RBAC authorization rules.

How to eliminate wrong answers

Option A is wrong because 'system:serviceaccount:default:sa1' is a valid Kubernetes user identifier for a service account, and the 'kubectl auth can-i' command correctly supports impersonation of service accounts via the --as flag. Option B is wrong because the command does not verify the existence of the service account; it performs an RBAC authorization check based on the provided identity, and a 'no' response does not imply the service account is missing. Option D is wrong because the 'no' response only indicates lack of permission for the specific action (create pods in the default namespace), not that the service account is denied all actions; it may have other permissions.

Practice this question →

118

MCQmedium

You need to enforce that no pod runs with privileged containers or runs as root. Which tool can define policies that block such pods at admission time?

A.Kubernetes Secret

B.PodDisruptionBudget

C.OPA Gatekeeper

D.NetworkPolicy

AnswerC

OPA Gatekeeper is a validating admission webhook based on Open Policy Agent that evaluates every pod creation request against customizable ConstraintTemplates and Constraints defined by cluster administrators. It can inspect any field in the pod specification, including securityContext.privileged, and reject or mutate requests that violate defined policies. For example, a constraint can deny any pod with privileged: true, effectively enforcing the 'no privileged containers' rule. Because Gatekeeper intercepts API requests during admission, it is the correct and powerful mechanism to enforce such pod security policies.

Why this answer

OPA Gatekeeper is a Kubernetes admission controller that enforces custom policies defined via the Constraint Framework (CF). It can reject pods that request privileged containers or run as root by evaluating constraints against the PodSecurityPolicy-like rules expressed in Rego, blocking them before they are persisted in etcd.

Exam trap

A common mistake is confusing runtime enforcement (e.g., AppArmor, seccomp) with admission-time enforcement (e.g., OPA Gatekeeper, PodSecurity Admission). Candidates often choose NetworkPolicy because it 'blocks' something, but it blocks network traffic, not pod creation.

How to eliminate wrong answers

Option A is wrong because a Kubernetes Secret is an object for storing sensitive data (e.g., passwords, tokens) and has no admission control capability to block pods based on security context. Option B is wrong because a PodDisruptionBudget (PDB) only controls the minimum number of available pods during voluntary disruptions (e.g., node drains) and does not evaluate pod security settings at admission time. Option D is wrong because a NetworkPolicy defines ingress/egress traffic rules at the network layer (L3/L4) and cannot inspect or block pod creation based on container privileges or user identity.

Practice this question →

119

MCQeasy

You need to ensure that all pods in a cluster run with read-only root filesystems. Which Pod Security Standard (PSS) control field should be set to true?

A.spec.readOnlyRootFilesystem

B.securityContext.privileged: false

C.container.readOnly

D.securityContext.readOnlyRootFilesystem

AnswerD

Set securityContext.readOnlyRootFilesystem: true at the container level (spec.containers[].securityContext) to instruct the container runtime to mount the container's root filesystem as read-only. This prevents processes in the container from writing to the image's filesystem, though writable volumes such as emptyDir or persistentVolumeClaims remain writable if mounted. It is the only field listed that directly enforces a read-only root filesystem, and it must be repeated for every container that needs this protection.

Why this answer

The Pod Security Standard (PSS) control field `securityContext.readOnlyRootFilesystem` must be set to `true` at the pod or container security context level to enforce a read-only root filesystem. This setting prevents containers from writing to their root filesystem, reducing the attack surface by limiting the ability to drop malicious binaries or modify system files. It is a key control under the 'Restricted' PSS profile for minimizing microservice vulnerabilities.

Exam trap

The CKS exam often tests the distinction between pod-level and container-level security context fields, and candidates mistakenly look for a field under `spec` (like `spec.readOnlyRootFilesystem`) instead of the correct nested path `securityContext.readOnlyRootFilesystem` at the container level.

How to eliminate wrong answers

Option A is wrong because `spec.readOnlyRootFilesystem` is not a valid field; the correct field is nested under `securityContext` at the container level, not directly under `spec`. Option B is wrong because `securityContext.privileged: false` disables privileged mode but does not enforce a read-only root filesystem; it is a separate security control. Option C is wrong because `container.readOnly` is not a valid Kubernetes field; the correct field is `readOnlyRootFilesystem` within the container's `securityContext`.

Practice this question →

120

MCQmedium

A developer reports that a pod fails to start with the error 'container has runAsNonRoot and image will run as root'. The pod spec includes securityContext.runAsNonRoot: true but does not specify runAsUser. The container image's Dockerfile does not set a USER instruction. Which change should you make to the pod spec to resolve the error while still enforcing non-root execution?

A.Set securityContext.readOnlyRootFilesystem to true.

B.Set securityContext.runAsUser to a numeric UID greater than 0.

C.Set securityContext.allowPrivilegeEscalation to false.

D.Set securityContext.privileged to true.

AnswerB

When runAsNonRoot is true and the image would run as root (UID 0), the kubelet rejects the container. Specifying a numeric runAsUser greater than 0 tells the runtime to run the process as that non-root UID, satisfying the policy. This is the correct fix because it both resolves the error and maintains the non-root enforcement requirement.

Why this answer

The runAsNonRoot check fails when the effective UID is 0. Setting a numeric runAsUser greater than 0 provides a non-root UID, satisfying the policy. Other security context fields like privileged, allowPrivilegeEscalation, and readOnlyRootFilesystem do not change the user ID and therefore do not fix this error.

Exam trap

The trap here is thinking that allowPrivilegeEscalation or readOnlyRootFilesystem can satisfy runAsNonRoot, but only an explicit non-root runAsUser or a non-root USER in the image resolves the error.

Practice this question →

121

MCQmedium

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

A.capabilities.drop: ["ALL"]

B.privileged: false

C.allowPrivilegeEscalation: false

D.runAsNonRoot: true

AnswerC

The setting allowPrivilegeEscalation: false is specifically designed to prevent privilege escalation by setting the no_new_privs process attribute (or equivalent) on the container's main process. When enabled, this Linux security feature blocks any execution that would result in a privilege gain, including setuid/setgid binaries, file capabilities, and other mechanisms that could elevate the process's UID or GID. It is the sole option among these that directly addresses the privileged escalation vector, making it the correct control for the security team's requirement.

Why this answer

`allowPrivilegeEscalation: false` directly controls whether a process can gain more privileges than its parent, which is the mechanism by which containers acquire new capabilities (e.g., via `setuid` binaries or `file capabilities`). Setting this to `false` prevents privilege escalation within the container, effectively blocking the acquisition of new capabilities beyond those initially granted. This field is defined in the Pod Security Context and is a key control for minimizing microservice vulnerabilities.

Exam trap

The trap is that candidates often choose capabilities.drop: ['ALL'] because it removes all capabilities, but the question asks for preventing containers from gaining new capabilities. allowPrivilegeEscalation: false prevents privilege escalation at runtime, which is the mechanism for gaining new capabilities beyond those initially granted.

How to eliminate wrong answers

Option A is wrong because `capabilities.drop: ["ALL"]` drops all capabilities from the container's bounding set, but it does not prevent the container from gaining new capabilities later (e.g., through a `setcap` binary or a privileged helper process); it only removes existing ones at start time. Option B is wrong because `privileged: false` is the default and disables privileged mode, but it does not specifically prevent capability escalation; a non-privileged container can still gain new capabilities via `setuid` or file capabilities if `allowPrivilegeEscalation` is not set to false. Option D is wrong because `runAsNonRoot: true` ensures the container runs as a non-root user, but it does not block the acquisition of new capabilities; a non-root user can still gain capabilities through `setcap` or other mechanisms if privilege escalation is allowed.

Practice this question →

122

MCQmedium

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

A.Remove the service account from the pod

B.Set securityContext.runAsNonRoot: true

C.Set automountServiceAccountToken: false in the pod spec

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

AnswerC

The PodSpec boolean automountServiceAccountToken is the exact field the kubelet consults when deciding whether to project the ServiceAccount token into the container's filesystem. When set to false, the token volume is not automatically added to the Pod, so even a compromised or malicious command like 'exec cat /var/run/secrets/kubernetes.io/serviceaccount/token' would fail because the file simply does not exist. This is the intended, first-line mitigation for restricting credential exposure within a Pod.

Why this answer

Setting `automountServiceAccountToken: false` in the pod spec prevents the automatic mounting of the service account token into the container's filesystem. By default, Kubernetes mounts a token at `/var/run/secrets/kubernetes.io/serviceaccount/token`, which can be read via `kubectl exec` as shown. Disabling this mount blocks direct access to the token from within the pod, mitigating the risk of token theft or misuse.

Exam trap

The trap here is that candidates confuse network-level controls (NetworkPolicy) with filesystem-level access, or mistakenly think `runAsNonRoot` or removing the service account (which is not possible post-creation) would block token access, when the actual solution is to disable the automatic mount of the token.

How to eliminate wrong answers

Option A is wrong because you cannot remove a service account from a pod after creation; service accounts are assigned at pod creation and cannot be changed without recreating the pod. Option B is wrong because `securityContext.runAsNonRoot: true` only enforces that the container runs as a non-root user, but does not prevent the mounting or reading of the service account token. Option D is wrong because a NetworkPolicy controls network traffic to/from pods, but the `kubectl exec` command uses the Kubernetes API server (which is typically on the control plane network) and does not rely on pod-to-API-server network access; the token is read locally from the filesystem, not over the network.

Practice this question →

123

MCQmedium

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

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

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

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

D.The secret is not base64 encoded.

AnswerB

Setting a Secret as an environment variable copies its value into the container's process environment, where it can be read from /proc/self/environ, captured by debugging tools, or inadvertently written to logs by the application. If the container is compromised, the attacker can trivially dump these variables and extract the secret in plaintext. Mounting the Secret as a file into a volume is preferred because the value is only present on the filesystem and not exposed in process metadata.

Why this answer

Injecting secrets as environment variables exposes them in the container's process environment, which can be read from /proc/self/environ or /proc/1/environ by any process running in the container. If the container is compromised, an attacker can easily extract the secret from the environment, and it may also leak into logs or error messages. Kubernetes secrets should be mounted as files (e.g., via volumes) to reduce exposure, as environment variables are more accessible to malicious code.

Exam trap

A common misconception is that base64 encoding or secret naming is a security concern, when the real issue is the attack surface introduced by environment variable injection versus file-based mounts.

How to eliminate wrong answers

Option A is wrong because encryption at rest in etcd is a cluster-level concern that applies to all secrets, but it does not address the specific vulnerability of exposing secrets via environment variables in a container. Option C is wrong because the name 'db-secret' being generic is not a security concern; secret names do not affect security posture. Option D is wrong because base64 encoding is not a security measure—it is merely a serialization format for storing binary data in YAML, and secrets are automatically base64 encoded when created via kubectl; the security issue is about exposure, not encoding.

Practice this question →

124

MCQhard

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

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

B.Using a mutating webhook to apply security contexts

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

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

AnswerC

OPA/Gatekeeper is a valid admission control tool, but it does not include built-in Pod Security Standards (PSS) templates. To enforce PSS levels like restricted or baseline, you must write custom Rego policies or import externally maintained constraint templates. Relying on 'built-in PSS templates' is therefore incorrect because such templates are not provided out of the box, making this an invalid method as stated.

Why this answer

OPA/Gatekeeper does not have built-in Pod Security Standards (PSS) templates; it enforces custom policies defined in Rego, not the predefined PSS profiles (privileged, baseline, restricted). While Gatekeeper can be used to implement PSS-like controls, it requires writing custom constraint templates, whereas the built-in PSS templates are a feature of Pod Security Admission (PSA), not OPA/Gatekeeper. Therefore, stating that OPA/Gatekeeper uses 'built-in PSS templates' is incorrect.

Exam trap

A common misconception in the CKS exam is that OPA/Gatekeeper includes built-in Pod Security Standards templates, but those templates are exclusive to Pod Security Admission (PSA). Gatekeeper requires custom Rego policies to enforce similar controls.

How to eliminate wrong answers

Option A is wrong because Pod Security Policy (PSP) was a valid method to enforce pod security standards in Kubernetes versions prior to 1.21 (deprecated in 1.21, removed in 1.25), and if still available in the cluster, it remains a valid enforcement mechanism. Option B is wrong because a mutating webhook can indeed be used to apply security contexts (e.g., setting runAsNonRoot, readOnlyRootFilesystem) to pods, which is a valid method to enforce pod security standards. Option D is wrong because Pod Security Admission (PSA) with labels on namespaces is the official replacement for PSP and is a valid method to enforce the three PSS profiles (privileged, baseline, restricted) by setting the 'pod-security.kubernetes.io/enforce' label on a namespace.

Practice this question →

125

MCQmedium

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

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

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

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

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

AnswerA

Environment variables injected from Secrets are visible to any process that can read /proc/<pid>/environ or execute `env` inside the container; they are inherited by child processes and can appear in crash dumps, debug logs, and shell history. Mounted secret files, by contrast, are not broadcast through process metadata—an attacker must already have code execution in the container and explicitly read the file, which is a narrower, deliberate action. This is why the security recommendation is to mount secrets as files rather than pass them as environment variables.

Why this answer

Environment variables are inherited by all processes in the container and can be read via commands like `env` or by accessing `/proc/1/environ` from any process, even without a shell. In contrast, secrets mounted as volumes are only accessible to processes that explicitly read the file path, and only if the container has a shell or the process has file system access. This reduces the attack surface by limiting exposure to processes that need the secret.

Exam trap

A common misconception tested in the exam is that mounted volumes are invisible in /proc or that they automatically rotate secrets, but the real security advantage is the reduced exposure of secrets to processes and commands that can list environment variables.

How to eliminate wrong answers

Option B is wrong because mounted volumes are visible in `/proc/mounts` and the secret files are accessible through the container's filesystem, so they are not invisible to other processes. Option C is wrong because environment variables are not stored in etcd in plaintext; Kubernetes Secrets are base64-encoded in etcd, and encryption at rest is a cluster-level configuration that applies to both environment variables and volumes equally. Option D is wrong because mounted volumes do not automatically rotate secrets; the pod must be restarted or the volume contents must be manually refreshed (e.g., using a sidecar or inotify) to reflect updates to the Secret object.

Practice this question →

126

Multi-Selecteasy

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

Select 2 answers

A.docker

B.runc

C.runsc

D.containerd

E.kata

AnswersC, E

runsc is the correct RuntimeClass handler for gVisor, which intercepts system calls at the user-space kernel level to provide an extra isolation boundary between containers and the host kernel. When gVisor is installed and the CRI runtime (like containerd) is configured with the handler name 'runsc', you can define a RuntimeClass that references it. This makes runsc a valid and commonly used RuntimeClass for sandboxed workloads, as it provides stronger security than the default runc runtime while still being OCI-compatible.

Why this answer

(runsc) is correct because it is the handler for gVisor, a user-space kernel that provides an additional layer of sandboxing between the container and the host kernel. In Kubernetes, a RuntimeClass with handler 'runsc' instructs the container runtime (e.g., containerd) to launch the container using gVisor's runsc runtime, which intercepts system calls to enforce a security boundary.

Exam trap

The CKS exam often tests the distinction between container runtimes (like runc) and sandboxing runtimes (like runsc or kata), and the trap here is that candidates mistakenly select runc because it is a common runtime, but it does not provide sandboxing isolation.

Practice this question →

127

MCQhard

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

A.ClusterSecretStore

B.ExternalSecret

C.VaultSecret

D.SecretStore

AnswerB

ExternalSecret is the ESO custom resource that declares the exact source data to retrieve from an external provider, such as a specific Vault path and the remote keys, and defines the target Kubernetes Secret, including its name, namespace, and when/how the secret is refreshed. It references a SecretStore or ClusterSecretStore only for backend credentials and configuration. The ESO controller watches ExternalSecrets, fetches the requested key-value pairs, and writes them as a native Kubernetes Secret. This is precisely the resource the question asks about, making it the correct answer.

Why this answer

The ExternalSecret resource is the core custom resource definition (CRD) in the External Secrets Operator (ESO) that defines the mapping between a secret stored in an external provider (like HashiCorp Vault) and a Kubernetes Secret. It specifies which remote secret path and key to fetch, and how to transform that data into the desired Kubernetes Secret object. Without an ExternalSecret, the operator has no instruction to create or sync any Kubernetes Secret.

Exam trap

The exam often tests the distinction between the store configuration (SecretStore/ClusterSecretStore) and the actual secret mapping (ExternalSecret), leading candidates to confuse the backend connection resource with the resource that defines the secret data mapping.

How to eliminate wrong answers

Option A is wrong because ClusterSecretStore is a cluster-scoped configuration that defines how to authenticate and connect to an external secrets provider (e.g., Vault), but it does not define the mapping of individual secrets. Option C is wrong because VaultSecret is not a valid CRD in the External Secrets Operator; it is a common misconception from other tools or older versions. Option D is wrong because SecretStore is a namespaced version of the store configuration, similar to ClusterSecretStore, and it only defines the backend connection, not the secret mapping.

Practice this question →

128

MCQmedium

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

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

B.The pod creation is denied with a message

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

D.The pod is created but logged as a violation

AnswerB

The deny action in a Gatekeeper constraint template produces a ValidatingAdmissionPolicy that intercepts pod creation requests. When the constraint's violation condition is met, the API server receives a rejection response containing the configured violation message, thus preventing the pod from being created. This is the standard enforcement mechanism for Gatekeeper, where admission is denied rather than merely flagged or altered.

Why this answer

The Gatekeeper ConstraintTemplate defines a Rego policy that denies any Pod creation request that lacks the 'security-tier' label. When the user creates a Pod without this label, the admission webhook evaluates the policy and returns a denial message 'Pod must have label 'security-tier'', preventing the Pod from being created. Gatekeeper operates as a validating admission webhook, so it rejects the request before the object is persisted in etcd.

Exam trap

The exam often tests the distinction between validating and mutating admission webhooks—candidates may mistakenly think Gatekeeper can auto-add labels (mutating behavior) or that it only logs violations (audit mode), but the Rego policy here uses 'deny' which causes immediate rejection.

How to eliminate wrong answers

Option A is wrong because Gatekeeper does not automatically add missing labels; it only validates and denies or allows requests based on the policy. Option C is wrong because Gatekeeper evaluates every admission request independently; there is no 'first-only' behavior—each Pod without the label is denied consistently. Option D is wrong because Gatekeeper denies the request outright when the policy is violated; it does not create the Pod and log the violation—that behavior would require a mutating webhook or an audit-only mode, which is not configured here.

Practice this question →

129

Multi-Selecthard

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

Select 3 answers

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

B.It configures how traffic is routed between services

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

D.It requires a DestinationRule to define the TLS settings

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

AnswersA, C, E

PeerAuthentication is an Istio security policy that defines mTLS enforcement at the mesh, namespace, or workload level. When applied to a namespace, it applies to all workloads in that namespace, enforcing mTLS by setting the TLS mode. This is the straightforward way to require mutual TLS for every service in that namespace without configuring each deployment individually.

Why this answer

Istio PeerAuthentication defines the mutual TLS (mTLS) mode for traffic between services within a mesh. When applied at the namespace level, it enforces the specified mTLS mode (e.g., STRICT) for all workloads in that namespace, ensuring that all inter-service communication uses TLS certificates for identity and encryption.

Exam trap

Candidates often confuse the role of Istio PeerAuthentication (which controls mTLS mode) with DestinationRule (which controls traffic routing and TLS settings for outbound connections). They may incorrectly think a DestinationRule is required for PeerAuthentication to work, when in fact PeerAuthentication is independent and only sets the mTLS policy for inbound traffic.

Practice this question →

130

MCQmedium

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

A.ValidatingWebhookConfiguration

B.WebhookConfiguration

C.MutatingWebhookConfiguration

D.AdmissionWebhook

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

131

MCQeasy

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

A.PeerAuthentication

B.VirtualService

C.DestinationRule

D.ServiceEntry

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

132

Multi-Selectmedium

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

Select 2 answers

A.--dry-run

B.--from-literal

C.--from-yaml

D.--from-file

E.--from-env-file

AnswersD, E

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

Why this answer

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

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

Exam trap

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

Practice this question →

133

MCQeasy

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

A.runAsUser: 1000

B.readOnlyRootFilesystem: true

C.allowPrivilegeEscalation: false

D.runAsNonRoot: true

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

134

MCQhard

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

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

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

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

135

MCQmedium

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

A.AuthorizationPolicy

B.ServiceEntry

C.VirtualService

D.PeerAuthentication

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

136

MCQeasy

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

A.Constraint

B.ValidatingWebhookConfiguration

C.ConstraintTemplate

D.ConfigMap

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

137

MCQeasy

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

A.secret

B.emptyDir

C.hostPath

D.configMap

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

138

Multi-Selecthard

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

Select 3 answers

A.Set securityContext.runAsNonRoot: true

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

C.Set high CPU requests to ensure performance

D.Set securityContext.readOnlyRootFilesystem: true

E.Expose secrets as environment variables for convenience

AnswersA, B, D

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

Why this answer

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

Exam trap

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

Practice this question →

139

MCQeasy

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

A.securityContext: dropCapabilities: true

B.securityContext: privileged: false

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

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

140

MCQmedium

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

A.allowPrivilegeEscalation

B.readOnlyRootFilesystem

C.privileged

D.runAsNonRoot

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

141

MCQhard

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

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

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

C.The pod mounts a ConfigMap as a volume.

D.The pod uses a PersistentVolumeClaim for storage.

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

142

MCQeasy

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

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

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

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

143

MCQeasy

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

A.Set securityContext.readOnlyRootFilesystem: true

B.Set securityContext.privileged: false

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

D.Set securityContext.allowPrivilegeEscalation: false

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

144

MCQmedium

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

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

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

C.A Constraint resource that enforces the readOnlyRootFilesystem rule

D.A ValidatingWebhookConfiguration that points to the Gatekeeper service

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

145

MCQeasy

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

A.privileged: false

B.readOnlyRootFilesystem: true

C.allowPrivilegeEscalation: false

D.runAsNonRoot: true

AnswerD

`runAsNonRoot: true` enforces that the container's main process runs with a UID other than 0. Kubernetes validates the image's configured user (from the `USER` directive) or the `runAsUser` field; if neither specifies a non-root UID, pod creation fails. This is the precise security context setting that matches the requirement, as it directly controls the user identity.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

146

MCQeasy

Which kubectl command lists all MutatingWebhookConfigurations in the cluster?

A.kubectl get webhooks

B.kubectl list webhooks

C.kubectl get mutatingwebhookconfigurations

D.kubectl get mutating-webhooks

AnswerC

The correct resource is `mutatingwebhookconfigurations` (plural form of MutatingWebhookConfiguration) from the `admissionregistration.k8s.io/v1` API group. `kubectl get mutatingwebhookconfigurations` queries the API server for all cluster-scoped mutating admission webhook configurations, which intercept resource requests to modify objects before they are persisted. This command will return a list of the configured webhooks, or an empty list if none exist. The singular form `kubectl get mutatingwebhookconfiguration` is also accepted, but the plural form is the canonical resource name.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

147

MCQmedium

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

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

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

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

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

AnswerD

This security context satisfies the policy by combining two essential controls: capabilities.drop: ["ALL"] removes every Linux capability from the container's effective/permitted sets, and allowPrivilegeEscalation: false prevents any process from gaining additional privileges via setuid, file capabilities, or other escalation paths. Together they enforce a strict least-privilege environment where even a compromised process cannot elevate its rights. This is the canonical way to run a truly unprivileged pod in Kubernetes.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

148

MCQeasy

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

A.Docker

B.containerd

C.gVisor (runsc)

D.runc

AnswerC

gVisor (runsc) is an OCI runtime that implements a user-space kernel, intercepting system calls made by the container and processing them in user space rather than passing them to the host kernel. This architecture significantly reduces the host kernel attack surface, making gVisor specifically designed for sandboxing and running untrusted workloads. The user-space kernel adds a layer of isolation that standard runtimes do not provide.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

149

MCQmedium

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

A.PeerAuthentication with mTLS mode STRICT

B.Sidecar resource with outboundTrafficPolicy REGISTRY_ONLY

C.ServiceEntry with resolution NONE

D.DestinationRule with trafficPolicy tls mode ISTIO_MUTUAL

AnswerA

PeerAuthentication is the Istio policy resource that enforces mTLS for workloads. Setting mode STRICT requires all inbound requests to present valid client certificates, rejecting plaintext HTTP traffic. Since the server-side sidecar proxy enforces this policy, it is the correct control for mandating mutual TLS across all services in a namespace.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

150

MCQeasy

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

A.To replace Kubernetes NetworkPolicies for network segmentation.

B.To provide a centralized logging solution.

C.To automatically scale pods based on CPU usage.

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

AnswerD

The primary purpose of a service mesh is to enable mutual TLS (mTLS) between services transparently, so each sidecar proxy terminates and re-originates TLS connections, presenting workload identities (typically SPIFFE-based) and verifying the peer's certificate. This ensures all service-to-service traffic is both encrypted in transit and mutually authenticated, preventing eavesdropping, man-in-the-middle attacks, and unauthorized service impersonation. The mesh takes over certificate issuance, rotation, and transmission, which means the application code and containers do not need to embed or manage TLS secrets themselves.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →