CKS Minimize Microservice Vulnerabilities Practice Test 9 — 15 Questions

Question 1

Which TWO container sandboxing technologies are supported in Kubernetes via RuntimeClass? (Choose two)

Accepted Answer

gVisor (runsc). gVisor (runsc) is a container sandboxing technology that provides a user-space kernel for containers, isolating them from the host kernel. Kubernetes supports gVisor via RuntimeClass, allowing pods to be scheduled with the 'runsc' runtime for enhanced security.

Answer

Docker

Answer

containerd

Answer

runc

Question 2

Which field must be set in a Pod's security context to prevent the container from running as the root user?

Accepted Answer

runAsNonRoot: true. The `runAsNonRoot: true` field in a Pod's security context enforces that the container's entrypoint cannot run as UID 0 (root). If the container image attempts to run as root, the container runtime (e.g., containerd) will reject the container from starting, ensuring compliance with the principle of least privilege and mitigating root-based container escapes.

Answer

runAsUser: 1000

Answer

readOnlyRootFilesystem: true

Answer

allowPrivilegeEscalation: false

Question 3

An administrator deploys a Gatekeeper ConstraintTemplate with the following Rego policy:

package k8srequiredlabels
deny[{"msg": msg}] {
  input.request.kind.kind == "Pod"
  not input.request.object.metadata.labels["security-tier"]
  msg := "Pod must have label 'security-tier'"
}

After creating the Constraint, a user creates a Pod without the 'security-tier' label. What is the expected behavior?

Accepted Answer

The pod creation is denied with a message. The Gatekeeper ConstraintTemplate defines a Rego policy that denies any Pod creation request that lacks the 'security-tier' label. When the user creates a Pod without this label, the admission webhook evaluates the policy and returns a denial message 'Pod must have label 'security-tier'', preventing the Pod from being created. Gatekeeper operates as a validating admission webhook, so it rejects the request before the object is persisted in etcd.

Answer

The pod is created and the label is automatically added

Answer

Only the first pod without the label is denied; subsequent ones are allowed

Answer

The pod is created but logged as a violation

Question 4

You are configuring an Istio service mesh for mTLS between services. Which resource defines the TLS mode for traffic between services in a namespace?

Accepted Answer

PeerAuthentication. PeerAuthentication is the correct resource because it defines the TLS mode (e.g., STRICT, PERMISSIVE, DISABLE) for mTLS between services within a namespace in Istio. It enforces the authentication policy for workloads, ensuring that all traffic between them uses mutual TLS as specified. This directly controls the TLS mode for inter-service communication at the namespace or mesh level.

Answer

ServiceEntry

Answer

VirtualService

Answer

DestinationRule

Question 5

A cluster administrator wants to ensure that all Secrets are encrypted at rest using AES-CBC with a key managed by the local Kubernetes API server. Which configuration is required?

Accepted Answer

Set --encryption-provider-config flag to a file containing EncryptionConfiguration with 'aescbc' provider. The `--encryption-provider-config` flag on the kube-apiserver points to a YAML file containing an `EncryptionConfiguration` resource. Within that configuration, specifying the `aescbc` provider enables AES-CBC encryption for Secrets at rest, with the encryption key managed locally by the API server. This is the only option that satisfies the requirement for AES-CBC encryption with a locally managed key.

Answer

Enable etcd encryption by setting --experimental-encryption-provider-config

Answer

Use Secret resource's 'data' field with base64 encoding

Answer

Set --encryption-provider-config flag to a file containing EncryptionConfiguration with 'identity' provider

Question 6

A security team wants to enforce that containers in a specific namespace cannot gain new capabilities. Which Pod security context field is used to achieve this?

Accepted Answer

allowPrivilegeEscalation: false. `allowPrivilegeEscalation: false` directly controls whether a process can gain more privileges than its parent, which is the mechanism by which containers acquire new capabilities (e.g., via `setuid` binaries or `file capabilities`). Setting this to `false` prevents privilege escalation within the container, effectively blocking the acquisition of new capabilities beyond those initially granted. This field is defined in the Pod Security Context and is a key control for minimizing microservice vulnerabilities.

Answer

capabilities.drop: ["ALL"]

Answer

privileged: false

Answer

runAsNonRoot: true

Question 7

Which command creates a validating webhook configuration that checks all pods in the cluster?

Accepted Answer

kubectl create validatingwebhookconfiguration my-webhook --from-file=webhook.yaml. `kubectl create validatingwebhookconfiguration` is the specific command to create a ValidatingWebhookConfiguration resource from a YAML file, which can be configured to intercept and validate pod creation requests across the cluster. This resource allows you to define a webhook that checks all pods before they are admitted, enforcing custom validation logic.

Answer

kubectl create mutatingwebhookconfiguration my-webhook --from-file=webhook.yaml

Answer

kubectl run webhook --image=webhook

Answer

kubectl apply -f webhook.yaml --validating

Question 8

A developer asks you to run a container with gVisor runtime. The cluster has a RuntimeClass named 'gvisor' defined. Which field must be added to the Pod spec to use gVisor?

Accepted Answer

