Courseiva

CCNA Minimize Microservice Vulnerabilities Questions

75 of 161 questions · Page 1/3 · Minimize Microservice Vulnerabilities · Answers revealed

Practice these questionsDomain overviewAll questions
1
Multi-Selectmedium

Which TWO of the following are valid approaches to manage secrets in a Kubernetes cluster?

Select 2 answers
A.Pass secrets as environment variables
B.Embed secrets directly in the pod YAML definition
C.Mount secrets as volumes in pods
D.Store secrets as plain text in ConfigMap
E.Use an external secrets manager like HashiCorp Vault with CSI driver
AnswersC, E

Mounting secrets as volumes in pods is the Kubernetes-native best practice because the secret is rendered as individual files on a tmpfs volume, which is memory-backed and not written to disk. File permissions default to 0444, and can be tightened to 0400; additionally, when the secret is updated, kubelet eventually updates the mounted files, allowing for rotation without restarting the pod. This approach avoids exposure via /proc/environ and limits access to containers that explicitly mount the volume.

Why this answer

Kubernetes allows secrets to be mounted as volumes in pods, which is a secure approach as the secret data is stored in tmpfs (RAM-backed filesystem) and not written to disk on the node. This method avoids exposing secrets in environment variables that can be leaked through process dumps or logs, and it supports automatic updates when secrets are modified.

Exam trap

A common pitfall is selecting option A (passing secrets as environment variables) because it seems convenient, but environment variables can be exposed through /proc, logs, and debugging commands. The correct secure approaches are mounting secrets as volumes (C) and using external secrets managers (E).

Practice this question →
2
MCQmedium

A security admin wants to ensure that no container in a specific namespace runs as root. Which Gatekeeper ConstraintTemplate and Constraint configuration should be used?

A.ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsNonRoot == true }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`
B.ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsNonRoot != true }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`
C.ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.capabilities.drop != "ALL" }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`
D.ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsUser == 0 }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`
AnswerB

This constraint correctly enforces the non-root requirement by denying any pod in which any container does not set `securityContext.runAsNonRoot` to true. In Rego, a missing field evaluates as false, so `runAsNonRoot != true` catches both explicit `false` and undefined cases, blocking containers that could run as root. The constraint scope on Pods ensures every container in the spec is evaluated without exception.

Why this answer

The goal is to deny any Pod whose containers do not explicitly set runAsNonRoot to true. In Rego, the deny rule must fire when the condition is violated, so the correct expression is `input.review.object.spec.containers[_].securityContext.runAsNonRoot != true`. This matches containers that either omit the field or set it to false, which is exactly the insecure state the admin wants to block.

The Constraint then binds this template to Pods via match.kinds.

Exam trap

