CKS Minimize Microservice Vulnerabilities Practice Test 1 — 15 Questions

Question 1

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 2

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 3

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 is installed in the CI environment. The container image is built and pushed to a registry. Trivy then scans the pushed image for known vulnerabilities. The scan results (e.g., JSON output) are parsed by the CI pipeline, and policies such as failing the build on critical vulnerabilities are enforced based on those results.

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 4

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 5

Which Kubernetes admission controller is responsible for mutating and validating pod requests based on policies defined by OPA Gatekeeper?

Accepted Answer

ValidatingAdmissionWebhook. OPA Gatekeeper uses the ValidatingAdmissionWebhook admission controller to intercept pod creation requests and enforce policies defined as ConstraintTemplates and Constraints. This webhook validates requests against Rego policies before they are persisted, rejecting non-compliant pods. The ValidatingAdmissionWebhook is the correct mechanism because Gatekeeper does not mutate requests—it only validates them.

Answer

PodSecurityPolicy

Answer

ServiceAccount

Answer

NodeRestriction

Question 6

A cluster administrator wants to ensure that all pods in a namespace run with the `seccomp` profile set to `RuntimeDefault`. Which OPA Gatekeeper ConstraintTemplate would achieve this?

Accepted Answer

violation[{"msg": "Seccomp profile must be RuntimeDefault"}] { input.review.object.spec.containers[_].securityContext.seccompProfile.type != "RuntimeDefault" }. It uses the Rego rule `input.review.object.spec.containers[_].securityContext.seccompProfile.type != "RuntimeDefault"` to check that every container in the pod has its seccomp profile type set to `RuntimeDefault`. This ensures that any container without the required profile triggers a violation, enforcing the cluster administrator's policy.

Answer

violation[{"msg": "Seccomp profile must be RuntimeDefault"}] { input.review.object.spec.containers[_].securityContext.seccompProfile.type == "Unconfined" }

Answer

violation[{"msg": "Seccomp profile must be RuntimeDefault"}] { input.review.object.spec.containers[_].securityContext.seccompProfile == "RuntimeDefault" }

Answer

violation[{"msg": "Seccomp profile must be RuntimeDefault"}] { input.review.object.spec.securityContext.seccompProfile.type != "RuntimeDefault" }

Question 7

You are deploying a microservice that must run as a non-root user and have a read-only root filesystem. Which two fields must be set in the PodSecurityContext or container SecurityContext?

Accepted Answer

readOnlyRootFilesystem: true. To meet the requirements, readOnlyRootFilesystem: true (D) is required for a read-only root filesystem. For running as a non-root user, either runAsUser: 1000 (C) or runAsNonRoot: true (E) is sufficient. Setting both is allowed but not mandatory. Therefore the two fields that must be set are D and one of {C, E}, not a unique pair.

Answer

allowPrivilegeEscalation: false

Answer

seLinuxOptions

Answer

runAsUser: 1000

Question 8

A security engineer wants to encrypt secrets at rest in an existing Kubernetes cluster. The cluster is already running with the default encryption configuration. After creating an EncryptionConfiguration resource and updating the kube-apiserver manifest, which command should be used to ensure the new configuration is applied without restarting the API server?

Accepted Answer

kubectl delete pod -n kube-system -l component=kube-apiserver. After updating the kube-apiserver static pod manifest and the EncryptionConfiguration, the API server reads the encryption config only at startup. Therefore a restart is necessary. The standard method is to delete the kube-apiserver pod so kubelet recreates it. The phrase 'without restarting' in the stem is incorrect.

Answer

kubectl label node control-plane --overwrite encryption=true

Answer

kubectl rollout restart -n kube-system deployment/kube-apiserver

Answer

kubectl apply -f encryption-config.yaml

Question 9

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 10

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 11

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"]. Option A is correct because dropping all Linux capabilities with capabilities.drop: ["ALL"] removes the default set of privileged kernel operations (such as NET_RAW, CHOWN, and SETUID) that a container process would otherwise inherit, directly shrinking the attack surface. Option C is correct because setting readOnlyRootFilesystem: true mounts the container's root filesystem read-only, preventing an attacker from writing malicious binaries, modifying configuration, or persisting malware inside the container. Option B is wrong because adding SYS_ADMIN grants broad administrative privileges (mounting filesystems, namespace manipulation), which expands rather than reduces the attack surface. Option D is wrong because runAsUser: 0 runs the container as root, the most privileged UID, increasing risk. Option E is wrong because privileged: false is the default and merely avoids an escalation; it is not itself an active hardening measure that reduces the attack surface.

Answer

Add the SYS_ADMIN capability

Answer

Set runAsUser: 0

Answer

Set privileged: false

Question 12

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

Question 13

A pod is running with the following security context:

```yaml
securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault
```

The pod is in a CrashLoopBackOff. The logs show: "exec user process caused: operation not permitted". What is the most likely cause?

Accepted Answer

The allowPrivilegeEscalation: false prevents the container from starting.. The 'operation not permitted' error occurs during the runtime execution of the container's entrypoint. With allowPrivilegeEscalation: false, Kubernetes sets the no_new_privs flag, which causes the kernel to reject exec of binaries that would gain additional privileges (e.g., setuid or file capabilities). This leads to CrashLoopBackOff. runAsNonRoot: true checks the image's configured user at pod creation and would result in an error like 'container has runAsNonRoot and image will run as root' rather than an exec failure. The seccomp RuntimeDefault profile does not block execve, and missing CAP_SYS_ADMIN is not relevant to this startup error.

Answer

The container image is set to run as root, which conflicts with runAsNonRoot.

Answer

The container is missing the CAP_SYS_ADMIN capability.

Answer

The seccomp profile is blocking necessary system calls.

Question 14

A security best practice is to avoid storing secrets in environment variables. Which is a secure alternative for injecting secrets into a pod?

Accepted Answer

Use the Kubernetes Secret Store CSI driver to mount from external store. Both mounting the Secret as a volume (D) and using the Kubernetes Secret Store CSI driver to mount from an external store (A) are secure alternatives to environment variables. D uses tmpfs to avoid persisting secrets to disk, while A integrates with external secret stores and avoids storing secrets in etcd. The original explanation only justifies D and does not address why A is incorrect.

Answer

Store secrets in ConfigMap and reference them in the pod

Answer

Embed the secret directly in the pod definition YAML

Question 15

You have deployed a service mesh with Istio and want to enforce mutual TLS (mTLS) for all traffic between services in the 'mesh' namespace. Which resource should you create?

Accepted Answer

A PeerAuthentication resource with mTLS mode set to STRICT and a namespace selector. A PeerAuthentication resource with mTLS mode set to STRICT and a namespace selector enforces mutual TLS for all traffic within the specified namespace. This is the correct Istio resource to define mTLS policies at the namespace level, as it applies to all workloads in the namespace without requiring individual DestinationRules.

Answer

A DestinationRule resource with trafficPolicy tls mode set to ISTIO_MUTUAL

Answer

A VirtualService with a rewrite rule to enforce TLS

Answer

A ServiceEntry to define external services