CKS Minimize Microservice Vulnerabilities Practice Test 4 — 15 Questions

Question 1

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?

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

Accepted Answer

Apply a custom seccomp profile that blocks the vulnerable syscall. 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.

Answer

Apply a NetworkPolicy to block egress traffic from the Pod

Answer

Apply an AppArmor profile to the Pod

Answer

Use a PodSecurityPolicy to drop all capabilities

Question 2

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

Accepted Answer

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

Answer

Add `DAC_OVERRIDE` capability

Answer

Add `NET_ADMIN` capability

Answer

Add `NET_BIND_SERVICE` capability

Question 3

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

Accepted Answer

Use minimal base images (e.g., distroless or scratch) to reduce attack surface. 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.

Answer

Use images from any public registry for flexibility

Answer

Always use the latest tag to get the most recent patches

Question 4

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

Accepted Answer

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

Answer

Containers can run in privileged mode

Answer

Containers cannot use ConfigMap volumes

Answer

Containers must run as the root user

Question 5

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

Accepted Answer

The container has all capabilities enabled, which is a security risk. 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.

Answer

The container is running without any capabilities

Answer

The container has dropped all capabilities except NET_BIND_SERVICE

Answer

The container has default Docker capabilities, which is secure

Question 6

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?

Accepted Answer

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

Answer

Store the credentials in a Secret and mount it as a volume with default permissions.

Answer

Use a sidecar container that reads the secret from a file and exposes it via a Unix socket, running the container as root.

Answer

Store the credentials in a ConfigMap and inject them as environment variables.

Question 7

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

Accepted Answer

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

Answer

Manually inject sidecar proxies into every pod to enforce mTLS.

Answer

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

Answer

Store secrets directly in container images for easy access.

Question 8

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

Accepted Answer

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

Answer

Run containers as root to avoid permission issues.

Answer

Allow all egress traffic from pods to simplify network management.

Answer

Use hostNetwork: true for pods to improve network performance.

Question 9

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

Accepted Answer

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

Answer

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

Answer

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

Answer

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

Question 10

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

Accepted Answer

Create the NetworkPolicy YAML manifest, then apply it using kubectl apply, then deploy test pods with appropriate labels, then verify connectivity using kubectl exec.. NetworkPolicy must be created and applied, then tested by deploying pods and checking connectivity. The policy is enforced immediately.

Answer

Apply the NetworkPolicy using kubectl apply, then create the YAML manifest, then deploy test pods, then verify connectivity.

Answer

Create the NetworkPolicy YAML, then deploy test pods, then apply the policy, then verify connectivity.

Answer

Deploy test pods, then create and apply the NetworkPolicy, then verify connectivity.

Question 11

Match each Kubernetes object or feature to its primary security purpose.

Accepted Answer

NetworkPolicy: Controls network traffic to and from pods. Correct matches: NetworkPolicy controls network traffic; RBAC controls permissions; SecurityContext defines security settings. Common confusions: ServiceAccount is for identity, not encryption; PodSecurityPolicy is for security constraints, not resource limits.

Answer

ServiceAccount: Encrypts secrets at rest

Answer

PodSecurityPolicy: Defines CPU and memory limits for pods

Question 12

Match each Kubernetes network security concept to its definition.

Accepted Answer

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

Answer

Egress rule: In a NetworkPolicy, specifies which incoming traffic is allowed to reach pods.

Answer

Calico network policy: A Kubernetes native resource for network segmentation.

Question 13

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

Accepted Answer

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

Answer

allowPrivilegeEscalation

Answer

privileged

Answer

runAsNonRoot

Question 14

Which Istio resource is used to enforce mutual TLS (mTLS) for all services in a namespace, ensuring that traffic between services is encrypted?

Accepted Answer

PeerAuthentication. PeerAuthentication is the correct Istio resource for enforcing mutual TLS (mTLS) at the namespace level. It defines the TLS mode for traffic between services, and when set to `STRICT`, it requires that all traffic within the namespace uses mTLS, encrypting both the request and response. This is part of Istio's security features under the `security.istio.io/v1beta1` API group.

Answer

DestinationRule

Answer

ServiceEntry

Answer

VirtualService

Question 15

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

Accepted Answer

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

Answer

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

Answer

kubectl create -f webhook.yaml

Answer

kubectl expose deployment webhook --port=443