CKS often tests the direction of the Rego condition — candidates mistakenly write `== true` when the deny rule must fire on the insecure state (`!= true`), inverting the policy.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot == true` denies Pods that are already compliant (non-root), inverting the policy's intent. Option C is wrong because it checks capabilities.drop != "ALL", which is a different security control (dropping Linux capabilities) and does not enforce non-root execution. Option D is wrong because checking `runAsUser == 0` only catches containers that explicitly set UID 0; it misses containers that omit runAsUser entirely and may still run as root by default.

Practice this question →
3
MCQmedium

You need to drop all Linux capabilities from a container. Which YAML snippet is correct?

A.capabilities: { remove: ["ALL"] }
B.capabilities: { drop: ["ALL"] }
C.capabilities: { none: true }
D.securityContext: { capabilities: { drop: ["ALL"] } }
AnswerD

This is correct because the `securityContext` at the container level is the only place where Linux capabilities are configured in Kubernetes. The `capabilities.drop` list accepts `"ALL"` as a special token that removes every capability from the container's effective and permitted sets, giving a minimal attack surface. Because it is nested under `securityContext`, the kubelet applies it when creating the container via the container runtime.

Why this answer

In Kubernetes, to drop Linux capabilities from a container, you must use the `capabilities.drop` field inside `securityContext`. Option D correctly nests `capabilities` under `securityContext`. Option B is incorrect because it places `capabilities` directly under the container spec without the `securityContext` wrapper, which is not valid in most Kubernetes API versions.

Options A and C use invalid keywords (`remove` and `none`). Therefore, only Option D is correct.

Exam trap

CNCF often tests the distinction between `drop` and `remove` in the capabilities field, where `drop` is the correct Kubernetes API field name, and `remove` is a common but incorrect alternative that candidates might mistakenly use.

How to eliminate wrong answers

Option A is wrong because `remove` is not a valid field in the Kubernetes capabilities specification; the correct field is `drop`. Option C is wrong because `none: true` is not a valid syntax for managing capabilities in Kubernetes; capabilities must be explicitly dropped using the `drop` field. Option D is wrong because while the structure `securityContext: { capabilities: { drop: ["ALL"] } }` is technically correct, the question asks for the correct YAML snippet, and option B is the only one that directly provides the correct snippet without extraneous nesting; however, note that option D is also marked as correct in the answer options, but the question expects a single correct answer, and option B is the most concise and direct representation.

Practice this question →
4
MCQmedium

A microservice running as a Deployment in a Kubernetes cluster needs to authenticate to a third-party API using a static API key. Which is the most secure way to store and inject this secret into the container?

A.Store the API key in a ConfigMap and expose it as an environment variable
B.Hardcode the API key in the container image
C.Store the API key in a Kubernetes Secret and mount it as a volume inside the container
D.Store the API key in a Kubernetes Secret and expose it as an environment variable
AnswerC

Mounting the Secret as a volume avoids exposing the API key in environment variables, which can leak via process listings or crash dumps. It satisfies the requirement for secure injection into the container without baking credentials into the image or manifest.

Why this answer

Mounting a Kubernetes Secret as a volume provides the most secure method for injecting sensitive data into a container. Unlike environment variables, which can be exposed through process listings, container logs, or `/proc` filesystem, a volume mount stores the secret in the container's filesystem with permissions restricted to the runtime user. This approach also supports automatic rotation of secret values without restarting the pod, as the filesystem is updated in place when the Secret object changes.

Exam trap

CNCF often tests the misconception that environment variables from Secrets are equally secure as volume mounts, but the trap is that environment variables are more exposed to runtime leaks and cannot be rotated without pod restart, whereas volume mounts offer better isolation and live update capabilities.

How to eliminate wrong answers

Option A is wrong because ConfigMaps store data in plaintext and are intended for non-sensitive configuration, not secrets like API keys. Option B is wrong because hardcoding secrets in a container image embeds them in the image layers, making them accessible to anyone with image pull access and violating immutable infrastructure principles. Option D is wrong because exposing a Secret as an environment variable increases the risk of leakage through container logs, debugging endpoints, or the `/proc/self/environ` file, and does not support seamless secret rotation without pod restart.

Practice this question →
5
MCQmedium

You need to encrypt Kubernetes secrets at rest. Which resource should you configure?

A.EncryptionProvider
B.SecretEncryptionConfig
C.KMSProvider
D.EncryptionConfiguration
AnswerD

EncryptionConfiguration is the correct API resource, defined in apiserver.config.k8s.io/v1, that specifies encryption providers and their keys for etcd data. You pass it to the kube-apiserver via the --encryption-provider-config flag, and it governs how resources like Secrets are encrypted at rest. This is the only valid object among the options for configuring at-rest encryption.

Why this answer

Kubernetes uses an `EncryptionConfiguration` object to configure encryption at rest for secrets and other resources in etcd. This YAML-based resource defines which providers (e.g., `aescbc`, `kms`, `secretbox`) are used to encrypt data before it is written to the underlying storage. The API server reads this configuration from a file specified via the `--encryption-provider-config` flag, enabling transparent encryption and decryption of resource data.

Exam trap

A common Kubernetes certification pitfall is confusing the `EncryptionConfiguration` resource (the top-level configuration object) with the individual provider types like `KMSProvider` or `aescbc` that are listed inside it. Candidates may pick a provider name instead of the configuration resource itself.

How to eliminate wrong answers

Option A is wrong because `EncryptionProvider` is not a valid Kubernetes resource; the correct term is `EncryptionConfiguration`, which references provider types like `aescbc` or `kms` within its `resources` array. Option B is wrong because `SecretEncryptionConfig` is a fictional resource name; Kubernetes does not have a dedicated resource for secret-only encryption, and the `EncryptionConfiguration` object applies to any resource type listed in its `resources` field. Option C is wrong because `KMSProvider` is not a standalone resource; it is a provider type (e.g., `kms` or `kmstool`) that can be used inside an `EncryptionConfiguration` to delegate encryption to an external Key Management Service like AWS KMS or GCP Cloud KMS.

Practice this question →
6
Multi-Selectmedium

You want to use an external secret management system like HashiCorp Vault to manage database credentials for your application. Which of the following are valid approaches to integrate Vault with Kubernetes?

Select 3 answers
A.Use environment variables from Vault with a script
B.Store Vault tokens in a Kubernetes Secret and mount them
C.Use the Vault Agent Sidecar Injector to inject secrets into pods
D.Use the Vault CSI Provider to mount secrets as volumes
E.Store Vault tokens in a ConfigMap and mount them into pods
AnswersB, C, D

Storing a Vault token in a Kubernetes Secret and mounting that Secret as a volume or env var is technically valid — the token itself is protected at rest by etcd encryption (if enabled) and access is governed by RBAC, so it acts as a static bootstrap credential. However, this approach has a significant security downside: the Vault token is a long-lived, high-privilege credential that, once copied into the Secret, does not rotate automatically and could be exfiltrated if the Secret or its decrypted contents are exposed. It works for simple use cases, but because the token remains valid until its TTL or an explicit revocation, it is less secure than using Vault Agent or CSI, which handle dynamic, short-lived secrets.

Why this answer

Storing Vault tokens in a Kubernetes Secret and mounting them into pods is a valid integration approach. The token is retrieved from Vault (e.g., via a Kubernetes auth method) and stored as a Secret, which is then mounted as a volume or environment variable, allowing the application to authenticate with Vault and fetch secrets dynamically.

Exam trap

The trap here is that candidates may think environment variables or ConfigMaps are acceptable for secrets, but the CKS exam emphasizes that ConfigMaps are for non-sensitive data and environment variables can leak secrets via logs or /proc, while Vault integration requires secure token handling via Secrets or dedicated injectors.

Practice this question →
7
Multi-Selecteasy

Which TWO container sandboxing technologies are supported in Kubernetes via RuntimeClass? (Choose two)

Select 2 answers
A.gVisor (runsc)
B.Docker
C.containerd
D.runc
E.Kata Containers
AnswersA, E

gVisor (runsc) is an OCI runtime that provides application-level sandboxing: it intercepts system calls made by container processes and handles them with the Sentry, a user-space kernel implemented in Go, instead of passing them directly to the host kernel. This design dramatically reduces the kernel attack surface for workloads that run in untrusted pods. In Kubernetes, runsc is exposed through a RuntimeClass, letting the scheduler place specific pods onto the gVisor runtime.

Why this answer

gVisor (runsc) is a container sandboxing technology that provides a user-space kernel for containers, isolating them from the host kernel. Kubernetes supports gVisor via RuntimeClass, allowing pods to be scheduled with the 'runsc' runtime for enhanced security.

Exam trap

Candidates often confuse container runtimes (like containerd and runc) with container sandboxing technologies (like gVisor and Kata Containers). In the CNCF exam, only sandboxing technologies are supported via RuntimeClass for enhanced isolation.

Practice this question →
8
Multi-Selecthard

You are deploying a workload that must be isolated from other workloads on the same node. You want to use a container sandboxing runtime to provide an additional security boundary. Which TWO of the following are true regarding the use of gVisor or Kata Containers in a Kubernetes cluster? (Choose two.)

Select 2 answers
A.They are only supported on Windows nodes and cannot run on Linux.
B.They require a RuntimeClass resource and a corresponding handler configured on the node.
C.They provide kernel-level isolation by running each container in its own virtual machine or user-space kernel.
D.They can be enabled by setting the pod's securityContext.privileged field to true.
E.They automatically encrypt all container images at rest on the node.
AnswersB, C

Both gVisor and Kata Containers are implemented as container runtimes that must be registered with the container runtime interface (CRI) on each node. A RuntimeClass object references the handler name, and the pod's spec.runtimeClassName selects it. Without the RuntimeClass and node-level handler, the pod cannot be scheduled with the sandboxed runtime, making this a necessary configuration step.

Why this answer

Sandboxed runtimes like gVisor and Kata Containers require a RuntimeClass and a node-level handler to be selected by pods. They add isolation by using a user-space kernel or a lightweight VM, reducing the risk of container escapes. They are not enabled via privileged mode, do not encrypt images, and are not limited to Windows nodes.

Exam trap

The trap here is confusing sandboxing with privileged mode, which actually removes isolation, or assuming sandboxing provides image encryption rather than runtime isolation.

Practice this question →
9
MCQmedium

A security engineer runs the following command to inspect a container's security context. What vulnerability does this configuration expose?

A.The container is running without any capabilities
B.The container has all capabilities enabled, which is a security risk
C.The container has dropped all capabilities except NET_BIND_SERVICE
D.The container has default Docker capabilities, which is secure
AnswerB

The CapEff value is a full mask, meaning every capability supported by the kernel is present in the container process's effective set. With all capabilities, the process can invoke privileged syscalls such as mount(), ptrace(), and operations guarded by CAP_SYS_ADMIN, essentially matching root on the host for capability-restricted actions. This dramatically increases the host attack surface if the container is compromised, so the configuration is a significant security risk.

Why this answer

The command `docker run --privileged` or a similar configuration that grants all capabilities (e.g., `--cap-add=ALL`) removes all kernel-level isolation, giving the container full access to the host's kernel capabilities. This means the container can perform privileged operations like loading kernel modules, modifying network settings, and accessing raw devices, which directly violates the principle of least privilege and exposes the host to container breakout attacks.

Exam trap

CNCF often tests the distinction between 'default Docker capabilities' (which are secure and limited) and 'all capabilities' (which is a severe vulnerability), and the trap here is that candidates may confuse 'all capabilities' with the default set or think that dropping all capabilities is the only insecure state.

How to eliminate wrong answers

Option A is wrong because the container is explicitly configured with all capabilities enabled, not running without any capabilities (which would be the case with `--cap-drop=ALL`). Option C is wrong because the configuration grants all capabilities, not a minimal set like only `NET_BIND_SERVICE`; dropping all but one capability would be a secure practice, not a vulnerability. Option D is wrong because default Docker capabilities (a restricted set like `CHOWN`, `DAC_OVERRIDE`, `FSETID`, `FOWNER`, `MKNOD`, `NET_RAW`, `SETGID`, `SETUID`, `SETFCAP`, `SETPCAP`, `NET_BIND_SERVICE`, `SYS_CHROOT`, `KILL`, `AUDIT_WRITE`) are considered secure for most workloads, but this configuration explicitly grants all capabilities, which is far less restrictive and insecure.

Practice this question →
10
MCQeasy

What is the primary benefit of using external secret managers (e.g., HashiCorp Vault) in Kubernetes?

A.They ensure that secrets are never stored in etcd
B.They prevent all unauthorized access to secrets
C.They provide better control over secret rotation, auditing, and access policies
D.They eliminate the need for Kubernetes Secrets entirely
AnswerC

External secret managers centralize lifecycle controls such as automated rotation, expiration enforcement, and granular IAM-based access policies that are not supported natively by Kubernetes Secrets. They also produce detailed audit logs of who accessed which secret and when, enabling compliance and forensic analysis. This operational advantage over static Kubernetes Secrets is the primary reason organizations adopt them.

Why this answer

External secret managers such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault provide centralized lifecycle management for secrets, including automated rotation, detailed audit logging, and fine-grained access policies. In Kubernetes, integrating these tools (via CSI drivers or operators) gives teams stronger governance than native Kubernetes Secrets, which lack built-in rotation and rich auditing. The primary benefit is therefore better control over rotation, auditing, and access policies.

Exam trap

CKS often tests the misconception that external secret managers eliminate secrets from etcd — in reality, syncSecret and native Secret usage can still persist them, so the correct answer focuses on governance benefits, not absolute elimination.

How to eliminate wrong answers

Option A is wrong because external secret managers do not guarantee secrets are never stored in etcd — if the secret is synced into a Kubernetes Secret object, it is still stored in etcd unless the integration injects it directly into the pod (e.g., via CSI volume) without creating a Secret. Option B is wrong because no tool can prevent all unauthorized access; external managers improve access control but do not make it absolute. Option D is wrong because external secret managers complement, not eliminate, Kubernetes Secrets — many integrations still use Secret objects as a delivery mechanism.

Practice this question →
11
MCQhard

A cluster has a ValidatingWebhookConfiguration that intercepts Pod CREATE requests. The webhook server is unavailable. What happens when a user tries to create a pod?

A.The webhook is automatically disabled
B.The API server crashes
C.The pod creation is rejected until the webhook becomes available
D.The pod is created without webhook validation
AnswerC

A ValidatingWebhookConfiguration with failurePolicy set to Fail rejects requests when the webhook server cannot be reached. Because the webhook intercepts Pod CREATE, admission fails closed, so the pod creation is rejected until the server recovers.

Why this answer

When a ValidatingWebhookConfiguration is defined and the webhook server is unavailable, the default failure policy is `Fail`, which causes the API server to reject the Pod CREATE request. This ensures that security validation is not bypassed due to webhook downtime, maintaining the cluster's security posture. The pod creation is blocked until the webhook becomes available again, as specified by the `failurePolicy` field in the webhook configuration.

Exam trap

The CKS exam often tests the default `failurePolicy` behavior, and the trap here is that candidates assume the API server will simply skip validation or crash, rather than understanding that the default `Fail` policy causes the request to be rejected.

How to eliminate wrong answers

Option A is wrong because ValidatingWebhookConfigurations are not automatically disabled when the webhook server is unavailable; the failure policy (`Fail` or `Ignore`) determines the behavior, not an automatic disable. Option B is wrong because the API server does not crash; it handles the webhook timeout or connection error gracefully by applying the configured failure policy, which may reject the request but does not cause a crash. Option D is wrong because the pod is not created without validation unless the failure policy is explicitly set to `Ignore`; by default, it is `Fail`, which rejects the request.

Practice this question →
12
Multi-Selectmedium

Which TWO of the following are correct about container sandboxing technologies? (Select TWO)

Select 2 answers
A.Kata Containers run containers in lightweight VMs, providing hardware-level isolation.
B.gVisor provides a kernel-level sandbox by implementing a user-space kernel.
C.Kata Containers use the host kernel for system calls.
D.gVisor runs containers in separate VMs for each pod.
E.Both gVisor and Kata Containers require RuntimeClass to be used in Kubernetes.
AnswersA, B

Kata Containers provide hardware-level isolation by spawning each container or pod inside a lightweight VM that is booted with its own guest kernel, typically using KVM on Linux. The guest kernel handles system calls as if it were a real host, and the hypervisor enforces CPU and memory isolation at the hardware boundary. This design gives each container a full kernel of its own, which is a stronger isolation boundary than syscall interception because even a compromised guest kernel cannot directly access the host kernel.

Why this answer

Kata Containers provide hardware-level isolation by running each container or pod in a lightweight VM with its own guest kernel using KVM. Option B is correct because gVisor implements a user-space kernel (called Sentry) that intercepts system calls, providing a kernel-level sandbox without dedicated VMs. Option C is incorrect because Kata Containers use a guest kernel, not the host kernel.

Option D is incorrect because gVisor does not run containers in separate VMs; it runs as a kernel within the user space. Option E is incorrect because although RuntimeClass is commonly used to select non-default runtimes in Kubernetes, the statement is not universally required; it is a mechanism but not a strict requirement for using these technologies, making the claim that both 'require' RuntimeClass too absolute and thus false.

Exam trap

Candidates may be misled by the appealing combination of A, B, and E, but only A and B are correct. The statement in E is too absolute because RuntimeClass is not strictly required—it is an optional mechanism.

Practice this question →
13
MCQmedium

A pod uses a Secret mounted as a volume. The Secret is updated. How can the pod consume the updated values without restarting?

A.Use a sidecar container that watches for changes and reloads the application
B.Update the pod spec to reference a new Secret version
C.The mounted volume is automatically updated over time
D.Delete and recreate the pod
AnswerC

For a Secret mounted as a regular volume (not via subPath or as a projected volume), the kubelet periodically syncs the Secret from the API server to the volume directory, so the file contents are updated automatically. This triggers inotify events that a well-designed application can watch to reload configuration without restarting the Pod. The update is eventually consistent and typically occurs within a minute, but the application must be coded to re-read the file from disk after receiving a change notification.

Why this answer

When a Secret is mounted as a volume in Kubernetes, the kubelet periodically syncs the secret data from the API server and updates the files in the volume. This means the pod can consume the updated values without needing a restart, as the files are refreshed automatically (with a default sync period of around 60 seconds). Option C correctly identifies this behavior.

Exam trap

Candidates often think that updating a Secret requires a pod restart, but in Kubernetes, Secrets mounted as volumes are automatically updated by the kubelet without restart.

How to eliminate wrong answers

Option A is wrong because while a sidecar container can watch for changes and reload the application, it is not the default or automatic mechanism; the question asks how the pod can consume updated values without restarting, and the built-in volume update handles that without requiring a sidecar. Option B is wrong because Kubernetes Secrets do not have versioning; you cannot reference a 'new Secret version' in the pod spec — you must update the same Secret object or create a new one and update the pod spec to reference the new name, which would require a pod restart. Option D is wrong because deleting and recreating the pod is unnecessary; the mounted volume is automatically updated by the kubelet, so restarting is not required.

Practice this question →
14
MCQmedium

An admin has deployed a ValidatingWebhookConfiguration that denies pods with `runAsNonRoot: false`. After creating a pod that does not set `runAsNonRoot` at all, the pod is created successfully. Why did the webhook not deny it?

A.The webhook configuration's rules do not match the pod create operation
B.The webhook's failure policy is set to Ignore
C.The webhook is only applied to pods in a specific namespace
D.The webhook only applies to pods created with a specific service account
AnswerA

For a ValidatingWebhookConfiguration to be triggered, the incoming request must match the declared rules on apiGroups, apiVersions, resources, and operations. If the rules omit the 'pods' resource or the 'create' operation (or the pod's API version/group), the API server bypasses this webhook entirely. Thus, the observed absence of any admission response is fully explained by a rules mismatch, making this the correct answer.

Why this answer

A is correct because the ValidatingWebhookConfiguration's `rules` define which API operations (e.g., create, update) and resources (e.g., pods) trigger the webhook. If the rules do not include the `create` operation for pods, the webhook will not intercept the pod creation request, so the pod is created without validation. The pod's security context (missing `runAsNonRoot`) is irrelevant if the webhook never fires.

Exam trap

The CKS exam often tests the misconception that a webhook's failure policy (Ignore/Fail) controls whether it denies requests, when in fact the `rules` matching is the primary gate for webhook invocation.

How to eliminate wrong answers

Option B is wrong because the failure policy (Ignore or Fail) only determines behavior when the webhook itself is unreachable or returns an error, not when the webhook is not triggered by the request. Option C is wrong because the question states the pod was created successfully, implying no namespace restriction was in effect; even if a namespaceSelector existed, the pod would have been denied if the webhook matched. Option D is wrong because service account filtering is configured via `matchConditions` or `objectSelector`, not by default, and the question provides no evidence of such a filter.

Practice this question →
15
Multi-Selecthard

Which ONE of the following is a valid Rego policy construct used in OPA Gatekeeper ConstraintTemplates to enforce security policies?

Select 1 answer
A.violation[{"msg": msg}] { condition }
B.allow { condition }
C.deny[{"msg": msg}] { condition }
D.audit { condition }
E.warn[{"msg": msg}] { condition }
AnswersA

The `violation[{"msg": msg}] { condition }` construct is the canonical rule format for Gatekeeper ConstraintTemplates. Gatekeeper's admission and audit controllers compile the template's Rego and expect a partial set rule named `violation`; whenever the `condition` evaluates to true, the set is non-empty and the constraint's enforcement action (deny, warn, or dryrun) is applied. The `msg` variable binds to a human-readable message that is surfaced in the audit results or admission response. This construct directly fulfills Gatekeeper's internal policy enforcement contract.

Why this answer

In OPA Gatekeeper ConstraintTemplates, the only Rego construct that directly triggers a constraint violation is `violation[{"msg": msg}] { condition }`. When the condition evaluates to true, Gatekeeper generates a violation message. The `allow` and `deny` rules are not standard constructs for enforcing constraints in Gatekeeper; they are general Rego rules used in other OPA contexts but not within ConstraintTemplates to report violations.

Options D (`audit`) and E (`warn`) are also not valid Rego constructs for Gatekeeper constraints.

Exam trap

Candidates may mistakenly think that `allow` and `deny` are valid constructs within Gatekeeper ConstraintTemplates. In reality, only the `violation` rule is used to trigger constraint violations. `allow` and `deny` are general Rego rules used in other OPA contexts, but not for defining Gatekeeper constraints.

Practice this question →
16
MCQhard

A cluster administrator wants to run some workloads in a sandboxed environment using gVisor. Which Kubernetes resource must be created first to allow pods to request the gVisor runtime?

A.Create a new PodSecurityPolicy that allows the gVisor runtime
B.Create a custom resource definition for the runtime
C.Create a RuntimeClass resource that specifies the gVisor runtime handler
D.Add a `runtimeClass` field to the pod spec
AnswerC

A RuntimeClass is a cluster-scoped, built-in object whose handler field names the runtime configuration registered on each node, for example ',runsc,' for gVisor. When a pod's spec sets runtimeClassName to reference this object, the kubelet passes the handler to the container runtime (like containerd), which then launches the pod under the gVisor sandbox. Creating this RuntimeClass resource is the mandatory administrative step, as it establishes the mapping between a simple name and the actual OCI runtime handler that workloads will use.

Why this answer

C is correct because in Kubernetes, a RuntimeClass resource must be created to define a container runtime configuration, such as gVisor. This resource specifies a runtime handler (e.g., 'runsc') that the container runtime uses to run pods in a sandboxed environment. Pods can then reference this RuntimeClass via the `runtimeClassName` field in their spec to request the gVisor runtime.

Exam trap

Kubernetes often tests the distinction between creating a resource (RuntimeClass) versus referencing it in a pod spec, so candidates mistakenly think adding the `runtimeClass` field directly to the pod is sufficient without first creating the RuntimeClass object.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (deprecated in v1.21 and removed in v1.25) controls security context constraints, not runtime selection; it cannot specify which container runtime to use. Option B is wrong because a custom resource definition (CRD) is used to extend the Kubernetes API with new resource types, but RuntimeClass is a built-in API resource (node.k8s.io/v1) that does not require a CRD. Option D is wrong because the `runtimeClass` field in the pod spec is a reference to an existing RuntimeClass object; the RuntimeClass resource must be created first before any pod can use it.

Practice this question →
17
Multi-Selectmedium

Which TWO of the following are required to enable encryption of Kubernetes Secrets at rest?

Select 2 answers
A.Configure etcd encryption via etcdctl
B.Create an EncryptionConfiguration resource
C.Enable the --feature-gates=EncryptionAtRest=true flag on the API server
D.Pass the --encryption-provider-config flag to the kube-apiserver
AnswersB, D

The EncryptionConfiguration manifest defines which resources are encrypted and names the provider (for example aescbc or kms). The API server reads this file to know what to encrypt, making its creation a prerequisite before any flag can reference it.

Why this answer

Option B is correct because enabling encryption at rest for Kubernetes Secrets requires creating an EncryptionConfiguration resource, a YAML file that defines the encryption providers (such as aescbc, aesgcm, or secretbox) and their key material used to encrypt resources like secrets in etcd. Option D is correct because the kube-apiserver must be started with the --encryption-provider-config flag pointing to that EncryptionConfiguration file; without this flag the API server ignores the configuration and writes Secrets to etcd in plaintext. Option A is incorrect because etcdctl is only an administrative CLI for interacting with etcd (for example, verifying that stored values are prefixed with k8s:enc:), not a mechanism for configuring encryption.

Option C is incorrect because EncryptionAtRest is not a feature gate that must be enabled; the feature is controlled entirely by the --encryption-provider-config flag and the EncryptionConfiguration resource, so no such --feature-gates flag exists or is needed.

Exam trap

The CNCF CKS exam often tests the misconception that encryption at rest is enabled via a feature gate or etcdctl, when in fact it requires creating an EncryptionConfiguration resource and passing it via the --encryption-provider-config flag to the kube-apiserver.

Practice this question →
18
MCQeasy

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

A.ServiceAccount
B.PodSecurityPolicy
C.NodeRestriction
D.ValidatingAdmissionWebhook and MutatingAdmissionWebhook
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
19
MCQhard

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

A.Use kubectl encrypt secrets command.
B.Modify the etcd configuration to enable encryption.
C.Create an EncryptionConfiguration resource and pass it to the kube-apiserver via the --encryption-provider-config flag.
D.Set the environment variable ENCRYPT_SECRETS=true on all nodes.
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
20
Multi-Selectmedium

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

Select 2 answers
A.Set the container image to use a root user
B.Set runAsNonRoot: true in the pod securityContext
C.Use a PodSecurityPolicy (PSP)
D.Use a Kyverno policy to validate runAsNonRoot
E.Set runAsUser: 0 in the container securityContext
AnswersB, D

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

Why this answer

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

Exam trap

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

Practice this question →
21
MCQmedium

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

A.PeerAuthentication with mtls.mode: STRICT in the namespace
B.VirtualService with tls mode
C.DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL
D.ServiceEntry for external services
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
22
Multi-Selectmedium

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

Select 2 answers
A.Setting `runAsNonRoot: true` in the pod's securityContext
B.Using an emptyDir volume mounted at /
C.Setting `fsGroup: 1000` in the pod's securityContext
D.Using a MutatingWebhookConfiguration that adds `readOnlyRootFilesystem: true` to all containers
E.Setting `readOnlyRootFilesystem: true` in the container's securityContext
AnswersD, E

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

Why this answer

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

Exam trap

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

Practice this question →
23
Multi-Selecthard

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

Select 3 answers
A.Enforce that containers set runAsNonRoot: true.
B.Enforce that containers do not mount hostPath volumes with read-write access.
C.Allow privileged containers for system-critical workloads.
D.Allow containers to use hostNetwork for easier service discovery.
E.Enforce that containers set seccompProfile.type to RuntimeDefault or Localhost.
AnswersA, B, E

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

Why this answer

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

Exam trap

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

Practice this question →
24
Multi-Selecthard

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

Select 2 answers
A.Create a ServiceEntry for internal services
B.Create a VirtualService with tls termination
C.Create a PeerAuthentication resource with mtls.mode: STRICT
D.Set global.mtls.enabled: true in IstioConfigMap
E.Create a DestinationRule with tls.mode: ISTIO_MUTUAL
AnswersC, E

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

Why this answer

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

Exam trap

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

Practice this question →
25
MCQhard

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

A.Create a NetworkPolicy to block pods without limits.
B.Create a MutatingWebhookConfiguration to add resource limits automatically.
C.Create a ValidatingWebhookConfiguration that calls an external service to validate pod limits.
D.Create a ConstraintTemplate with a Rego policy that checks for 'spec.containers[*].resources.limits', then create a Constraint targeting pods.
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
26
MCQmedium

You need to create a NetworkPolicy that denies all ingress traffic to pods with label 'app: web' in the 'frontend' namespace, except for traffic from pods with label 'app: ingress' in the 'ingress' namespace. Which NetworkPolicy spec correctly achieves this?

A.ingress: - from: - namespaceSelector: matchLabels: name: ingress podSelector: matchLabels: app: ingress
B.ingress: - from: - namespaceSelector: matchLabels: app: ingress podSelector: {}
C.ingress: - from: - podSelector: matchLabels: app: ingress - namespaceSelector: matchLabels: kubernetes.io/metadata.name: ingress
D.ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: ingress podSelector: matchLabels: app: ingress
AnswerD

This is correct because a single 'from' entry containing both a namespaceSelector and a podSelector applies Boolean AND semantics: the source pod must run in a namespace that carries the 'kubernetes.io/metadata.name: ingress' label (i.e., the namespace literally named 'ingress') AND the pod itself must have the label 'app: ingress'. Since no other ingress rules exist, the policy defaults to deny all other ingress traffic, precisely matching the requirement. Using the standard metadata.name label ensures reliable namespace identification without relying on manually maintained labels.

Why this answer

It uses a single `from` entry with both a `namespaceSelector` (matching the `ingress` namespace by its `kubernetes.io/metadata.name` label) and a `podSelector` (matching pods with `app: ingress`). This combination restricts ingress traffic to only pods that are both in the `ingress` namespace AND have the label `app: ingress`, while implicitly denying all other ingress traffic to pods labeled `app: web` in the `frontend` namespace.

Exam trap

A common trap in CKS is to confuse AND vs OR logic in NetworkPolicy selectors. Option C uses separate 'from' entries (OR logic), making it overly permissive, while the correct approach combines namespaceSelector and podSelector in a single 'from' block (AND logic).

How to eliminate wrong answers

Option A is wrong because it uses a `namespaceSelector` with `matchLabels: {name: ingress}` but the `ingress` namespace may not have a label `name: ingress`; Kubernetes automatically assigns the `kubernetes.io/metadata.name` label, not `name`. Option B is wrong because it uses `podSelector: {}` which matches all pods in the selected namespace, but the `namespaceSelector` incorrectly uses `matchLabels: {app: ingress}` — namespaces do not have an `app` label by default, and even if they did, it would select the wrong namespace. Option C is wrong because it lists two separate `from` entries: the first allows traffic from any pod with `app: ingress` in any namespace, and the second allows traffic from any pod in the `ingress` namespace; this creates an OR condition, allowing traffic from pods with `app: ingress` in any namespace (including the `frontend` namespace), which violates the requirement to only allow traffic from the `ingress` namespace.

Practice this question →
27
MCQeasy

Which command can be used to view the current set of admission webhooks in the cluster?

A.kubectl get webhooks
B.kubectl get validatingwebhookconfigurations
C.kubectl get webhookconfigurations
D.kubectl get admissionwebhooks
AnswerB

This is the correct command. ValidatingWebhookConfiguration is a real admissionregistration.k8s.io/v1 resource that defines validation webhooks. Running 'kubectl get validatingwebhookconfigurations' lists all registered validating webhook configurations, which contain the webhook client configuration, rules, and failure policy. These resources are cluster-scoped and directly represent the admission webhooks that validate API requests.

Why this answer

Admission webhooks in Kubernetes are configured via `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` resources. The command `kubectl get validatingwebhookconfigurations` retrieves all validating admission webhooks currently registered in the cluster, which is the standard way to list them.

Exam trap

The trap here is that candidates may assume a generic `webhooks` or `admissionwebhooks` resource exists, but Kubernetes requires the exact resource names `validatingwebhookconfigurations` and `mutatingwebhookconfigurations`.

How to eliminate wrong answers

Option A is wrong because there is no `webhooks` resource type in Kubernetes; the correct resource types are `validatingwebhookconfigurations` and `mutatingwebhookconfigurations`. Option C is wrong because `webhookconfigurations` is not a valid Kubernetes API resource; the proper plural form is `validatingwebhookconfigurations` or `mutatingwebhookconfigurations`. Option D is wrong because `admissionwebhooks` is not a valid Kubernetes API resource; admission webhooks are managed through the specific `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` objects.

Practice this question →
28
MCQmedium

A security scanner reports that a microservice container image contains a critical vulnerability (CVE-2024-1234) in a system library. The team cannot immediately rebuild the image. What is the most effective temporary mitigation at the Kubernetes level?

A.Apply a NetworkPolicy to block egress traffic from the Pod
B.Apply a custom seccomp profile that blocks the vulnerable syscall
C.Apply an AppArmor profile to the Pod
D.Use a PodSecurityPolicy to drop all capabilities
AnswerB

A custom seccomp profile restricts the set of syscalls a process may make, and if the scanner mapped the library CVE to a specific syscall, denying that syscall creates a direct mitigation at the kernel boundary. Even when the vulnerable library remains in the image, the exploit cannot complete because the necessary syscall is rejected with EPERM. This is the only option that acts directly on syscall invocation.

Why this answer

A custom seccomp (secure computing mode) profile can restrict the system calls (syscalls) a container is allowed to make. By blocking the specific vulnerable syscall exploited by CVE-2024-1234, you can prevent the vulnerability from being triggered at runtime without rebuilding the image. This is a temporary, Kubernetes-native mitigation that directly addresses the attack vector at the syscall level.

Exam trap

CNCF often tests the distinction between seccomp (syscall filtering) and AppArmor/SELinux (MAC on files and capabilities), leading candidates to confuse AppArmor as a syscall blocker when it is not.

How to eliminate wrong answers

Option A is wrong because blocking egress traffic with a NetworkPolicy only prevents outbound network connections; it does not prevent exploitation of a local system library vulnerability, which typically does not require network egress. Option C is wrong because AppArmor profiles enforce mandatory access control (MAC) on file paths, network, and capabilities, but they do not filter syscalls; seccomp is the correct mechanism for syscall-level restriction. Option D is wrong because dropping all capabilities with a PodSecurityPolicy (or Pod Security Admission) removes Linux capabilities like CAP_NET_RAW, but it does not block specific syscalls; the vulnerable syscall may still be invoked even with no capabilities.

Practice this question →
29
MCQmedium

You have enabled encryption at rest for Kubernetes Secrets by configuring an EncryptionConfiguration object and restarting the API server. After the configuration, you create a new Secret. However, when you retrieve the Secret using 'kubectl get secret mysecret -o yaml', the 'data' field still shows base64-encoded plaintext. Is the Secret encrypted at rest?

A.No, because only Secrets in namespaces with a specific annotation are encrypted.
B.Yes, but only if the Secret was created after the API server restart.
C.No, because the data is still visible in the API response.
D.Yes, because encryption at rest applies to the storage layer (etcd), not the API response.
AnswerD

EncryptionConfiguration encrypts Secret objects at the etcd storage layer, so the on-disk data is ciphertext. The API server decrypts before returning responses, which is why kubectl still shows base64-encoded plaintext — base64 is an encoding, not encryption, and does not indicate the at-rest state.

Why this answer

Encryption at rest in Kubernetes protects data when it is stored in etcd, the underlying key-value store. The API server decrypts the data transparently when serving it via the API, so the base64-encoded plaintext visible in `kubectl get secret -o yaml` is the decrypted output, not the raw encrypted data. The EncryptionConfiguration object ensures that new or updated Secrets are encrypted before being written to etcd, but the API response always shows the plaintext after decryption.

Exam trap

The trap here is that candidates mistakenly believe that if the Secret data is readable in the kubectl output, it is not encrypted at rest. However, encryption at rest applies to the storage layer (etcd), and the API server decrypts on retrieval.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not require a namespace annotation to enable encryption at rest; encryption is applied cluster-wide based on the EncryptionConfiguration resource. Option B is wrong because encryption at rest applies to any Secret written to etcd after the API server restart, regardless of when it was created, as long as the EncryptionConfiguration is active. Option C is wrong because the visibility of plaintext in the API response is expected—encryption at rest protects data on disk (etcd), not in transit or in API responses, which are decrypted by the API server before serving.

Practice this question →
30
MCQmedium

A security engineer wants to enable mutual TLS (mTLS) between services in an Istio service mesh. Which Istio resource should be used to define the mTLS mode for the entire mesh?

A.DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL
B.PeerAuthentication with mTLS mode set to STRICT
C.VirtualService with tls configuration
D.ServiceEntry with mTLS enabled
AnswerB

PeerAuthentication with mTLS mode set to STRICT is the correct approach because PeerAuthentication is the Istio policy resource that enforces TLS at the server side. When mode: STRICT is applied, the sidecar proxy requires all incoming connections to use mutual TLS and rejects plaintext traffic, thereby enforcing mTLS for the selected workloads. This can be set at the mesh, namespace, or workload level, making it the standard way to enable mesh-wide mTLS.

Why this answer

PeerAuthentication is the Istio resource specifically designed to define the authentication policy for workloads, including the mTLS mode. Setting `mTLS.mode: STRICT` in a PeerAuthentication policy enforces mutual TLS for all traffic within the mesh, ensuring that every service-to-service connection requires a valid client certificate. This is the correct resource for mesh-wide mTLS enforcement, as it operates at the authentication layer rather than the traffic routing layer.

Exam trap

A common pitfall in the CKS exam is confusing DestinationRule (which handles traffic routing and connection pool settings) with PeerAuthentication (which handles mTLS enforcement). Candidates often choose DestinationRule because it has a tls field, but for mesh-wide mTLS, PeerAuthentication with mode: STRICT is the correct resource.

How to eliminate wrong answers

Option A is wrong because DestinationRule with `trafficPolicy.tls.mode: ISTIO_MUTUAL` configures TLS settings for traffic routing and load balancing, but it does not enforce authentication or mTLS at the service identity level; it only specifies the TLS mode for connections to a specific host, not the entire mesh. Option C is wrong because VirtualService is used for traffic routing, retries, and fault injection, not for defining mTLS or authentication policies; it has no `tls` configuration for mTLS mode. Option D is wrong because ServiceEntry is used to register external services into the mesh, not to define mTLS policies for internal mesh traffic; enabling mTLS on a ServiceEntry would apply to external endpoints, not the entire mesh.

Practice this question →
31
MCQmedium

A security best practice is to avoid storing sensitive data in environment variables. Instead, secrets should be mounted as volumes. Which of the following YAML snippets correctly mounts a Kubernetes Secret named 'db-secret' as a volume at /etc/secrets?

A.volumes: - name: secret-volume secret: name: db-secret containers: - name: app volumeMounts: - name: secret-volume mountPath: /etc/secrets
B.volumes: - name: secret-volume configMap: name: db-secret containers: - name: app volumeMounts: - name: secret-volume mountPath: /etc/secrets
C.volumes: - name: secret-volume secret: secretName: db-secret containers: - name: app volumeMounts: - name: secret-volume mountPath: /etc/secrets
D.containers: - name: app env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password
AnswerC

This option correctly defines a Secret volume by specifying the 'secretName' field to reference the 'db-secret' Secret object, then mounts it at the desired path of /etc/secrets. Mounting the Secret as a volume exposes each key as a file containing the corresponding value, which is a more secure pattern than passing secrets via environment variables because files are less likely to appear in process listings or container logs. This is the correct way to satisfy the requirement of using a volume to store sensitive data.

Why this answer

It uses the `secret` volume type with the `secretName` field to reference the 'db-secret' Secret, and mounts it at /etc/secrets via a volumeMount. This adheres to the best practice of mounting secrets as volumes rather than injecting them as environment variables, which can be exposed in process listings or logs.

Exam trap

The CKS exam often tests the distinction between the `name` field (used for the volume's name) and the `secretName` field (used to reference the Secret object), leading candidates to incorrectly choose Option A which uses `name` instead of `secretName`.

How to eliminate wrong answers

Option A is wrong because it uses the `secret` volume type with a `name` field directly under `secret`, but the correct field to specify the Secret's name is `secretName`, not `name`. Option B is wrong because it uses a `configMap` volume type instead of `secret`, which would mount a ConfigMap named 'db-secret' rather than the intended Secret. Option D is wrong because it injects the secret value as an environment variable using `secretKeyRef`, which violates the best practice of avoiding sensitive data in environment variables.

Practice this question →
32
Multi-Selecthard

Which THREE of the following are characteristics of container sandboxing runtimes like gVisor and Kata Containers?

Select 3 answers
A.They eliminate the need for seccomp profiles
B.They require setting spec.runtimeClassName in the pod spec
C.They have higher performance overhead compared to runc
D.They share the host kernel directly
E.They provide stronger isolation than default runc
AnswersB, C, E

Kubernetes selects the container runtime for a pod through the optional `.spec.runtimeClassName` field, which references a pre-defined RuntimeClass object. The RuntimeClass has a handler like 'runsc' or 'kata' that tells the kubelet which runtime to use. If omitted, the default runc runtime is used; therefore, opting into sandboxing requires explicitly setting runtimeClassName in the pod spec.

Why this answer

Container sandboxing runtimes like gVisor and Kata Containers are not the default runtime in Kubernetes. To use them, you must specify the runtime class name in the pod spec via `spec.runtimeClassName`. This field references a `RuntimeClass` resource that defines which container runtime (e.g., `gvisor`, `kata`) should be used for that pod, overriding the default runc runtime.

Exam trap

The CKS exam often tests the misconception that sandboxing runtimes eliminate the need for other security mechanisms like seccomp, when in reality they are complementary layers, and that these runtimes share the host kernel (they do not, which is the entire point of their isolation).

Practice this question →
33
MCQmedium

A cluster administrator has configured EncryptionConfiguration to encrypt secrets at rest using a local key. After applying the configuration, the administrator creates a new secret. How can they verify that the secret is encrypted at rest?

A.Run kubectl get secret -o yaml and check for an encryption annotation.
B.Use kubectl describe secret and look for 'Encrypted: true'.
C.Check the apiserver logs for encryption status messages.
D.Use etcdctl to read the secret directly from etcd and verify it is encrypted.
AnswerD

Reading the secret directly from etcd with etcdctl bypasses the API server's decryption layer, giving you the raw bytes as stored. When encryption at rest is enabled, the stored value begins with a 'k8s:enc:' prefix followed by the encryption provider name (e.g., 'aescbc'), and the payload is ciphertext. This is the only reliable method to verify that a secret is encrypted on disk, because it shows the actual storage format without any API server processing.

Why this answer

Encryption at rest is applied at the etcd storage layer, not at the Kubernetes API level. To verify that a secret is actually encrypted when stored, you must read it directly from etcd using etcdctl (with the appropriate endpoint and certificate flags). If the encryption configuration is working, the secret data will appear as base64-encoded ciphertext (e.g., starting with 'k8s:enc:aescbc:...') rather than plaintext base64 of the original secret data.

Exam trap

The trap here is that candidates assume Kubernetes CLI commands like kubectl get or describe can reveal encryption status, when in fact the API server transparently decrypts data on retrieval, so you must bypass the API server and inspect the storage backend directly.

How to eliminate wrong answers

Option A is wrong because kubectl get secret -o yaml returns the secret after it has been decrypted by the API server, so the output shows the plaintext data, not the encrypted form; there is no encryption annotation added by the EncryptionConfiguration. Option B is wrong because kubectl describe secret does not show an 'Encrypted: true' field; the describe output only displays metadata and the size of the data, not encryption status. Option C is wrong because the API server logs may indicate that encryption configuration was loaded or report errors, but they do not provide a per-secret verification that the stored data is encrypted; the definitive check is reading the raw value from etcd.

Practice this question →
34
MCQhard

You are writing a Rego policy for OPA/Gatekeeper to deny pods that do not have runAsNonRoot set to true. Which Rego statement should the ConstraintTemplate contain?

A.violation[msg] { not input.request.object.spec.securityContext.runAsNonRoot == true }
B.deny[msg] { input.request.object.spec.securityContext.runAsNonRoot == true }
C.allow[msg] { input.request.object.spec.securityContext.runAsNonRoot == false }
D.deny[msg] { input.request.object.spec.containers[_].securityContext.runAsNonRoot == true }
AnswerA

The violation rule is the only construct Gatekeeper's constraint framework evaluates for admission decisions. By using 'not input...runAsNonRoot == true', the expression is satisfied whenever the field is absent, undefined, or set to false — including pods that omit pod-level securityContext entirely — so every non-compliant pod is denied while explicitly compliant pods pass. This matches the intended policy exactly.

Why this answer

The Rego rule `violation[msg]` is the standard pattern for Gatekeeper ConstraintTemplates to deny a resource. The condition `not input.request.object.spec.securityContext.runAsNonRoot == true` triggers a violation when the field is missing or set to false, ensuring pods do not have `runAsNonRoot` set to true. This directly enforces the requirement to deny pods without the security context.

Exam trap

The CKS exam often tests the distinction between pod-level and container-level security contexts, and the trap here is that candidates may incorrectly use `deny[msg]` with a positive condition or check container-level fields instead of the pod-level `runAsNonRoot` field.

How to eliminate wrong answers

Option B is wrong because it uses `deny[msg]` with a condition that checks `runAsNonRoot == true`, which would deny pods that have it set correctly, the opposite of the requirement. Option C is wrong because it uses `allow[msg]`, which is not a valid Rego keyword in Gatekeeper; the correct pattern is `violation[msg]` or `deny[msg]`, and the condition `runAsNonRoot == false` would allow pods without the setting, failing to deny them. Option D is wrong because it checks `runAsNonRoot` only at the container level (`spec.containers[_].securityContext.runAsNonRoot`), but the requirement is to check the pod-level `spec.securityContext.runAsNonRoot`, and it also uses `deny[msg]` with a condition that would deny pods with the setting set to true.

Practice this question →
35
MCQeasy

Which kubectl command creates a validating webhook configuration that calls an external HTTPS endpoint for pod validation?

A.kubectl create admission webhook --validate
B.kubectl run webhook --image=...
C.kubectl apply -f webhook.yaml
D.kubectl create validatingwebhookconfiguration --url=https://...
AnswerC

`kubectl apply -f webhook.yaml` is the correct approach because ValidatingWebhookConfiguration is a declarative API resource defined in YAML. The manifest contains the essential fields: clientConfig (url or service reference and caBundle), rules, failurePolicy, and admissionReviewVersions. Running kubectl apply sends this manifest to the API server, which persists the configuration and immediately activates the webhook for matching requests. This is the only reliable way to create such cluster-scoped admission configurations.

Why this answer

`kubectl apply -f webhook.yaml` is the standard way to create any Kubernetes resource, including a ValidatingWebhookConfiguration, from a YAML manifest. The manifest defines the webhook's client configuration, including the external HTTPS endpoint, CA bundle, and rules for pod validation. There is no dedicated `kubectl create` subcommand for webhooks; the resource must be defined declaratively in a YAML file.

Exam trap

The trap here is that candidates assume there is a dedicated `kubectl create` subcommand for webhooks (like `kubectl create validatingwebhookconfiguration`), but Kubernetes requires webhooks to be defined declaratively via YAML/JSON, not imperatively with flags.

How to eliminate wrong answers

Option A is wrong because `kubectl create admission webhook --validate` is not a valid kubectl command; Kubernetes does not have a built-in `admission webhook` subcommand. Option B is wrong because `kubectl run webhook --image=...` creates a Pod, not a ValidatingWebhookConfiguration resource; it would run a container but not register any webhook with the API server. Option D is wrong because `kubectl create validatingwebhookconfiguration --url=https://...` is not a valid syntax; kubectl's `create` subcommand does not support inline `--url` flags for webhooks—the resource must be defined via a YAML file or JSON.

