CKS Minimize Microservice Vulnerabilities — Timed 20 Questions

Question 1

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?

20 minute time limit — choose an answer to begin.

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 2

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

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

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 5

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 6

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 7

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 8

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 9

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 10

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

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 12

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 13

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 14

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

Accepted Answer

Step 1: Install Trivy, Step 2: Build and push container image, Step 3: Scan image with Trivy, Step 4: Parse results and enforce policies. Trivy scanning involves installation, building/pushing image, scanning, parsing results, and enforcing policies.

Answer

Step 1: Build and push container image, Step 2: Install Trivy, Step 3: Scan image with Trivy, Step 4: Parse results and enforce policies

Answer

Step 1: Install Trivy, Step 2: Scan image with Trivy, Step 3: Build and push container image, Step 4: Parse results and enforce policies

Answer

Step 1: Install Trivy, Step 2: Build and push container image, Step 3: Parse results and enforce policies, Step 4: Scan image with Trivy

Question 15

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 16

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 17

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 }. It uses the correct Rego path to match the `runAsUser` field inside each container's `securityContext`. The `containers[_]` iterator ensures the policy checks every container in the pod spec, and `runAsUser == 0` correctly identifies containers running as root. This is the standard way to enforce a 'no root' policy at the container level in OPA Gatekeeper.

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 18

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 19

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

Question 20

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?

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.