CKS Minimize Microservice Vulnerabilities Practice Test 3 — 15 Questions

Question 1

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 2

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 3

A pod is failing with 'CrashLoopBackOff'. The pod's securityContext includes 'allowPrivilegeEscalation: false'. The container image is built with a default user of root and attempts to change capabilities. What is the most likely cause of the crash?

Accepted Answer

The container is trying to set capabilities using setcap. The container image runs as root by default and attempts to change capabilities, which requires the `setcap` command. However, the pod's `securityContext` has `allowPrivilegeEscalation: false`, which prevents the container process from gaining additional privileges beyond its initial set. Since `setcap` requires privilege escalation (specifically the `CAP_SETFCAP` capability), the operation fails, causing the container to crash and enter `CrashLoopBackOff`.

Answer

The container is trying to write to a read-only filesystem

Answer

The container is missing the NET_ADMIN capability

Answer

The container is trying to bind to a privileged port (<1024) as non-root

Question 4

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 5

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 6

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

Question 7

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

Accepted Answer

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

Answer

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

Answer

Using a mutating webhook to apply security contexts

Answer

Using Pod Security Admission (PSA) with labels on namespaces

Question 8

To encrypt secrets at rest, which file must be modified on the control plane nodes?

Accepted Answer

/etc/kubernetes/manifests/kube-apiserver.yaml. To enable encryption of secrets at rest in Kubernetes, you must modify the kube-apiserver manifest file at `/etc/kubernetes/manifests/kube-apiserver.yaml` on control plane nodes. This file is a static Pod manifest that defines the API server's startup flags, including `--encryption-provider-config`, which points to an EncryptionConfiguration YAML file specifying the encryption providers (e.g., `aescbc`, `secretbox`) and keys. The API server is the component that writes and reads secrets from etcd, so it is the only place where encryption-at-rest configuration is applied.

Answer

/etc/kubernetes/scheduler.conf

Answer

/etc/kubernetes/etcd.yaml

Answer

/etc/kubernetes/kubelet.conf

Question 9

You have an existing deployment that uses environment variables for secrets. Which kubectl command can be used to update the deployment to mount secrets as volumes without recreating the pods?

Accepted Answer

kubectl patch deployment <deploy> -p '{"spec":{"template":{"spec":{"containers":[{"name":"app","volumeMounts":[{"name":"secret","mountPath":"/etc/secret"}]}],"volumes":[{"name":"secret","secret":{"secretName":"mysecret"}}]}}}}'. The correct command to update a deployment to mount secrets as volumes without manually recreating pods is `kubectl patch deployment`. `kubectl set volume` is not a valid kubectl subcommand. The `kubectl set` command only supports env, image, resources, serviceaccount, selector, and subject. Therefore, only option A is correct.

Answer

kubectl set env deployment <deploy> --from=secret/mysecret

Answer

kubectl edit deployment <deploy>

Answer

kubectl set volume deployment/<deploy> --add --name=secret --mount-path=/etc/secret --secret-name=mysecret

Question 10

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

Accepted Answer

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

Answer

DestinationRule with tls: ISTIO_MUTUAL

Answer

PeerAuthentication with mode: DISABLE

Answer

PeerAuthentication with mode: PERMISSIVE

Question 11

A Gatekeeper Constraint is not blocking pods that violate the policy. The constraint references a ConstraintTemplate that has been successfully created. What is the most likely cause?

Accepted Answer

The Constraint has 'enforcementAction: dryrun'. When a Gatekeeper Constraint has `enforcementAction: dryrun`, it logs violations but does not block pod creation or updates. This is the most likely cause because the constraint is correctly configured and the ConstraintTemplate exists, but the enforcement action is set to dryrun instead of the default `deny`.

Answer

The Constraint is missing the 'match' field

Answer

The Constraint is in a different namespace than the pods

Answer

The ConstraintTemplate is missing the 'violation' rule

Question 12

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

Accepted Answer

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

Answer

Docker

Answer

containerd

Answer

runc

Question 13

Which TWO of the following are valid ways to reduce the attack surface of a container? (Select TWO)

Accepted Answer

Drop all capabilities with capabilities.drop: ["ALL"]. Dropping all capabilities with `capabilities.drop: ["ALL"]` removes all Linux capabilities from the container, preventing it from performing privileged operations like raw socket access or mounting filesystems. This follows the principle of least privilege and directly reduces the attack surface by eliminating potential kernel-level exploits. Option C is correct because setting `readOnlyRootFilesystem: true` makes the container's root filesystem immutable at runtime, preventing attackers from writing malicious binaries or modifying configuration files even if they gain code execution inside the container.

Answer

Add the SYS_ADMIN capability

Answer

Set runAsUser: 0

Answer

Set privileged: false

Question 14

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)

Accepted Answer

Deploy a ValidatingWebhookConfiguration that checks for readOnlyRootFilesystem: true. A ValidatingWebhookConfiguration can intercept pod creation requests and reject any pod that does not have `readOnlyRootFilesystem: true` set in its security context. This enforces the requirement without modifying the pod spec, ensuring only compliant pods are admitted.

Answer

Use a Gatekeeper policy to drop all capabilities

Answer

Apply a NetworkPolicy that denies egress

Question 15

An administrator needs to enforce that all pods in a namespace run with read-only root filesystem. Which Pod Security Standard should be applied?

Accepted Answer

Run the pod with securityContext.readOnlyRootFilesystem: true. The correct answer is B: setting `securityContext.readOnlyRootFilesystem: true` on each container enforces a read-only root filesystem. However, this is not a Pod Security Standard. Pod Security Standards are admission control profiles (privileged, baseline, restricted) applied via namespace labels. To enforce this requirement for all pods in a namespace, you would use Pod Security Admission or a custom admission policy, not just the field itself.

Answer

Use a NetworkPolicy to restrict filesystem access

Answer

Set securityContext.runAsNonRoot: true

Answer

Set securityContext.allowPrivilegeEscalation: false