Practice this question →
36
Multi-Selectmedium

Which TWO of the following are secure practices for managing secrets in Kubernetes? (Select TWO.)

Select 2 answers
A.Store secrets as environment variables
B.Use a CSI driver to mount secrets as volumes
C.Embed secrets in container images
D.Use an external secrets manager like Vault with a sidecar
E.Store secrets in a ConfigMap
AnswersB, D

A CSI driver for secrets, such as the Secrets Store CSI Driver, mounts secrets as formatted files into the pod's filesystem, pulling them from external providers like Vault or AWS Secrets Manager at runtime. This avoids storing sensitive data in Kubernetes etcd, enables secrets to be rotated without restarting pods, and keeps secrets out of environment variables and container images, significantly reducing exposure.

Why this answer

The CSI (Container Storage Interface) driver for secrets allows secrets to be mounted as volumes without storing them in etcd or exposing them in environment variables. This approach leverages the CSI driver's ability to fetch secrets from external providers (e.g., HashiCorp Vault) on-demand, ensuring secrets are never persisted in Kubernetes objects and reducing the attack surface. It also supports rotation without pod restarts, as the volume content can be updated dynamically.

Exam trap

A common trap in Kubernetes exams is the misconception that storing secrets as environment variables is secure because they are 'in-memory'. However, environment variables are easily exposed through pod logs, exec commands, and /proc, making them less secure than volume mounts with proper access controls.