spec.runtimeClassName: gvisor. The `runtimeClassName` field is a top-level field in the Pod spec (i.e., `spec.runtimeClassName`) that specifies the name of the RuntimeClass resource to use for running the Pod's containers. In this case, setting `spec.runtimeClassName: gvisor` instructs the kubelet to use the gVisor runtime (via the 'gvisor' RuntimeClass) for all containers in the Pod, enabling a sandboxed kernel for enhanced isolation.

Answer

spec.containers[0].runtimeClassName: gvisor

Answer

metadata.runtimeClassName: gvisor

Answer

spec.runtimeClass: gvisor

Question 9

Which kubectl command lists all MutatingWebhookConfigurations in the cluster?

Accepted Answer

kubectl get mutatingwebhookconfigurations. `kubectl get mutatingwebhookconfigurations` is the standard Kubernetes command to list all MutatingWebhookConfiguration resources. These resources are part of the admission webhook mechanism, which intercepts API requests to mutate objects before they are persisted. The resource name is case-sensitive and must match the exact API resource name `mutatingwebhookconfigurations` (or the short form `mutatingwebhookconfiguration`).

Answer

kubectl get webhooks

Answer

kubectl list webhooks

Answer

kubectl get mutating-webhooks

Question 10

A cluster has EncryptionConfiguration with aescbc provider. After rotating the encryption key, what must be done to re-encrypt existing Secrets with the new key?

Accepted Answer

Use 'kubectl get secrets --all-namespaces -o yaml | kubectl replace -f -'. After rotating the encryption key in the EncryptionConfiguration, existing Secrets are still encrypted with the old key. To re-encrypt them with the new key, you must read all Secrets and write them back using 'kubectl get secrets --all-namespaces -o yaml | kubectl replace -f -'. This triggers the API server to encrypt the data with the new key (the first provider in the list) during the write operation.

Answer

Delete and recreate all Secrets

Answer

Restart the API server

Answer

Run 'kubectl encrypt secrets --key new-key'

Question 11

You need to drop all Linux capabilities from a container. Which YAML snippet is correct?

Accepted Answer

securityContext: { capabilities: { drop: ["ALL"] } }. In Kubernetes, to drop Linux capabilities from a container, you must use the `capabilities.drop` field inside `securityContext`. Option D correctly nests `capabilities` under `securityContext`. Option B is incorrect because it places `capabilities` directly under the container spec without the `securityContext` wrapper, which is not valid in most Kubernetes API versions. Options A and C use invalid keywords (`remove` and `none`). Therefore, only Option D is correct.

Answer

capabilities: { remove: ["ALL"] }

Answer

capabilities: { drop: ["ALL"] }

Answer

capabilities: { none: true }

Question 12

Which TWO of the following are valid ways to enforce that containers cannot run as root in a Kubernetes cluster? (Select TWO.)

Accepted Answer

Create a Gatekeeper Constraint that requires runAsNonRoot. Gatekeeper, using the Open Policy Agent (OPA) framework, can enforce custom policies via ConstraintTemplates. A Constraint requiring `runAsNonRoot: true` in the Pod security context ensures containers cannot run as root, providing a flexible, admission-time control that works across all namespaces.

Answer

Use a NetworkPolicy to block root containers

Answer

Set the kubelet flag --run-non-root

Answer

Use a ServiceAccount to restrict root

Question 13

Which THREE of the following are true about Istio PeerAuthentication? (Select THREE.)

Accepted Answer

It can be used to enable mTLS for all workloads in a namespace. Istio PeerAuthentication defines the mutual TLS (mTLS) mode for traffic between services within a mesh. When applied at the namespace level, it enforces the specified mTLS mode (e.g., STRICT) for all workloads in that namespace, ensuring that all inter-service communication uses TLS certificates for identity and encryption.

Answer

It configures how traffic is routed between services

Answer

It requires a DestinationRule to define the TLS settings

Question 14

Which TWO of the following are secure practices for managing secrets in Kubernetes? (Select TWO.)

Accepted Answer

Use a CSI driver to mount secrets as volumes. The CSI (Container Storage Interface) driver for secrets allows secrets to be mounted as volumes without storing them in etcd or exposing them in environment variables. This approach leverages the CSI driver's ability to fetch secrets from external providers (e.g., HashiCorp Vault) on-demand, ensuring secrets are never persisted in Kubernetes objects and reducing the attack surface. It also supports rotation without pod restarts, as the volume content can be updated dynamically.

Answer

Store secrets as environment variables

Answer

Embed secrets in container images

Answer

Store secrets in a ConfigMap

Question 15

A security admin wants to ensure that no container in a specific namespace runs as root. Which Gatekeeper ConstraintTemplate and Constraint configuration should be used?

Accepted Answer

ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsNonRoot != true }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`. The goal is to deny any Pod whose containers do not explicitly set runAsNonRoot to true. In Rego, the deny rule must fire when the condition is violated, so the correct expression is `input.review.object.spec.containers[_].securityContext.runAsNonRoot != true`. This matches containers that either omit the field or set it to false, which is exactly the insecure state the admin wants to block. The Constraint then binds this template to Pods via match.kinds.

Answer

ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsNonRoot == true }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`

Answer

ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.capabilities.drop != "ALL" }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`

Answer

ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsUser == 0 }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`