CKS Minimize Microservice Vulnerabilities — Timed 100 Questions

Question 1

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?

Accepted Answer

Store the API key in a Kubernetes Secret and mount it as a volume inside the container. Option C is correct because 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.

Answer

Store the API key in a ConfigMap and expose it as an environment variable

Answer

Hardcode the API key in the container image

Answer

Store the API key in a Kubernetes Secret and expose it as an environment variable

Question 2

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

Accepted Answer

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

Answer

Use 'privileged' PSS with Warn mode

Answer

Use 'baseline' PSS with Audit mode

Answer

Use 'baseline' PSS with Enforce mode

Question 3

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?

Accepted Answer

Set `securityContext.readOnlyRootFilesystem: true` in the Pod spec. Option C is correct because 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.

Answer

Set `securityContext.runAsNonRoot: true` in the Pod spec

Answer

Mount an emptyDir volume to the container's writable directories

Answer

Set `securityContext.privileged: false` in the Pod spec

Question 4

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?

Accepted Answer

Apply a custom seccomp profile that blocks the vulnerable syscall. Option B is correct because 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 5

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. Option B is correct because DNS queries typically use UDP, but when a response is truncated or when zone transfers are involved, TCP is required. The `NET_RAW` capability allows a container to create raw sockets, which is necessary for crafting and sending TCP packets for DNS lookups at the transport layer. Without this capability, the container's network stack may be restricted to only UDP-based DNS resolution.

Answer

Add `DAC_OVERRIDE` capability

Answer

Add `NET_ADMIN` capability

Answer

Add `NET_BIND_SERVICE` capability

Question 6

Which TWO of the following are effective measures to minimize the impact of a compromised microservice container in a Kubernetes cluster? (Choose two.)

Accepted Answer

Set resource limits (CPU/memory) on the container. Setting resource limits (CPU/memory) on a container is correct because it prevents a compromised microservice from consuming excessive cluster resources, which could lead to a denial-of-service (DoS) attack against other workloads. By enforcing limits via the container's cgroup constraints, the kernel throttles or OOM-kills the container if it exceeds its allocated resources, containing the blast radius of the compromise.

Answer

Set the container's root filesystem as read-only

Answer

Run the container as root to simplify debugging

Answer

Use hostNetwork: true to share the host's network namespace

Question 7

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. Option B is correct because 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 8

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

Accepted Answer

Containers cannot add any Linux capabilities. Option D is correct because 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 9

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 10

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.. Option B is correct because 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 11

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.. Option C is correct because 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 12

You are a platform engineer at a financial services company. The production cluster runs a set of microservices that handle sensitive customer data. The cluster has been configured with Pod Security Standards (PSS) enforced via OPA/Gatekeeper. Recently, the security team identified that a new deployment of the `payment-processing` microservice is running with the `seccomp` profile set to `Unconfined`. This violates the company policy that requires all containers to use a runtime default seccomp profile. The deployment YAML does not explicitly set any security context for seccomp. The cluster's nodes are running containerd 1.6 with default seccomp profile enabled. The OPA constraint template checks that `securityContext.seccompProfile.type` is set to `RuntimeDefault` or `Localhost`. However, the deployment passes the OPA validation. What is the most likely reason the deployment is not being rejected by OPA, and how should you fix it?

Accepted Answer

The OPA constraint only checks pod-level `securityContext`, but the deployment uses container-level settings.. Option D is correct because the OPA constraint template checks `securityContext.seccompProfile.type` at the pod level, but the deployment does not set any security context at the pod level. The seccomp profile is only set at the container level (or defaults to `Unconfined` by the runtime), and the OPA constraint does not inspect container-level `securityContext`. This mismatch allows the deployment to pass validation even though the container is running with an unconfined seccomp profile.

Answer

The seccomp profile must be set via an admission controller, not OPA.

Answer

OPA/Gatekeeper is not properly installed or the constraint is not active.

Answer

The cluster's nodes do not support seccomp, so the profile is ignored.

Question 13

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 14

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.. Option C is correct because 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 15

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

Question 16

Arrange the steps to configure and use Trivy to scan container images for vulnerabilities in a CI/CD pipeline.

Question 17

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

Question 18

Match each Kubernetes network security concept to its definition.

Question 19

Which of the following OPA Gatekeeper Rego policies would deny a pod that sets `securityContext.runAsUser: 0`?

Accepted Answer

violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.containers[_].securityContext.runAsUser == 0 }. The correct Rego policy denies pods with `runAsUser: 0` because that runs as root. Option A correctly checks for the field and denies if it is 0.

Answer

violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.containers[_].securityContext.capabilities.drop == "ALL" }

Answer

violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.securityContext.runAsUser == 0 }

Answer

violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.containers[_].securityContext.runAsNonRoot == true }

Question 20

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. The field `readOnlyRootFilesystem: true` makes the container's root filesystem read-only, which forces all writes to go to mounted volumes.

Answer

allowPrivilegeEscalation

Answer

privileged

Answer

runAsNonRoot