Practice this question →
37
MCQhard

You have a Pod that uses a ServiceAccount token mounted via a projected volume. You want to ensure that the token has an expiration time and that the pod is not using a long-lived token. What is the most secure way to mount the token?

A.Mount the default service account token at /var/run/secrets/kubernetes.io/serviceaccount
B.Use a projected volume with 'serviceAccountToken' and set 'expirationSeconds'
C.Set automountServiceAccountToken: false and manually mount a Secret containing a token
D.Use a ConfigMap to inject the token
AnswerB

A projected volume with a serviceAccountToken source and expirationSeconds issues a short-lived, audience-bound token that the kubelet rotates automatically, satisfying the requirement that the pod not rely on a long-lived legacy token. Plain secret mounts or automountServiceAccountToken alone cannot enforce expiry.

Why this answer

Using a projected volume with `serviceAccountToken` and setting `expirationSeconds` allows you to explicitly control the token's lifetime, ensuring it is short-lived and automatically rotated. This is the most secure approach as it prevents the use of long-lived tokens that could be compromised. The default service account token is a long-lived token with no expiration, which violates the principle of minimizing credential exposure.

Exam trap

This exam often tests the misconception that the default service account token is secure because it is automatically mounted, but the trap is that it is a long-lived token with no expiration, whereas the projected volume with `expirationSeconds` provides a short-lived, automatically rotated token that aligns with security best practices.

How to eliminate wrong answers

Option A is wrong because mounting the default service account token at /var/run/secrets/kubernetes.io/serviceaccount provides a long-lived token that does not expire, increasing the risk of credential misuse. Option C is wrong because setting `automountServiceAccountToken: false` and manually mounting a Secret containing a token still uses a static, long-lived token stored in a Secret, which lacks automatic rotation and expiration. Option D is wrong because a ConfigMap is used for non-sensitive configuration data and cannot inject a ServiceAccount token; tokens are sensitive credentials and must be handled via Secrets or projected volumes.

Practice this question →
38
MCQmedium

Which of the following is the correct kubectl command to view the OPA Gatekeeper ConstraintTemplates in the cluster?

A.kubectl get gatekeeper-constrainttemplates
B.kubectl describe opa constrainttemplate
C.kubectl get constrainttemplates
D.kubectl get crd -o name | grep constraint
AnswerC

This is the correct command because 'constrainttemplates' is the exact plural name of the custom resource served by the Kubernetes API after Gatekeeper's CRD is installed. kubectl get constrainttemplates works without specifying a namespace because these resources are cluster-scoped, and it directly returns the actual instances of the ConstraintTemplate custom resource, not just the CRD definition. It leverages the standard dynamic API discovery mechanism, so no additional flags or 'opa' references are required.

Why this answer

OPA Gatekeeper registers its constraints as custom resources in Kubernetes, and the standard `kubectl get constrainttemplates` command retrieves all ConstraintTemplate resources from the cluster. This works because Gatekeeper uses the Kubernetes API aggregation layer, making ConstraintTemplates a top-level resource type that kubectl can query directly.

Exam trap

The trap here is that candidates may confuse the resource name (e.g., adding 'gatekeeper-' or 'opa' prefix) or think they need to query CRDs instead of the actual resource instances, when in fact Gatekeeper resources are standard Kubernetes custom resources accessible via their short names.

How to eliminate wrong answers

Option A is wrong because `kubectl get gatekeeper-constrainttemplates` is not a valid kubectl command; Gatekeeper resources are accessed via their short name `constrainttemplates`, not with a hyphenated prefix. Option B is wrong because `kubectl describe opa constrainttemplate` uses an incorrect resource name (`opa` is not a valid resource type) and the wrong verb for listing; `describe` is for a specific resource instance, not for listing all templates. Option D is wrong because while `kubectl get crd -o name | grep constraint` would list CRD names containing 'constraint', it does not directly list the ConstraintTemplate instances themselves—only the CRD definitions, which is an indirect and incomplete approach.

Practice this question →
39
MCQhard

You are using Open Policy Agent (OPA) Gatekeeper to enforce pod security. You want to create a constraint that denies pods unless they have readOnlyRootFilesystem set to true. Which Rego rule in a ConstraintTemplate correctly implements this?

A.violation[{"msg": msg}] { container := input.review.object.spec.containers[_] container.securityContext.readOnlyRootFilesystem == true msg := "readOnlyRootFilesystem must be true" }
B.violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not container.securityContext.readOnlyRootFilesystem msg := "readOnlyRootFilesystem must be true" }
C.violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not container.securityContext.readOnlyRootFilesystem == false msg := "readOnlyRootFilesystem must be true" }
D.violation[{"msg": msg}] { container := input.review.object.spec.containers[_] container.securityContext.readOnlyRootFilesystem == false msg := "readOnlyRootFilesystem must be true" }
AnswerB

This is the correct implementation because `not container.securityContext.readOnlyRootFilesystem` succeeds when the field is either absent (undefined) or explicitly `false`, exactly the non-compliant cases. In Rego, `not` on an undefined reference returns true, so a pod that omits `securityContext` or sets the key to `false` is caught. Conversely, a container with `readOnlyRootFilesystem: true` makes the inner expression true, so `not` fails and no violation is generated.

Why this answer

It uses `not container.securityContext.readOnlyRootFilesystem` to trigger a violation when the field is missing, false, or nil. In Rego, `not` succeeds when the expression inside it fails, so this rule denies any pod where any container does not have `readOnlyRootFilesystem` explicitly set to `true`. This matches the requirement to deny pods unless the field is `true`.

Exam trap

CNCF often tests the nuance that `not` in Rego catches both `false` and undefined values, whereas an explicit `== false` check misses undefined fields — a common pitfall for candidates who think only explicit `false` values should be denied.

How to eliminate wrong answers

Option A is wrong because it creates a violation when `readOnlyRootFilesystem == true`, which would deny pods that are actually compliant — the opposite of the requirement. Option C is wrong because `not container.securityContext.readOnlyRootFilesystem == false` is a double negative that evaluates to true when the field is `true` or missing, but it fails to catch cases where the field is explicitly `false` (since `false == false` is true, `not` makes it false, so no violation). Option D is wrong because it only denies pods where `readOnlyRootFilesystem == false`, but it misses pods where the field is missing entirely (nil), which should also be denied.

Practice this question →
40
MCQeasy

Which of the following is a characteristic of Kata Containers compared to gVisor?

A.Kata Containers require no additional configuration in Kubernetes
B.Kata Containers have lower overhead than gVisor
C.Kata Containers use lightweight VMs to isolate containers
D.Kata Containers provide a user-space kernel that intercepts system calls
AnswerC

Kata Containers use lightweight virtual machines to isolate containers, providing a hardware-level security boundary. Each container or pod runs inside its own VM, using a guest kernel and hardware virtualization (e.g., via QEMU, Cloud Hypervisor, or Firecracker), while still offering container interfaces like OCI. This design delivers stronger isolation than standard runc or even gVisor, because a separate kernel and hardware virtualization protect against many host-validating side channels. This is precisely the defining characteristic of Kata Containers.

