CKS Minimize Microservice Vulnerabilities Practice Test 5 — 15 Questions

Question 1

Which admission controller is responsible for validating and mutating requests based on webhooks?

Accepted Answer

ValidatingAdmissionWebhook and MutatingAdmissionWebhook. The ValidatingAdmissionWebhook and MutatingAdmissionWebhook admission controllers are specifically designed to intercept admission requests and call external webhooks to validate or mutate the request. MutatingAdmissionWebhook can modify the object (e.g., inject sidecar containers) before it is persisted, while ValidatingAdmissionWebhook only validates and can reject the request. These controllers are the only ones that delegate admission decisions to external HTTP callbacks.

Answer

ServiceAccount

Answer

PodSecurityPolicy

Answer

NodeRestriction

Question 2

You need to use gVisor as a container runtime for a set of workloads in the cluster. Which Kubernetes resource must be created to reference the runtime class?

Accepted Answer

Create a RuntimeClass resource with handler: runsc. In Kubernetes, a RuntimeClass resource is used to select a container runtime configuration, such as gVisor. The RuntimeClass must specify the handler field set to 'runsc', which is the gVisor runtime binary. This resource is then referenced by pods via the `runtimeClassName` field to enforce sandboxed isolation.

Answer

Set the kubelet runtime flag --runtime-class=gvisor

Answer

Install a CRD for gVisor

Answer

Create a Pod with spec.runtimeClassName set to "gvisor"

Question 3

You are deploying a ValidatingWebhookConfiguration. The webhook server is running in the 'webhook' namespace, service name 'svc', port 443. Which clientConfig should you specify?

Accepted Answer

clientConfig:
  service:
    namespace: webhook
    name: svc
    path: /validate. A ValidatingWebhookConfiguration's clientConfig must reference the Kubernetes service that fronts the webhook server, specifying the service's namespace, name, and the path to the validation endpoint. Since the webhook server runs in the 'webhook' namespace with service name 'svc' on port 443, the service reference must use namespace: webhook and name: svc, with path: /validate. Kubernetes automatically resolves the service to its cluster-internal DNS name and uses the service's HTTPS port (443) when a service reference is provided.

Answer

clientConfig:
  url: https://webhook.svc.cluster.local:443/validate

Answer

clientConfig:
  service:
    namespace: webhook
    name: webhook
    path: /validate

Answer

clientConfig:
  service:
    namespace: default
    name: svc
    path: /validate

Question 4

You need to enforce that no pod runs with privileged containers or runs as root. Which tool can define policies that block such pods at admission time?

Accepted Answer

OPA Gatekeeper. OPA Gatekeeper is a Kubernetes admission controller that enforces custom policies defined via the Constraint Framework (CF). It can reject pods that request privileged containers or run as root by evaluating constraints against the PodSecurityPolicy-like rules expressed in Rego, blocking them before they are persisted in etcd.

Answer

Kubernetes Secret

Answer

PodDisruptionBudget

Answer

NetworkPolicy

Question 5

Which command can be used to view the current set of admission webhooks in the cluster?

Accepted Answer

kubectl get validatingwebhookconfigurations. Admission webhooks in Kubernetes are configured via `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` resources. The command `kubectl get validatingwebhookconfigurations` retrieves all validating admission webhooks currently registered in the cluster, which is the standard way to list them.

Answer

kubectl get webhooks

Answer

kubectl get webhookconfigurations

Answer

kubectl get admissionwebhooks

Question 6

Which TWO of the following are recommended practices for securing container images and runtime?

Accepted Answer

Set runAsNonRoot to true in securityContext. Setting `runAsNonRoot: true` in the securityContext ensures that the container's entrypoint runs with a user ID other than 0 (root), reducing the risk of container escape if an attacker gains code execution. Setting `readOnlyRootFilesystem: true` makes the container's filesystem read-only, preventing attackers from modifying critical system files or binaries. Both are key hardening practices recommended by Kubernetes security best practices.

