CKS Minimize Microservice Vulnerabilities — 40 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

Question 16

Which command creates a ResourceQuota in the 'team-a' namespace?

Accepted Answer

kubectl create quota team-a-quota --namespace=team-a. `kubectl create quota` is the dedicated kubectl command to create a ResourceQuota object in a specified namespace. The `--namespace=team-a` flag ensures the quota is applied to the 'team-a' namespace, and the name 'team-a-quota' identifies the ResourceQuota resource.

Answer

kubectl expose quota --namespace=team-a

Answer

kubectl apply -f quota.yaml --namespace=team-a

Answer

kubectl run quota --namespace=team-a --image=quota

Question 17

A pod fails to start with 'CrashLoopBackOff'. The pod's YAML includes securityContext: { allowPrivilegeEscalation: false, capabilities: { drop: ['ALL'] } }. What is the likely cause?

Accepted Answer

The container image requires privilege escalation to run. The securityContext drops all capabilities and disables privilege escalation. If the container image requires elevated privileges (e.g., to bind to a low port, mount filesystems, or use raw sockets), it will fail to start and enter CrashLoopBackOff. This is a common misconfiguration when applying strict Pod Security Standards without verifying the image's runtime requirements.

Answer

The pod is missing a required environment variable

Answer

The node does not support seccomp profiles

Answer

The pod's service account lacks permissions to create pods

Question 18

A pod's container tries to read environment variables that contain database credentials. The cluster has an external secrets manager (HashiCorp Vault) integrated via a sidecar. Which approach is MOST secure for exposing secrets to the container?

Accepted Answer

Mount the secrets as a volume using a CSI driver. Mounting secrets via a CSI driver (e.g., the HashiCorp Vault CSI provider) allows secrets to be retrieved on-demand from the external secrets manager and presented as a volume to the pod. This approach avoids storing secrets in etcd, eliminates the need for a sidecar, and ensures that secrets are never written to disk or exposed in environment variables, which can be leaked through logs or `/proc` files.

Answer

Set the secrets as environment variables using the 'env' field

Answer

Embed the secrets directly in the container image

Answer

Use a ConfigMap to store the secrets

Question 19

An OPA Gatekeeper ConstraintTemplate uses a Rego rule that denies pods without a specific label. The Constraint is created but pods without the label are still being allowed. What is the MOST likely cause?

Accepted Answer

The Constraint object has not been created. The most likely cause is that the Constraint object has not been created. In OPA Gatekeeper, a ConstraintTemplate defines the Rego rule logic, but it is only a template. To enforce the policy, you must create a Constraint resource that instantiates the template and specifies parameters (e.g., the required label). Without the Constraint, the Rego rule is never evaluated against admission requests, so pods without the label are allowed.

Answer

The Rego policy has a syntax error

Answer

Gatekeeper is not installed in the cluster

Answer

The namespace is excluded via Gatekeeper configuration

Question 20

Which of the following is a best practice for storing sensitive information like database passwords in Kubernetes?

Accepted Answer

Mount secrets as volumes in the pod. Mounting secrets as volumes ensures that sensitive data is stored in the in-memory tmpfs filesystem, which is never written to disk and is automatically removed when the pod is deleted. This approach also allows for automatic updates of secret values when the Secret object is modified, without requiring a pod restart, and provides better access control through filesystem permissions.

Answer

Use environment variables in the pod spec to pass secrets

Answer

Embed secrets as literals in the pod YAML file

Answer

Store them in ConfigMaps