Why this answer

Kata Containers use lightweight virtual machines (VMs) to provide strong hardware-enforced isolation for containers. Each container runs inside its own minimal VM with a separate kernel, offering security comparable to a VM while maintaining container-like performance and orchestration. This is the defining characteristic that distinguishes Kata Containers from gVisor.

Exam trap

The trap here is that candidates confuse gVisor's user-space kernel approach (system call interception) with Kata Containers' hardware virtualization, leading them to select option D, which accurately describes gVisor but not Kata Containers.

How to eliminate wrong answers

Option A is wrong because Kata Containers require additional configuration in Kubernetes, such as installing the Kata runtime handler and configuring a RuntimeClass in the cluster. Option B is wrong because Kata Containers have higher overhead than gVisor due to the full VM and separate kernel per container, whereas gVisor intercepts system calls in user space with lower resource consumption. Option D is wrong because it describes gVisor's architecture (a user-space kernel that intercepts system calls), not Kata Containers, which use hardware virtualization.

Practice this question →
41
MCQeasy

A DevOps engineer wants to ensure that all microservice containers run with a read-only root filesystem to prevent unauthorized writes. What is the simplest way to enforce this at the Pod level?

A.Set `securityContext.runAsNonRoot: true` in the Pod spec
B.Mount an emptyDir volume to the container's writable directories
C.Set `securityContext.readOnlyRootFilesystem: true` in the Pod spec
D.Set `securityContext.privileged: false` in the Pod spec
AnswerC

Setting readOnlyRootFilesystem: true instructs the container runtime to mount the container's root filesystem as read-only, so no process can create, delete, or modify files in the root layer. This is the precise securityContext field that the requirement asks for, and it works regardless of the UID the container runs as. Any process that needs to write temporary data must have explicit writable volumes, such as emptyDir, mounted over required paths.

Why this answer

Setting `securityContext.readOnlyRootFilesystem: true` in the Pod spec directly enforces that the container's root filesystem is read-only, preventing any unauthorized writes to the root filesystem. This is the simplest and most direct way to achieve the requirement at the Pod level, as it applies to all containers in the Pod unless overridden at the container level.

Exam trap