Answer

Run containers as root inside the container for easier management

Answer

Mount the docker socket inside the container for debugging

Answer

Use the latest tag for all images

Question 7

Which THREE of the following are characteristics of container sandboxing runtimes like gVisor and Kata Containers?

Accepted Answer

They require setting spec.runtimeClassName in the pod spec. Container sandboxing runtimes like gVisor and Kata Containers are not the default runtime in Kubernetes. To use them, you must specify the runtime class name in the pod spec via `spec.runtimeClassName`. This field references a `RuntimeClass` resource that defines which container runtime (e.g., `gvisor`, `kata`) should be used for that pod, overriding the default runc runtime.

Answer

They eliminate the need for seccomp profiles

Answer

They share the host kernel directly

Question 8

Which TWO of the following are valid approaches to manage secrets in a Kubernetes cluster?

Accepted Answer

Mount secrets as volumes in pods. Kubernetes allows secrets to be mounted as volumes in pods, which is a secure approach as the secret data is stored in tmpfs (RAM-backed filesystem) and not written to disk on the node. This method avoids exposing secrets in environment variables that can be leaked through process dumps or logs, and it supports automatic updates when secrets are modified.

Answer

Pass secrets as environment variables

Answer

Embed secrets directly in the pod YAML definition

Answer

Store secrets as plain text in ConfigMap

Question 9

A security auditor requires that all pods in a cluster must not run as root. Which Pod Security Standard (PSS) and enforcement mode should be applied at the namespace level?

Accepted Answer

Restricted profile with enforce mode. The Restricted profile is the only Pod Security Standard that prohibits running containers as root by enforcing the 'MustRunAsNonRoot' security context constraint. Applying it in 'enforce' mode ensures that any pod violating this rule is immediately rejected at admission time, which directly meets the auditor's requirement.

Answer

Baseline profile with enforce mode

Answer

Baseline profile with warn mode

Answer

Privileged profile with audit mode

Question 10

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 11

You want to run a container with gVisor for sandboxing. After installing gVisor and creating a RuntimeClass named 'gvisor', which Pod configuration enables it?

Accepted Answer

Set spec.runtimeClassName: gvisor. The `spec.runtimeClassName` field in a Pod spec is the standard Kubernetes mechanism to select a specific container runtime for that Pod. When a RuntimeClass named 'gvisor' is created, setting `spec.runtimeClassName: gvisor` instructs the kubelet to use the gVisor runtime (runsc) to run the Pod's containers, providing an additional sandboxing layer for security.

Answer

Set spec.nodeSelector with 'gvisor: true'

Answer

Define an environment variable RUNTIME=gvisor in the container

Answer

Add an annotation 'container.runtime: gvisor' to the Pod

Question 12

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 13

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 14

You need to ensure that all pods in a namespace have the label 'security: high' added automatically upon creation. Which admission controller should you use?

Accepted Answer

MutatingWebhookConfiguration. A MutatingWebhookConfiguration intercepts pod creation requests and can automatically add the label 'security: high' to pods in a namespace. This admission controller mutates the object before it is persisted, ensuring all pods receive the label without manual intervention.

Answer

PodSecurityPolicy (deprecated)

Answer

ResourceQuota

Answer

ValidatingAdmissionPolicy

Question 15

Which flag enables the PodSecurity admission plugin in kube-apiserver?

Accepted Answer

--enable-admission-plugins=PodSecurity. The PodSecurity admission plugin is enabled in kube-apiserver by passing the `--enable-admission-plugins=PodSecurity` flag. This flag activates the built-in Pod Security Admission (PSA) controller, which replaced the deprecated PodSecurityPolicy (PSP) in Kubernetes v1.25. The plugin enforces the Pod Security Standards (baseline, restricted, privileged) at the namespace level based on labels.

Answer

--admission-control=PodSecurity

Answer

--feature-gates=PodSecurity=true

Answer

--pod-security-policy=true