CKS Minimize Microservice Vulnerabilities Practice Test 5 — 15 Questions

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Use etcdctl to read the secret directly from etcd and verify it is encrypted.. 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.

Answer

Run kubectl get secret -o yaml and check for an encryption annotation.

Answer

Use kubectl describe secret and look for 'Encrypted: true'.

Answer

Check the apiserver logs for encryption status messages.

Question 2

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

Accepted Answer

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

Answer

The pod runs a web server listening on port 8080.

Answer

The pod mounts a ConfigMap as a volume.

Answer

The pod uses a PersistentVolumeClaim for storage.

Question 3

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

Accepted Answer

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

Answer

Use environment variables to inject secrets directly.

Answer

Pass secrets via command-line arguments.

Answer

Hardcode the secret in the container image.

Question 4

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?

Accepted Answer

The CNI plugin is not configured correctly for the kata RuntimeClass. 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.

Answer

The node has insufficient memory

Answer

The pod is trying to mount a hostPath volume

Answer

The pod's securityContext sets runAsNonRoot: true

Question 5

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

Accepted Answer

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

Answer

securityContext: capabilities: remove: ['ALL']

Answer

securityContext: capabilities: []

Answer

securityContext: capabilities: add: []

Question 6

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

Accepted Answer

It prevents processes from gaining additional privileges (e.g., via setuid).. 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.

Answer

It prevents the container from running as root.

Answer

It prevents the container from using host networking.

Answer

It prevents the container from accessing host devices.

Question 7

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

Accepted Answer

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

Answer

Use environment variables from the pod spec referencing Secret keys.

Answer

Pass secrets as command-line arguments to the container.

Answer

Store secrets in ConfigMaps with base64 encoded data.

Question 8

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

Accepted Answer

Enforce that containers set runAsNonRoot: true.. 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.

Answer

Allow privileged containers for system-critical workloads.

Answer

Allow containers to use hostNetwork for easier service discovery.

Question 9

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

Accepted Answer

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

Answer

docker

Answer

runc

Answer

containerd

Question 10

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

Accepted Answer

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

Answer

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

Answer

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

Answer

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

Question 11

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

Accepted Answer

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

Answer

VirtualService

Answer

DestinationRule

Answer

ServiceEntry

Question 12

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

Accepted Answer

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

Answer

A PodSecurityPolicy that allows the runsc runtime

Answer

A ValidatingWebhookConfiguration to validate the runtime

Answer

A priorityClass with a high priority

Question 13

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

Accepted Answer

Injecting via volume mounts. 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.

Answer

Storing secrets in container image layers

Answer

Using environment variables

Answer

Using ConfigMap for secrets

Question 14

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

Accepted Answer

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

Answer

capabilities.allow

Answer

capabilities.add: ["ALL"]

Answer

dropCapabilities: true

Question 15

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

Accepted Answer

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

Answer

The webhook server uses HTTP instead of HTTPS

Answer

The webhook service is of type ClusterIP

Answer

The webhook server returns a 502 status code