CNCF often tests the distinction between security contexts that control user identity (runAsNonRoot) versus those that control filesystem permissions (readOnlyRootFilesystem), and the trap here is that candidates may confuse 'non-root' with 'read-only' or assume that disabling privileged mode is sufficient to prevent writes.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot: true` only ensures the container runs as a non-root user, but does not restrict writes to the root filesystem; a non-root user can still write to writable directories. Option B is wrong because mounting an emptyDir volume to writable directories is a workaround to allow specific writes while keeping the root filesystem read-only, but it does not enforce the read-only root filesystem itself; the root filesystem remains writable unless explicitly set to read-only. Option D is wrong because `privileged: false` is the default and simply disables privileged mode, but it does not prevent writes to the root filesystem; a non-privileged container can still modify the root filesystem if it is not explicitly set to read-only.

Practice this question →
42
MCQmedium

In Kubernetes, you need to enforce a default deny-all network policy for pods in a specific namespace to ensure pods cannot communicate unless explicitly allowed by policy. Which resource should you create?

A.NetworkPolicy
B.ResourceQuota
C.LimitRange
D.RuntimeClass
AnswerA

A NetworkPolicy with an empty pod selector and both Ingress and Egress policyTypes set to deny enforces default deny-all for every pod in the namespace, satisfying the requirement that communication is blocked unless explicitly permitted. Kubernetes' native policy object operates at layer 3/4, matching the namespace-scoped constraint in the stem.

Why this answer

A NetworkPolicy is the Kubernetes resource that controls network traffic to and from pods. A default deny-all policy can be created by selecting all pods (e.g., using an empty podSelector) and omitting ingress/egress rules. ResourceQuota and LimitRange manage compute/resource usage, not network traffic, and RuntimeClass selects a container runtime configuration rather than enforcing network policy.

Exam trap

Candidates often confuse namespace-scoped controls: ResourceQuota and LimitRange limit resource consumption, while NetworkPolicy is the only one of these that enforces pod-to-pod network segmentation.

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 setting authentication or mTLS policies. Option C (ServiceEntry) is wrong because it is used to register external services (outside the mesh) into the service mesh, not to enforce mTLS within the mesh. Option D (DestinationRule) is wrong because while it can define traffic policies including TLS settings, it applies to specific host-level traffic rules, not to set a namespace-wide default mTLS mode; PeerAuthentication is the intended resource for this purpose.

Practice this question →
43
MCQmedium

A cluster administrator needs to run a workload that uses gVisor (runsc) for container sandboxing. Which Kubernetes resource is required to enable this?

A.RuntimeClass
B.PriorityClass
C.NetworkPolicy
D.PodSecurityPolicy
AnswerA

RuntimeClass is a cluster-level resource that defines a handler (e.g., 'runsc' or 'gvisor') that the Kubernetes node's CRI runtime should use to launch the pod. A pod can reference a RuntimeClass via `spec.runtimeClassName`, and the kubelet then passes the handler to the runtime (like containerd) to run the container with that specific runtime engine. This is precisely how gVisor is selected, since multiple runtimes can be installed on the same node and chosen per-pod. Importantly, the RuntimeClass must be created by an administrator, and the handler must match a runtime configured on the node.

Why this answer

A RuntimeClass resource is required to enable gVisor (runsc) because it defines the container runtime configuration that should be used for pods. By creating a RuntimeClass with the handler set to 'runsc', the cluster administrator can instruct the kubelet to use gVisor as the OCI-compatible runtime for sandboxing, providing an additional security layer through a user-space kernel.

Exam trap

The trap here is that candidates confuse RuntimeClass with PodSecurityPolicy or PriorityClass, thinking that sandboxing is enforced through security policies or scheduling priorities, rather than understanding that RuntimeClass is the explicit Kubernetes resource for selecting a different container runtime per pod.

How to eliminate wrong answers

Option B (PriorityClass) is wrong because it manages pod scheduling priority and preemption, not container runtime selection. Option C (NetworkPolicy) is wrong because it controls network traffic rules between pods, not the underlying container runtime or sandboxing mechanism. Option D (PodSecurityPolicy) is wrong because it enforces security constraints on pod specifications (e.g., privileged containers, host namespaces), but does not configure which OCI runtime (like runsc) is used to run the containers.

Practice this question →
44
MCQmedium

Which of the following commands creates a ValidatingWebhookConfiguration that uses an OPA Gatekeeper webhook?

A.kubectl apply -f validatingwebhook.yaml where the webhook's service reference points to the gatekeeper-validating-webhook service.
B.kubectl apply -f constraint.yaml with a ConstraintTemplate.
C.kubectl create validatingwebhook gatekeeper --from-file=webhook.yaml
D.kubectl run gatekeeper-webhook --image=openpolicyagent/gatekeeper:v3.14.0
AnswerA

This is correct because Gatekeeper's admission webhook is implemented as a Kubernetes ValidatingWebhookConfiguration, which is a cluster-scoped API object created declaratively with kubectl apply. The configuration references the gatekeeper-validating-webhook service by name and namespace, telling the API server to forward matching admission requests to that service's HTTPS endpoint. Applying the YAML file registers the webhook with the API server, enabling policy enforcement during pod creation and updates.

Why this answer

A ValidatingWebhookConfiguration in Kubernetes must reference a service that handles the admission review request. OPA Gatekeeper exposes its webhook via the `gatekeeper-validating-webhook` service, which listens for `AdmissionReview` requests on the `/v1/admit` endpoint. Applying a YAML manifest that correctly specifies this service reference in the `clientConfig.service` field creates the necessary webhook configuration to integrate Gatekeeper.

Exam trap

This exam often tests the distinction between creating the Kubernetes resource that registers the webhook (ValidatingWebhookConfiguration) versus deploying the webhook server itself (Pod/Deployment), and candidates mistakenly think running the Gatekeeper container alone is sufficient to enable admission control.

How to eliminate wrong answers

Option B is wrong because `kubectl apply -f constraint.yaml` with a `ConstraintTemplate` creates a Gatekeeper constraint or template, not a ValidatingWebhookConfiguration; the webhook configuration must be created separately to register the external admission webhook with the API server. Option C is wrong because `kubectl create validatingwebhook gatekeeper --from-file=webhook.yaml` is not a valid kubectl command; kubectl does not have a `validatingwebhook` subcommand, and ValidatingWebhookConfigurations are created via `kubectl apply` or `kubectl create -f` with a YAML file. Option D is wrong because `kubectl run gatekeeper-webhook --image=openpolicyagent/gatekeeper:v3.14.0` only deploys a Pod running the Gatekeeper container, but does not create the ValidatingWebhookConfiguration resource that registers the webhook with the API server; without that registration, the API server will not forward admission requests to the Gatekeeper service.

Practice this question →
45
MCQhard

To encrypt secrets at rest in Kubernetes, an administrator configures an EncryptionConfiguration. What is the correct flag to pass to the kube-apiserver to use this configuration?

A.--encryption-provider-config=/path/to/config.yaml
B.--feature-gates=EncryptionAtRest=true
C.--encryption-key=/path/to/config.yaml
D.--encryption-config=/path/to/config.yaml
AnswerA

The `--encryption-provider-config` flag points the kube-apiserver to an EncryptionConfiguration YAML file that defines which providers (like `aescbc`, `aesgcm`, or `secretbox`) to use for encrypting Secrets and other resources at rest. The file also holds the actual encryption keys under each provider and specifies the order in which providers are attempted for throttling and decryption. Without this flag, Kubernetes stores Secrets in etcd as plaintext, so this is the standard way to enable encryption.

Why this answer

The `--encryption-provider-config` flag is the exact command-line option that the kube-apiserver expects to locate the EncryptionConfiguration YAML file. This flag tells the API server to read the configuration that defines which encryption providers (e.g., `aescbc`, `secretbox`) to use for encrypting Kubernetes secrets at rest in etcd.

Exam trap

The trap here is that candidates may confuse the flag name with similar-sounding options like `--encryption-config` or `--encryption-key`, or mistakenly think encryption at rest is enabled via a Kubernetes feature gate (`--feature-gates=EncryptionAtRest=true`). In reality, Kubernetes secret encryption at rest requires an EncryptionConfiguration YAML file specified via the `--encryption-provider-config` flag on the kube-apiserver. The feature gate approach is not valid; the correct mechanism is the dedicated configuration file and flag.

How to eliminate wrong answers

Option B is wrong because `--feature-gates=EncryptionAtRest=true` is not a valid flag; encryption at rest is enabled by providing an EncryptionConfiguration, not by a feature gate. Option C is wrong because `--encryption-key` is not a recognized kube-apiserver flag; encryption keys are specified inside the EncryptionConfiguration file, not passed directly as a command-line argument. Option D is wrong because `--encryption-config` is not the correct flag name; the correct flag is `--encryption-provider-config`.

Practice this question →
46
MCQhard

An admin creates the following EncryptionConfiguration to encrypt secrets at rest. After applying it, what must the admin do to ensure existing secrets are encrypted?

A.Re-create the existing secrets
B.Restart the kube-apiserver
C.Delete the existing secrets and wait for them to be recreated automatically
D.Nothing, the existing secrets are automatically encrypted
AnswerA

Existing secrets are stored in etcd with the identity provider (plaintext) until they are rewritten. Enabling an encryption provider in the EncryptionConfiguration only affects future write operations; the kube-apiserver does not retroactively scan or encrypt existing entries. To force encryption, you must re-create each secret (e.g., via kubectl get secret -o yaml | kubectl replace -f -) so the apiserver writes the new record using the configured encryption provider.

Why this answer

When an EncryptionConfiguration is applied to encrypt secrets at rest, the kube-apiserver uses the configured encryption provider to encrypt new or updated secrets as they are written to etcd. However, existing secrets that were stored in plaintext before the configuration was applied remain unencrypted in etcd. To ensure these existing secrets are encrypted, the admin must re-create them (e.g., by deleting and recreating them or using `kubectl get secret -o yaml | kubectl replace -f -`), which triggers a write to etcd through the encryption provider.

Exam trap

A common misconception is that applying an EncryptionConfiguration automatically encrypts all existing data, but the trap here is that encryption at rest only applies to new or updated writes, not to data already stored in etcd.

How to eliminate wrong answers

Option B is wrong because restarting the kube-apiserver does not re-encrypt existing secrets; it only loads the new EncryptionConfiguration for future writes. Option C is wrong because deleting existing secrets does not cause them to be automatically recreated; Kubernetes does not regenerate deleted secrets unless they are managed by a controller (e.g., ServiceAccount token secrets), and even then, the new secret would be encrypted, but the original data is lost. Option D is wrong because existing secrets are not automatically encrypted; the EncryptionConfiguration only applies to data written after it is active, so previously stored plaintext secrets remain unencrypted until they are rewritten.

Practice this question →
47
MCQeasy

An admin runs 'kubectl get pod web -o yaml' and sees the following security context. Which setting prevents privilege escalation?

A.allowPrivilegeEscalation: false
B.Both B and C
C.runAsNonRoot: true
D.capabilities: drop: [ALL]
AnswerA

Setting allowPrivilegeEscalation to false blocks the container process from gaining more privileges than its parent, disabling setuid binaries and preventing escalation via no_new_privs. This directly satisfies the stem's requirement to identify the setting that stops privilege escalation.

Why this answer

`allowPrivilegeEscalation: false` directly prevents a process from gaining more privileges than its parent process, such as through setuid binaries or gaining root capabilities. This setting is enforced by the kernel via the `no_new_privs` flag, which blocks privilege escalation attempts regardless of other security context settings.

Exam trap

A common misconception is that dropping all capabilities or running as non-root alone prevents privilege escalation, but the kernel's `no_new_privs` flag (set by `allowPrivilegeEscalation: false`) is the only direct control against setuid-based escalation.

How to eliminate wrong answers

Option B is wrong because it claims both B and C are correct, but only A directly prevents privilege escalation; `runAsNonRoot: true` ensures the container does not run as root but does not block privilege escalation if the container later gains root capabilities. Option C is wrong because `runAsNonRoot: true` only enforces that the container's user is not UID 0; it does not prevent the process from escalating privileges via setuid binaries or capability grants. Option D is wrong because dropping all capabilities removes many privileges but does not prevent privilege escalation—a process could still use setuid binaries or other mechanisms to gain root if `allowPrivilegeEscalation` is not set to false.

Practice this question →
48
MCQeasy

Which field in a Pod's securityContext prevents privilege escalation by the container?

A.capabilities.add: ["SYS_ADMIN"]
B.runAsNonRoot
C.allowPrivilegeEscalation
D.privileged
AnswerC

This field is the direct and intended control for privilege escalation. Setting allowPrivilegeEscalation: false applies the Linux no_new_privs attribute to all processes in the container, which prevents them from gaining more privileges than their parent process, including setuid/setgid executions and file capability acquisition. It is a runtime security feature that blocks the actual mechanism of privilege escalation, making it the correct answer. Without this setting, a container running as a non-root user may still escalate to root via a setuid binary.

Why this answer

`allowPrivilegeEscalation` controls whether a process can gain more privileges than its parent process. In a Pod's securityContext, setting this field to `false` prevents the container from performing privilege escalation, such as via setuid binaries or system calls like `setuid(0)`. This directly mitigates a common attack vector where an attacker exploits a container process to gain root access.

Exam trap

CNCF often tests this by having candidates confuse `allowPrivilegeEscalation` with `runAsNonRoot`, where the trap is that `runAsNonRoot` only sets the initial user but does not block subsequent privilege escalation via setuid binaries or capability-based syscalls.

How to eliminate wrong answers

Option A is wrong because `capabilities.add: ["SYS_ADMIN"]` grants the SYS_ADMIN capability, which itself allows many privileged operations, but it does not control or prevent privilege escalation; in fact, it can enable it. Option B is wrong because `runAsNonRoot` ensures the container runs as a non-root user but does not prevent the container from escalating privileges (e.g., via a setuid binary) if the binary is owned by root and the container has the necessary capabilities. Option D is wrong because `privileged: true` disables all security constraints and inherently allows privilege escalation; it is the opposite of preventing it.

Practice this question →
49
MCQhard

A pod fails to start with the error 'Container runtime network not ready', and the node uses Kata Containers (RuntimeClass: kata). What is the most likely cause?

A.The node has insufficient memory
B.The pod is trying to mount a hostPath volume
C.The CNI plugin is not configured correctly for the kata RuntimeClass
D.The pod's securityContext sets runAsNonRoot: true
AnswerC

Kata Containers runs each pod inside a lightweight VM, so CNI must do more than create a veth pair in the host namespace: it must set up a virtual network interface (e.g., TAP or virtio-net) that connects the guest VM to the host's network infrastructure. If the CNI plugin in use is not compatible with Kata's VM-based model — for example, a plugin that assumes the container's network namespace is a regular host netns — the plugin's ADD command may fail or return before the VM's network interface is ready. This causes the containerd/kubelet sandbox creation to fail with a network not ready error, exactly as described in the scenario.

Why this answer

Kata Containers use lightweight VMs for pod isolation, which require a separate CNI plugin (e.g., flannel, calico) to be configured specifically for the kata RuntimeClass. The error 'Container runtime network not ready' indicates that the CNI plugin is either missing, misconfigured, or not compatible with the kata runtime, preventing the pod's network namespace from being set up.

Exam trap

Candidates often overlook the need for RuntimeClass-specific CNI configuration when using Kata Containers, assuming that the network error is always due to a cluster-wide CNI issue.

How to eliminate wrong answers

Option A is wrong because insufficient memory would typically cause an OOMKill or pod eviction, not a network readiness error. Option B is wrong because hostPath volume mounts do not affect the container runtime's network initialization; they are handled by the kubelet after the pod is scheduled. Option D is wrong because runAsNonRoot: true is a security context setting that enforces user ID restrictions, but it does not impact the container runtime's network setup or CNI plugin configuration.

Practice this question →
50
Multi-Selectmedium

Which TWO actions help minimize vulnerabilities in microservices by securing secrets? (Choose two)

Select 2 answers
A.Base64 encode the secret in the YAML manifest
B.Set the secret as a label on the pod
C.Mount Secrets as volumes instead of environment variables
D.Use an external secrets manager like HashiCorp Vault
E.Store secrets in ConfigMaps to leverage ConfigMap encryption
AnswersC, D

Mounting a Secret as a volume (e.g., in /var/secrets) keeps the secret data out of the container's environment variables, which are exposed through /proc/<pid>/environ and can be inherited by child processes or captured in debug output. A mounted file also lets you set restrictive file permissions (e.g., 0400) and, with projected volumes or subPath, can be updated without restarting the container. However, this only mitigates runtime exposure; the Secret is still stored in etcd and should be protected with encryption at rest.

Why this answer

Mounting secrets as volumes is more secure than using environment variables. When secrets are injected as environment variables, they can be exposed through the process environment (e.g., via `/proc/self/environ` or `env` command) and are more likely to be accidentally logged or leaked. Mounting as a volume ensures the secret is only available as a file in the container's filesystem, and the secret data is not visible in the process list or environment dumps, reducing the attack surface.

Exam trap

The exam often tests the misconception that Base64 encoding is a form of security, or that storing secrets in ConfigMaps is acceptable because ConfigMaps can be encrypted, but the exam expects you to know that ConfigMaps are for non-sensitive data and that external secrets managers or volume mounts are the correct approaches for secret management.

Practice this question →
51
Drag & Dropmedium

Order the steps to configure and apply a NetworkPolicy to restrict pod-to-pod traffic.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

NetworkPolicy must be created and applied, then tested by deploying pods and checking connectivity. The policy is enforced immediately.

Practice this question →
52
Multi-Selectmedium

Which ONE of the following is a valid method to restrict a container's filesystem to read-only in Kubernetes?

Select 1 answer
A.Use a ConfigMap volume with defaultMode 0444
B.Set readOnly: true on a hostPath volume mount
C.Set readOnlyRootFilesystem: true in the container's securityContext
D.Mount an emptyDir volume with readOnly: true
AnswersC

Setting readOnlyRootFilesystem: true in the container's securityContext causes the entire root filesystem of the container to be mounted read-only, so any attempt to write to filesystem paths that are part of the image or container layer will fail. This is the standard, recognized method to enforce a read-only container filesystem, because it applies globally to the container's base filesystem rather than to a specific volume. Note that this does not affect volumes that are explicitly mounted; each volume still needs to be explicitly marked readOnly if that is desired.

Why this answer

The only valid method listed. Setting `readOnlyRootFilesystem: true` in the container's securityContext directly makes the container's root filesystem read-only. Options A, B, and D only make specific volumes read-only (ConfigMap, hostPath, emptyDir), but do not prevent writes to the container's own filesystem (e.g., /etc, /tmp, /var).

Therefore, only option C correctly restricts the container's filesystem to read-only.

Exam trap

In the CKS exam, the distinction between making a specific volume read-only (e.g., via `readOnly: true` on a mount) versus making the entire container's root filesystem read-only via `readOnlyRootFilesystem` is often tested. Candidates mistakenly think that setting `readOnly: true` on any volume achieves the same effect.

Practice this question →
53
MCQhard

An admin has created an EncryptionConfiguration to encrypt secrets at rest in etcd. After applying the configuration and restarting the kube-apiserver, existing secrets are still stored in plaintext. What is the most likely reason?

A.The encryption provider is set to 'identity' which does not encrypt
B.The kube-apiserver was not restarted after applying the configuration
C.Existing secrets are not automatically encrypted; they need to be rewritten by reading and writing them back
D.The EncryptionConfiguration has a syntax error that caused it to be ignored
AnswerC

This is the correct answer. When a new EncryptionConfiguration becomes active, the API server only encrypts objects that are written to etcd after that point; any objects that already exist in etcd remain in their original unencrypted form until they are modified. To encrypt existing secrets, they must be rewritten by reading them and then performing a write operation, such as `kubectl get secret -o yaml | kubectl replace -f -` or by deleting and recreating them. The API server does not automatically backfill encryption for pre-existing data.

Why this answer

Kubernetes does not automatically encrypt existing secrets stored in etcd when an EncryptionConfiguration is applied. The encryption configuration only affects data written after the kube-apiserver is restarted; previously stored secrets remain in plaintext until they are read and rewritten (e.g., by running `kubectl get secret <name> -o yaml | kubectl replace -f -`). This behavior is by design, as the API server encrypts data on write, not retroactively.

Exam trap

The trap here is that candidates assume applying an EncryptionConfiguration and restarting the API server automatically encrypts all existing data, but Kubernetes only encrypts data on new writes, not retroactively.

How to eliminate wrong answers

Option A is wrong because the 'identity' provider does not encrypt, but the question states an EncryptionConfiguration was created to encrypt secrets, implying a non-identity provider (e.g., aesgcm or secretbox) was configured; if identity were used, no encryption would occur for new data either. Option B is wrong because the question explicitly states the kube-apiserver was restarted after applying the configuration, so the restart is not the issue. Option D is wrong because a syntax error in the EncryptionConfiguration would typically cause the kube-apiserver to fail to start or log an error, not silently ignore the configuration; the question implies the configuration was applied and the server restarted successfully.

Practice this question →
54
MCQmedium

A developer is deploying a pod that needs to access a sensitive database. The security team requires that the database credentials be stored in a Kubernetes Secret and mounted as a file, not exposed as environment variables. The credentials must be rotated without restarting the pod. Which volume type should be used?

A.A secret volume mounted as a file.
B.A projected volume combining the Secret with a downward API volume.
C.A hostPath volume pointing to a file on the node that contains the credentials.
D.An emptyDir volume populated by an init container that reads the Secret.
AnswerA

A secret volume mounts the Secret as files in the container. Kubernetes automatically updates the mounted files when the Secret is updated, without requiring a pod restart. This satisfies both requirements: credentials are not exposed as environment variables, and rotation is handled dynamically. The application can watch the file for changes and reload credentials.

Why this answer

A secret volume mounts Secret data as files and is automatically updated when the Secret is modified, allowing credential rotation without pod restarts. Environment variables are static and require a restart to update. Other volume types either do not provide automatic updates or introduce security risks.

Exam trap

The trap here is assuming that a projected volume is needed for automatic updates, when a plain secret volume already provides that behavior.

Practice this question →
55
MCQmedium

A DevOps team deploys a microservice that needs to access a third-party API using credentials stored in a Kubernetes Secret. The team wants to minimize the risk of credential exposure. Which approach best achieves this goal while following security best practices?

A.Store the credentials in a Secret and mount it as a volume with default permissions.
B.Store the credentials in a Secret, mount it as a read-only volume, and use a dedicated service account with RBAC limiting access to that secret.
C.Use a sidecar container that reads the secret from a file and exposes it via a Unix socket, running the container as root.
D.Store the credentials in a ConfigMap and inject them as environment variables.
AnswerB

This approach is correct because it combines confidentiality, integrity, and least privilege: mounting the Secret as a read-only volume prevents containers from modifying the credentials at runtime, while a dedicated ServiceAccount paired with a Role and RoleBinding strictly limits which pods can get or list the Secret through the Kubernetes API. The RBAC policy ensures that only the microservice's own service account can access the Secret, reducing the risk of unauthorized retrieval by other workloads in the cluster.

Why this answer

Mounting the Secret as a read-only volume prevents runtime modification, and using a dedicated service account with RBAC ensures only the specific microservice can access the Secret. This follows the principle of least privilege and minimizes exposure, as the credentials are never injected as environment variables (which can be leaked via /proc or logs) and are only available to the intended pod.

Exam trap

CNCF often tests the misconception that environment variables are safe for secrets, but the trap here is that environment variables can be exposed via `/proc/self/environ`, logs, or debug endpoints, making volume mounts with strict permissions and RBAC the more secure choice.

How to eliminate wrong answers

Option A is wrong because mounting a Secret with default permissions (typically 0644) allows other processes on the node to read the secret files, increasing exposure risk. Option C is wrong because running the sidecar container as root violates the principle of least privilege and could allow privilege escalation; a Unix socket approach adds complexity without addressing the core credential exposure issue. Option D is wrong because ConfigMaps are not designed for sensitive data—they lack encryption at rest and are often stored in plaintext in etcd, making credentials vulnerable to exposure.

Practice this question →
56
Multi-Selectmedium

Which TWO of the following are valid Pod Security Context settings to harden a container? (Select 2)

Select 2 answers
A.privileged: true
B.runAsUser: 0
C.runAsNonRoot: true
D.readOnlyRootFilesystem: true
E.allowPrivilegeEscalation: true
AnswersC, D

Setting `runAsNonRoot: true` enforces that the container process runs as a non-root user by rejecting the image's default user if it is root. This prevents the container from gaining root privileges inside the container, reducing the attack surface. It is a valuable security context setting recommended in Pod Security Standards.

Why this answer

Setting `runAsNonRoot: true` in the Pod Security Context forces the container to run with a user ID (UID) other than 0 (root). This is a fundamental hardening measure that prevents an attacker who gains code execution inside the container from having root privileges, thereby limiting the blast radius of a compromise. It is a recommended practice in the CIS Benchmark for Kubernetes and directly addresses the principle of least privilege.

Exam trap

A common misconception is that setting `runAsUser: 0` is a hardening measure because it 'specifies a user,' when in fact it sets the container to run as root, the most dangerous user.

Practice this question →
57
Multi-Selecthard

Which THREE of the following are valid approaches to enforce that all pods in a cluster run with a read-only root filesystem? (Select THREE)

Select 3 answers
A.Deploy a ValidatingWebhookConfiguration that checks for readOnlyRootFilesystem: true
B.Use a Gatekeeper policy to drop all capabilities
C.Enable Pod Security Admission (PSA) with the 'restricted' profile
D.Deploy a MutatingWebhookConfiguration that adds readOnlyRootFilesystem: true to all pods
E.Apply a NetworkPolicy that denies egress
AnswersA, C, D

A ValidatingWebhookConfiguration intercepts Pod create and update requests and can reject any pod that does not explicitly set readOnlyRootFilesystem: true in its container securityContext. This is a valid enforcement approach because the webhook runs as part of the admission chain and denies non-compliant resources before they are persisted in etcd, ensuring workloads never run with a writable root filesystem.

Why this answer

Option A is correct because a ValidatingWebhookConfiguration can intercept pod CREATE/UPDATE admission requests and reject any pod whose containers do not set securityContext.readOnlyRootFilesystem: true, thereby enforcing the requirement cluster-wide. Option C is correct because the Pod Security Admission 'restricted' profile mandates that every container sets securityContext.readOnlyRootFilesystem to true (among other hardening controls), so labeling namespaces with pod-security.kubernetes.io/enforce=restricted blocks non-compliant pods. Option D is correct because a MutatingWebhookConfiguration can patch incoming pod specs to inject readOnlyRootFilesystem: true into each container's securityContext, ensuring all admitted pods run with a read-only root filesystem.

Option B is not correct because a Gatekeeper policy that drops all capabilities addresses Linux capabilities, not the read-only root filesystem setting. Option E is not correct because a NetworkPolicy only controls pod ingress/egress traffic and has no effect on container filesystem mutability.

Exam trap

Candidates often confuse dropping capabilities with making the root filesystem read-only. Dropping capabilities limits kernel privileges but does not prevent writes to the filesystem; they are separate security contexts.

Practice this question →
58
Multi-Selectmedium

Which TWO of the following are valid Rego keywords used in OPA policies for Gatekeeper? (Select TWO)

Select 2 answers
A.violation
B.allow
C.input
D.data
E.deny
AnswersC, D

`input` is a reserved Rego symbol that refers to the complete input document passed to the query, e.g., an admission review request in Kubernetes. It is the root for all input data, accessed like `input.request.userInfo`. Because it is defined by the language as the root of the query input, it cannot be used as a regular rule name. That makes it a valid Rego keyword, parallel to `data`.

Why this answer

In Rego, `input` and `data` are reserved keywords. `input` refers to the incoming document (e.g., the admission review request in Gatekeeper), and `data` refers to the global data document containing external data. `deny` is not a keyword but a common rule name used to trigger denial; `violation` and `allow` are also custom rule names. Therefore, the correct answer is options C and D.

Exam trap

Gatekeeper often tests the distinction between Rego language keywords (like `input` and `data`) and common rule names (like `violation`, `allow`, `deny`) that are not part of the language specification. Candidates mistakenly treat custom rule names as keywords.

Practice this question →
59
MCQhard

You want to run a container with gVisor for sandboxing. After installing gVisor and creating a RuntimeClass named 'gvisor', which Pod configuration enables it?

A.Set spec.runtimeClassName: gvisor
B.Set spec.nodeSelector with 'gvisor: true'
C.Define an environment variable RUNTIME=gvisor in the container
D.Add an annotation 'container.runtime: gvisor' to the Pod
AnswerA

The Pod spec includes a runtimeClassName field that references a cluster-scoped RuntimeClass resource, which declares the handler (for gVisor, typically runsc) and may also include scheduling and overhead settings. When this field is set, the kubelet uses that handler to create the sandbox and containers, making it the only native, supported mechanism for per-Pod runtime selection. Without it, the default runtime such as runc is used, even if gVisor is installed on the node.

Why this answer

The `spec.runtimeClassName` field in a Pod spec is the standard Kubernetes mechanism to select a specific container runtime for that Pod. When a RuntimeClass named 'gvisor' is created, setting `spec.runtimeClassName: gvisor` instructs the kubelet to use the gVisor runtime (runsc) to run the Pod's containers, providing an additional sandboxing layer for security.

Exam trap

The trap is that candidates may mistakenly think that nodeSelector, environment variables, or annotations can select a runtime, but only spec.runtimeClassName directly references a RuntimeClass object. For gVisor, a CNCF sandbox project, the RuntimeClass must be created separately, and the Pod simply references it by name.

How to eliminate wrong answers

Option B is wrong because `spec.nodeSelector` is used to constrain which nodes a Pod can be scheduled on based on node labels, not to select a container runtime. Option C is wrong because environment variables have no effect on container runtime selection; they are passed to the container's process but do not influence the runtime used by the kubelet. Option D is wrong because annotations are metadata key-value pairs that do not affect runtime behavior; Kubernetes does not interpret an annotation like 'container.runtime: gvisor' to select a runtime.

Practice this question →
60
MCQeasy

A security engineer needs to ensure that all containers in a cluster run as non-root users. Which Pod Security Context field should be set to enforce this requirement?

A.runAsNonRoot: true
B.runAsUser: 1000
C.privileged: false
D.allowPrivilegeEscalation: false
AnswerA

The `runAsNonRoot: true` Pod security context setting forces Kubernetes to validate that the container image specifies a non-root user (e.g., via USER in the Dockerfile) or that a `runAsUser` value is explicitly set to a non-zero UID; if the image would run as UID 0, the Pod API request is rejected during admission, preventing the container from ever starting as root. This is the only option that directly enforces non-root execution at the container level, independent of the image's default behavior. It is the correct choice for the requirement to ensure all containers run as non-root.

Why this answer

Setting `runAsNonRoot: true` in the Pod Security Context explicitly instructs the container runtime to verify that the container's user ID is non-zero (i.e., not root). If the container image is configured to run as root (UID 0), the Pod will fail to start, enforcing the requirement that all containers run as non-root users.

Exam trap

The CKS exam often tests the distinction between setting a specific user ID (`runAsUser`) and enforcing a non-root check (`runAsNonRoot`), where candidates mistakenly think that specifying a non-zero UID alone guarantees the container is not running as root, ignoring that the image might still run as root if the UID is not set in the image.

How to eliminate wrong answers

Option B is wrong because `runAsUser: 1000` only sets the user ID to 1000 but does not prevent the container from running as root if the image is configured to run as root; the runtime will still run as UID 1000, but the check against root is not enforced. Option C is wrong because `privileged: false` only disables privileged mode (e.g., access to host devices) but does not enforce a non-root user; a container can still run as root without privileged mode. Option D is wrong because `allowPrivilegeEscalation: false` prevents processes from gaining more privileges than their parent (e.g., via setuid binaries) but does not require the container to start as a non-root user; it can still start as root and simply not escalate further.

Practice this question →
61
MCQhard

A cluster has EncryptionConfiguration with aescbc provider. After rotating the encryption key, what must be done to re-encrypt existing Secrets with the new key?

A.Delete and recreate all Secrets
B.Restart the API server
C.Run 'kubectl encrypt secrets --key new-key'
D.Use 'kubectl get secrets --all-namespaces -o yaml | kubectl replace -f -'
AnswerD

This command retrieves every Secret in all namespaces as YAML and pipes it to 'kubectl replace —f -', which submits an update request for each Secret. Because replace triggers a write, the API server reads the existing ciphertext from etcd, decrypts it with the old key, and re-encrypts it using the currently active encryption key (the first key in the aescbc provider's key list). This effectively migrates all existing Secrets to the new key without deleting them or losing data, making it the correct procedure for encrypting existing data with the new key.

Why this answer

After rotating the encryption key in the EncryptionConfiguration, existing Secrets are still encrypted with the old key. To re-encrypt them with the new key, you must read all Secrets and write them back using 'kubectl get secrets --all-namespaces -o yaml | kubectl replace -f -'. This triggers the API server to encrypt the data with the new key (the first provider in the list) during the write operation.

Exam trap

CNCF often tests the misconception that restarting the API server or deleting/recreating Secrets is sufficient for re-encryption, when in fact the only way to re-encrypt existing data is to read and write it back through the API server.

How to eliminate wrong answers

Option A is wrong because deleting and recreating Secrets would cause data loss and downtime; the correct approach is to re-encrypt in place without deletion. Option B is wrong because restarting the API server only loads the new EncryptionConfiguration but does not re-encrypt existing Secrets; they remain encrypted with the old key until rewritten. Option C is wrong because 'kubectl encrypt secrets --key new-key' is not a valid kubectl command; Kubernetes does not provide a built-in command to manually trigger re-encryption of individual resources.

Practice this question →
62
Multi-Selectmedium

Which TWO of the following are valid ways to enable mTLS between services in a service mesh (e.g., Istio)?

Select 2 answers
A.Creating a DestinationRule with a trafficPolicy that sets tls mode to ISTIO_MUTUAL
B.Creating a ServiceEntry for the destination service
C.Creating a NetworkPolicy that allows ingress on port 443
D.Creating a PeerAuthentication resource with mTLS mode set to STRICT
E.Creating an AuthorizationPolicy with DENY action
AnswersA, D

A DestinationRule applies client-side traffic policy, and when its trafficPolicy sets tls.mode to ISTIO_MUTUAL, the sending sidecar will present a client certificate and validate the server's certificate using the mesh CA. This explicitly enables mutual TLS for connections to the designated service, and it can also override a mesh-wide or namespace-wide mTLS mode for that specific host.

Why this answer

A DestinationRule with `trafficPolicy.tls.mode: ISTIO_MUTUAL` explicitly configures the client-side proxy (Envoy) to use mutual TLS when sending requests to the destination service. This is the standard Istio mechanism to enforce mTLS at the service-to-service communication level, ensuring both client and server certificates are exchanged and verified.

Exam trap

The trap here is that candidates often confuse AuthorizationPolicy or NetworkPolicy with mTLS configuration, but neither of those resources handles TLS encryption or certificate exchange — they only control authorization or network access at different layers.

Practice this question →
63
MCQmedium

What is the purpose of the `allowPrivilegeEscalation: false` setting in a container's security context?

A.It prevents the container from running as root.
B.It prevents processes from gaining additional privileges (e.g., via setuid).
C.It prevents the container from using host networking.
D.It prevents the container from accessing host devices.
AnswerB

When set to false, Kubernetes instructs the container runtime to apply the Linux no_new_privs attribute to all processes in the container. This prevents a process from gaining additional privileges through setuid/setgid binaries, file capabilities, or other mechanisms that would elevate its effective UID or grant new capabilities beyond those initially assigned. It is a cornerstone security control that contains a compromised process, ensuring it cannot escalate to a more privileged state within the container.

Why this answer

The `allowPrivilegeEscalation: false` setting in a container's security context directly controls whether processes within the container can gain more privileges than their parent process. This is achieved by dropping the `CAP_SETUID`, `CAP_SETGID`, and `CAP_SETPCAP` capabilities and, crucially, by setting the `no_new_privs` flag on the container's process, which prevents the use of setuid/setgid binaries and other privilege-escalation mechanisms. This is a core security control to mitigate container breakout via privilege escalation.

Exam trap

CNCF often tests the distinction between 'running as root' and 'privilege escalation' — candidates confuse `allowPrivilegeEscalation: false` with `runAsNonRoot: true`, but the former blocks the ability to gain new privileges regardless of the current user, while the latter only restricts the initial user ID.

How to eliminate wrong answers

Option A is wrong because preventing the container from running as root is achieved by setting `runAsUser: 1000` or `runAsNonRoot: true`, not by `allowPrivilegeEscalation: false`. Option C is wrong because preventing the container from using host networking is controlled by the `hostNetwork: false` setting in the Pod spec, not by the security context's privilege escalation flag. Option D is wrong because preventing access to host devices is done via `privileged: false` and not adding host device mounts, not by the `allowPrivilegeEscalation` setting.

Practice this question →
64
MCQhard

You need to encrypt Secrets at rest in an existing Kubernetes cluster. You create an EncryptionConfiguration file specifying aescbc as the provider. After updating the API server kube-apiserver.yaml with the new configuration, you create a new Secret. Which of the following statements is true?

A.Only newly created secrets will be encrypted; existing secrets remain unencrypted.
B.The encryption key is automatically rotated every 30 days.
C.The aescbc provider can be changed to identity without any impact on existing secrets.
D.All existing secrets in the cluster are automatically encrypted after the API server restart.
AnswerA

Enabling the aescbc provider encrypts data written after the API server restarts with the new configuration. Secrets created beforehand remain stored in plaintext until they are rewritten, so existing secrets must be recreated or updated to gain encryption.

Why this answer

The EncryptionConfiguration only applies to data written to etcd after the API server is restarted with the new configuration. Existing Secrets that were stored in etcd before the restart remain in their original unencrypted form unless they are explicitly rewritten (e.g., by deleting and recreating them or using a tool like `kubectl get secret ... -o yaml | kubectl replace -f -`). The `aescbc` provider encrypts new data at rest, but does not retroactively encrypt existing data.

Exam trap

A common misconception is that restarting the API server with an EncryptionConfiguration retroactively encrypts existing data, but actually only new writes are encrypted.

How to eliminate wrong answers

Option B is wrong because key rotation is not automatic; the EncryptionConfiguration must be manually updated with a new key and the API server restarted to rotate keys, and there is no built-in 30-day rotation mechanism. Option C is wrong because changing the provider from `aescbc` to `identity` would cause the API server to read existing encrypted secrets as raw ciphertext (since `identity` does not decrypt), leading to data corruption or loss unless all secrets are first decrypted and rewritten using the old provider. Option D is wrong because existing secrets are not automatically encrypted; only newly created or updated secrets after the API server restart are encrypted.

Practice this question →
65
MCQhard

You are deploying a ValidatingWebhookConfiguration. The webhook server is running in the 'webhook' namespace, service name 'svc', port 443. Which clientConfig should you specify?

A.clientConfig: service: namespace: webhook name: svc path: /validate
B.clientConfig: url: https://webhook.svc.cluster.local:443/validate
C.clientConfig: service: namespace: webhook name: webhook path: /validate
D.clientConfig: service: namespace: default name: svc path: /validate
AnswerA

This is the correct configuration because the clientConfig.service block directly references the Service named `svc` in the `webhook` namespace, which is exactly where the webhook server is deployed. The API server will resolve this Service reference to a stable DNS name (`svc.webhook.svc.cluster.local`) and forward admission requests to the `path` `/validate` on that Service's HTTPS endpoint. Using the Service reference rather than a raw URL is the recommended Kubernetes pattern because it lets the API server automatically account for the Service's ClusterIP and the configured CA bundle.

Why this answer

A ValidatingWebhookConfiguration's clientConfig must reference the Kubernetes service that fronts the webhook server, specifying the service's namespace, name, and the path to the validation endpoint. Since the webhook server runs in the 'webhook' namespace with service name 'svc' on port 443, the service reference must use namespace: webhook and name: svc, with path: /validate. Kubernetes automatically resolves the service to its cluster-internal DNS name and uses the service's HTTPS port (443) when a service reference is provided.

Exam trap

Common mistake: candidates may specify the wrong service name, using the webhook server's deployment name or pod name instead of the actual service name, or they may omit the 'path' field. Also, the namespace must match the service's namespace, not the default namespace.

How to eliminate wrong answers

Option B is wrong because while a raw URL can be used, it is not the recommended or typical approach for in-cluster webhooks; the service reference is preferred for automatic DNS resolution and port handling, and the URL format shown does not match the standard cluster DNS pattern (which would be svc.webhook.svc.cluster.local). Option C is wrong because it incorrectly specifies the service name as 'webhook' instead of 'svc', which would cause the API server to fail to reach the webhook server. Option D is wrong because it sets the namespace to 'default' instead of 'webhook', so the API server would look for the service in the wrong namespace and fail to connect.

Practice this question →
66
MCQeasy

Which kubectl command creates a valid webhook configuration that validates pods against a policy?

A.kubectl apply -f webhookconfiguration.yaml
B.kubectl apply -f podpreset.yaml
C.kubectl apply -f mutatingwebhookconfiguration.yaml
D.kubectl apply -f validatingwebhookconfiguration.yaml
AnswerD

ValidatingWebhookConfiguration is the correct resource type for registering validation webhooks, as it tells the API server which HTTP endpoint to call during admission and whether to allow or deny the request. When you apply a valid validatingwebhookconfiguration.yaml, the API server sends AdmissionReview objects to your configured webhook service and enforces the returned decisions. This is the idiomatic way to add custom validation logic to a cluster.

Why this answer

A ValidatingWebhookConfiguration is the Kubernetes resource that intercepts API server requests to validate resources (e.g., pods) against an external policy before they are persisted. The command `kubectl apply -f validatingwebhookconfiguration.yaml` creates this configuration, which triggers a webhook call to an admission webhook server that returns an admission review with an 'allowed' or 'denied' decision.

Exam trap

The trap here is that candidates confuse ValidatingWebhookConfiguration with MutatingWebhookConfiguration, or assume a generic 'webhookconfiguration.yaml' is valid, but the CKS exam specifically tests the distinction between validation and mutation in admission webhooks.

How to eliminate wrong answers

Option A is wrong because 'webhookconfiguration.yaml' is not a standard Kubernetes API resource; the correct resource types are ValidatingWebhookConfiguration or MutatingWebhookConfiguration. Option B is wrong because PodPreset is a deprecated alpha resource that injects information into pods at creation time, not a webhook configuration for validating pods against a policy. Option C is wrong because a MutatingWebhookConfiguration is used for mutating (modifying) resources, not for validating them; validation requires a ValidatingWebhookConfiguration.

Practice this question →
67
Multi-Selecthard

Which THREE of the following are required to configure encryption of secrets at rest in Kubernetes?

Select 3 answers
A.Specifying an encryption provider such as `aescbc` in the EncryptionConfiguration
B.An EncryptionConfiguration YAML file defining encryption providers and resources to encrypt
C.Running `kubectl get secrets --all-namespaces -o yaml | kubectl apply -f -` to rewrite existing secrets
D.Passing the `--encryption-provider-config` flag to the kube-apiserver
E.Modifying the etcd configuration to enable encryption at rest
AnswersA, B, D

Specifying an encryption provider such as `aescbc` in the EncryptionConfiguration is essential because the provider determines the cryptographic algorithm and key used to encrypt secrets at rest. `aescbc` uses AES-CBC with a 256-bit key and is the recommended provider for most clusters. Without a provider, the configuration is invalid and the API server cannot perform any encryption, so data would remain plaintext in etcd.

Why this answer

The `aescbc` encryption provider is one of the supported providers in Kubernetes for encrypting secrets at rest. Specifying it in the `EncryptionConfiguration` tells the kube-apiserver which encryption algorithm to use when writing data to etcd. Without a provider like `aescbc`, secrets are stored in plaintext in etcd.

Exam trap

A common misconception is that modifying etcd configuration directly enables encryption at rest, when in fact encryption is a kube-apiserver concern managed via the `--encryption-provider-config` flag and `EncryptionConfiguration` resource.

Practice this question →
68
MCQeasy

You are reviewing a pod specification that mounts a hostPath volume to /var/run/docker.sock. Which security risk does this present, and what is the recommended mitigation?

A.It allows the container to access the host's PID namespace; mitigate by setting hostPID: false.
B.It allows the container to control the Docker daemon, potentially leading to host compromise; mitigate by avoiding hostPath mounts to the Docker socket and using a least-privilege approach.
C.It allows the container to read only the Docker logs; mitigate by setting readOnly: true on the volume mount.
D.It exposes the host's network stack; mitigate by setting hostNetwork: false.
AnswerB

Mounting the Docker socket gives the container full control over the Docker daemon, which can be used to start privileged containers, access the host filesystem, and escalate to root on the node. The recommended mitigation is to avoid mounting the Docker socket and instead use a secure API or a dedicated sidecar with least privilege. This is a well-known container escape vector.

Why this answer

Mounting the Docker socket gives the container control over the Docker daemon, enabling container escapes and host compromise. The correct mitigation is to avoid such mounts and use least-privilege alternatives. Read-only flags, hostNetwork, and hostPID settings do not mitigate this specific risk.

Exam trap

The trap here is thinking that a readOnly volume mount or disabling hostNetwork/hostPID mitigates the Docker socket risk, when the socket itself grants full daemon control regardless of those settings.

Practice this question →
69
MCQmedium

You are configuring an Istio service mesh for mTLS between services. Which resource defines the TLS mode for traffic between services in a namespace?

A.PeerAuthentication
B.ServiceEntry
C.VirtualService
D.DestinationRule
AnswerA

PeerAuthentication is the Istio Custom Resource Definition (CRD) that directly defines the mTLS policy for workloads, either mesh-wide, per-namespace, or with a pod selector. Its mode field accepts STRICT, PERMISSIVE, or DISABLE, and STRICT tells the server sidecar to reject plaintext traffic and require a client certificate. This is the authoritative security policy for enforcing mutual TLS between internal services, so it is the correct resource for this task.

Why this answer

PeerAuthentication is the correct resource because it defines the TLS mode (e.g., STRICT, PERMISSIVE, DISABLE) for mTLS between services within a namespace in Istio. It enforces the authentication policy for workloads, ensuring that all traffic between them uses mutual TLS as specified. This directly controls the TLS mode for inter-service communication at the namespace or mesh level.

Exam trap

The trap here is that candidates often confuse DestinationRule with PeerAuthentication, thinking DestinationRule's 'tls' field controls mTLS mode, but DestinationRule only configures client-side TLS settings (e.g., SNI) for outbound traffic, not the server-side authentication policy that PeerAuthentication enforces.

How to eliminate wrong answers

Option B (ServiceEntry) is wrong because it is used to add external services to the mesh, not to define TLS modes for internal traffic between services. Option C (VirtualService) is wrong because it defines traffic routing rules (e.g., weight-based routing, retries) and does not set TLS authentication policies. Option D (DestinationRule) is wrong because it configures traffic policies like load balancing and connection pool settings, but the TLS mode for mTLS is specifically governed by PeerAuthentication, not DestinationRule.

Practice this question →
70
MCQmedium

You need to use gVisor as a container runtime for a set of workloads in the cluster. Which Kubernetes resource must be created to reference the runtime class?

A.Create a RuntimeClass resource with handler: runsc
B.Set the kubelet runtime flag --runtime-class=gvisor
C.Install a CRD for gVisor
D.Create a Pod with spec.runtimeClassName set to "gvisor"
AnswerA

A RuntimeClass resource names the runtime handler, here runsc, which the kubelet uses to run matching pods under gVisor. Creating it with handler: runsc registers the sandboxed runtime so pods can select it via runtimeClassName, satisfying the requirement.

Why this answer

In Kubernetes, a RuntimeClass resource is used to select a container runtime configuration, such as gVisor. The RuntimeClass must specify the handler field set to 'runsc', which is the gVisor runtime binary. This resource is then referenced by pods via the `runtimeClassName` field to enforce sandboxed isolation.

Exam trap

The trap here is that candidates confuse creating the RuntimeClass resource with simply setting a field on a Pod, forgetting that the RuntimeClass object must exist in the cluster first, and that gVisor does not require a CRD or kubelet flag.

How to eliminate wrong answers

Option B is wrong because `--runtime-class` is not a valid kubelet flag; the kubelet uses `--container-runtime` and `--container-runtime-endpoint` to configure runtimes, and runtime classes are defined as Kubernetes API objects, not kubelet flags. Option C is wrong because gVisor does not require a Custom Resource Definition (CRD); it uses the built-in RuntimeClass API resource, which is available in standard Kubernetes without CRDs. Option D is wrong because setting `spec.runtimeClassName` in a Pod spec references an existing RuntimeClass object; it does not create the RuntimeClass itself, which must exist beforehand.

Practice this question →
71
Multi-Selectmedium

Which TWO of the following are recommended practices for securing container images and runtime?

Select 2 answers
A.Set runAsNonRoot to true in securityContext
B.Run containers as root inside the container for easier management
C.Set readOnlyRootFilesystem to true in securityContext
D.Mount the docker socket inside the container for debugging
E.Use the latest tag for all images
AnswersA, C

Setting runAsNonRoot to true in the securityContext forces the container process to run with a non-zero UID, preventing it from having root privileges. This is a critical defense-in-depth control because even if container is compromised, the attacker cannot exploit root-level capabilities to escalate to the host. Kubernetes will also reject the pod if the image specifies USER root when admission policies enforce this setting.

Why this answer

Setting `runAsNonRoot: true` in the securityContext ensures that the container's entrypoint runs with a user ID other than 0 (root), reducing the risk of container escape if an attacker gains code execution. Setting `readOnlyRootFilesystem: true` makes the container's filesystem read-only, preventing attackers from modifying critical system files or binaries. Both are key hardening practices recommended by Kubernetes security best practices.

Exam trap

A common pitfall is thinking that running as root inside a container is safe due to namespace isolation. However, root inside a container still has dangerous capabilities (e.g., CAP_SYS_ADMIN) that can lead to container escape, especially without proper seccomp or AppArmor profiles. This is a critical concept for the CNCF Kubernetes Security Specialist exam.

Practice this question →
72
MCQmedium

A security admin wants to ensure all pods in a cluster drop ALL Linux capabilities. Which of the following YAML snippets should be added to a PodSecurityPolicy (assuming PSP is enabled) or a pod spec?

A.capabilities: drop: "ALL"
B.capabilities: drop: - "NET_RAW"
C.capabilities: add: ["ALL"]
D.capabilities: drop: ["ALL"]
AnswerD

Setting `capabilities.drop: ["ALL"]` inside the `securityContext` removes every Linux capability from the container's capability sets, leaving the process with no capabilities beyond those required for basic operation. This is a security best practice because it prevents many privilege-escalation attacks, including those that abuse a setuid binary or a capability retained by the runtime. The list form is mandatory; Kubernetes validates `drop` as an array of capability names, and `ALL` is the wildcard that clears the entire default set.

Why this answer

Dropping all Linux capabilities from a container is achieved by specifying `drop: ["ALL"]` in the PodSecurityPolicy or pod security context. This ensures the container runs with no capabilities, following the principle of least privilege. The correct syntax uses a YAML list (array) for the `drop` field, not a string.

Exam trap

The trap here is that candidates confuse the YAML syntax for dropping capabilities (must be a list) with a string value, or they think dropping a single capability like NET_RAW is sufficient to remove all capabilities. Also, note that PodSecurityPolicy is deprecated in Kubernetes 1.21 and removed in 1.25, so for newer clusters, use Pod Security Admission or a pod security context.

How to eliminate wrong answers

Option A is wrong because `drop: "ALL"` uses a string value instead of a list, which is invalid YAML syntax for the capabilities field; the Kubernetes API expects an array of strings. Option B is wrong because it only drops the `NET_RAW` capability, not all capabilities, leaving the container with other potentially dangerous capabilities. Option C is wrong because `add: ["ALL"]` adds all capabilities, which is the opposite of what the security admin wants and would grant maximum privileges.

Practice this question →
73
MCQeasy

Which of the following is the best practice for injecting secrets into a pod?

A.Storing secrets in container image layers
B.Using environment variables
C.Using ConfigMap for secrets
D.Injecting via volume mounts
AnswerD

Mounting secrets as files in a volume is safer because the sensitive data appears only as file contents at the specified mount path, not in environment variables. It allows per-pod filesystem permissions, like read-only and mode settings, and is easier to rotate, as a change to the Secret object will eventually update the mounted file without restarting the container.

Why this answer

Mounting secrets as volumes ensures that secret data is stored in the pod's filesystem as files, which are created in a tmpfs in-memory filesystem (ram-backed) and never written to disk. This approach also allows for automatic rotation of secret values when the Secret object is updated, without requiring a pod restart, and avoids exposing secrets in process listings or container logs.

Exam trap

Kubernetes often tests the misconception that environment variables are a safe way to inject secrets because they are 'in-memory,' but the trap here is that environment variables are visible in the process environment, can be leaked via `/proc`, and cannot be rotated without restarting the pod, making volume mounts the only secure and dynamic option.

How to eliminate wrong answers

Option A is wrong because storing secrets in container image layers makes them accessible to anyone with access to the image registry, and they persist in the image history even after deletion, violating the principle of least privilege. Option B is wrong because using environment variables for secrets exposes them in the pod's process environment, which can be read via /proc/self/environ or leaked in logs, and they cannot be dynamically updated without restarting the pod. Option C is wrong because ConfigMaps are designed for non-sensitive configuration data and do not support encryption at rest or in transit; using them for secrets would store data in plaintext in etcd and expose it to any user with access to the ConfigMap API.

Practice this question →
74
MCQeasy

Which kubectl command creates a secret named 'mysecret' from a file called 'credentials.json'?

A.kubectl create secret generic mysecret --from-file=credentials.json
B.kubectl apply -f credentials.json
C.kubectl create configmap mysecret --from-file=credentials.json
D.kubectl create secret tls mysecret --cert=credentials.json
AnswerA

The '--from-file' flag tells kubectl to read the file 'credentials.json' and use its filename as the key, with the file's raw contents as the value. Because the subcommand is 'generic', kubectl wraps this data in a Secret object and base64-encodes each value when storing it in etcd. This is the correct command for converting a single local file into a Secret.

Why this answer

`kubectl create secret generic` is the command to create a generic (opaque) secret from a file. The `--from-file` flag reads the contents of `credentials.json` and stores them as the secret's data, using the filename as the key by default. This is the standard method for injecting sensitive file-based data into a Kubernetes secret.

Exam trap

Kubernetes often tests the distinction between `kubectl create secret generic` and `kubectl create secret tls`, and the trap here is that candidates may confuse the `--from-file` flag (for generic secrets) with the `--cert`/`--key` flags (for TLS secrets) or mistakenly use `kubectl apply` on a raw data file instead of a manifest.

How to eliminate wrong answers

Option B is wrong because `kubectl apply -f credentials.json` expects a valid Kubernetes manifest (YAML/JSON) defining a resource, not a raw data file like `credentials.json`. Option C is wrong because `kubectl create configmap` creates a ConfigMap, not a Secret; ConfigMaps store non-sensitive data, while Secrets are base64-encoded and intended for sensitive information. Option D 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 generic JSON file.

Practice this question →
75
Multi-Selecthard

Which THREE of the following practices help protect microservice applications against supply chain attacks? (Choose three.)

Select 3 answers
A.Use images from any public registry for flexibility
B.Use minimal base images (e.g., distroless or scratch) to reduce attack surface
C.Always use the latest tag to get the most recent patches
D.Scan images for vulnerabilities using tools like Trivy or Clair
E.Enable image verification using digital signatures (e.g., Notary or Cosign)
AnswersB, D, E

Minimal images like distroless or scratch contain only the essential runtime dependencies, excluding shells, package managers, and superfluous utilities. This dramatically shrinks the attack surface available to an attacker who gains code execution, limiting exploitation capabilities and reducing the number of CVEs that can affect the image. Fewer components also mean fewer packages to monitor and patch in the base layer.

Why this answer

Using minimal base images like distroless or scratch significantly reduces the attack surface by eliminating unnecessary packages, libraries, and utilities that could contain vulnerabilities. This aligns with the principle of least functionality, as fewer components mean fewer potential entry points for an attacker to exploit in a supply chain attack.

Exam trap

CNCF often tests the misconception that using the latest tag is a safe practice for getting patches, when in fact it undermines supply chain security by breaking image immutability and reproducibility.

Practice this question →
Page 1 of 3 · 161 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Minimize Microservice Vulnerabilities questions.

Start 20-question session