CKS Minimize Microservice Vulnerabilities Practice Test 7 — 15 Questions

Question 1

Which of the following commands creates a ValidatingWebhookConfiguration that uses an OPA Gatekeeper webhook?

Accepted Answer

kubectl apply -f validatingwebhook.yaml where the webhook's service reference points to the gatekeeper-validating-webhook service.. A ValidatingWebhookConfiguration in Kubernetes must reference a service that handles the admission review request. OPA Gatekeeper exposes its webhook via the `gatekeeper-validating-webhook` service, which listens for `AdmissionReview` requests on the `/v1/admit` endpoint. Applying a YAML manifest that correctly specifies this service reference in the `clientConfig.service` field creates the necessary webhook configuration to integrate Gatekeeper.

Answer

kubectl apply -f constraint.yaml with a ConstraintTemplate.

Answer

kubectl create validatingwebhook gatekeeper --from-file=webhook.yaml

Answer

kubectl run gatekeeper-webhook --image=openpolicyagent/gatekeeper:v3.14.0

Question 2

What is the primary purpose of using a service mesh like Istio for microservices security?

Accepted Answer

To provide mTLS communication between services for encrypted and authenticated traffic.. The primary purpose of a service mesh like Istio for microservices security is to enforce mutual TLS (mTLS) between services, ensuring that all inter-service communication is both encrypted and authenticated. This is achieved by injecting sidecar proxies (Envoy) that handle TLS termination and certificate management transparently, without requiring changes to application code.

Answer

To replace Kubernetes NetworkPolicies for network segmentation.

Answer

To provide a centralized logging solution.

Answer

To automatically scale pods based on CPU usage.

Question 3

Which TWO of the following are valid Rego keywords used in OPA policies for Gatekeeper? (Select TWO)

Accepted Answer

input. In Rego, `input` and `data` are reserved keywords. `input` refers to the incoming document (e.g., the admission review request in Gatekeeper), and `data` refers to the global data document containing external data. `deny` is not a keyword but a common rule name used to trigger denial; `violation` and `allow` are also custom rule names. Therefore, the correct answer is options C and D.

Answer

violation

Answer

allow

Answer

deny

Question 4

Which THREE of the following are valid ways to manage secrets in a Kubernetes environment? (Select THREE)

Accepted Answer

Use an external secret manager like HashiCorp Vault and inject secrets via sidecar or CSI driver.. External secret managers like HashiCorp Vault can inject secrets into pods via a sidecar container (e.g., Vault Agent) or a CSI driver (e.g., Secrets Store CSI Driver). This approach avoids storing raw secrets in the cluster, reduces the attack surface, and enables dynamic secret rotation without pod restarts.

Answer

Store secrets in environment variables directly in the Deployment YAML.

Answer

Store secrets in ConfigMaps and reference them in pods.

Question 5

Which TWO of the following are correct about container sandboxing technologies? (Select TWO)

Accepted Answer

Kata Containers run containers in lightweight VMs, providing hardware-level isolation.. Kata Containers provide hardware-level isolation by running each container or pod in a lightweight VM with its own guest kernel using KVM. Option B is correct because gVisor implements a user-space kernel (called Sentry) that intercepts system calls, providing a kernel-level sandbox without dedicated VMs. Option C is incorrect because Kata Containers use a guest kernel, not the host kernel. Option D is incorrect because gVisor does not run containers in separate VMs; it runs as a kernel within the user space. Option E is incorrect because although RuntimeClass is commonly used to select non-default runtimes in Kubernetes, the statement is not universally required; it is a mechanism but not a strict requirement for using these technologies, making the claim that both 'require' RuntimeClass too absolute and thus false.

Answer

Kata Containers use the host kernel for system calls.

Answer

gVisor runs containers in separate VMs for each pod.

Answer

Both gVisor and Kata Containers require RuntimeClass to be used in Kubernetes.

Question 6

You need to ensure that all containers in a pod run as non-root. Which security context field should you set to enforce this?

Accepted Answer

runAsNonRoot: true. Setting `runAsNonRoot: true` in the pod or container security context instructs Kubernetes to verify that the container's user ID (UID) is non-zero (i.e., not root) before starting the container. If the container image is configured to run as root (UID 0), the Pod will fail to start, ensuring compliance with the requirement that all containers run as non-root.

Answer

privileged: false

Answer

readOnlyRootFilesystem: true

Answer

allowPrivilegeEscalation: false

Question 7

A security policy requires that all pods drop ALL Linux capabilities and disable privilege escalation. Which YAML snippet correctly implements this in the pod's security context?

Accepted Answer

securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]. It explicitly drops all Linux capabilities with `capabilities: drop: ["ALL"]` and disables privilege escalation with `allowPrivilegeEscalation: false`. This satisfies the security policy requirement to remove all capabilities and prevent any process from gaining more privileges than its parent, which is essential for minimizing container breakout risks.

Answer

securityContext:
  privileged: false
  capabilities:
    drop: ["ALL"]

Answer

securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    add: ["NET_ADMIN"]

Answer

securityContext:
  capabilities:
    drop: ["ALL"]

Question 8

You are using Open Policy Agent (OPA) Gatekeeper to enforce pod security. You want to create a constraint that denies pods unless they have readOnlyRootFilesystem set to true. Which Rego rule in a ConstraintTemplate correctly implements this?

Accepted Answer

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  not container.securityContext.readOnlyRootFilesystem
  msg := "readOnlyRootFilesystem must be true"
}. It uses `not container.securityContext.readOnlyRootFilesystem` to trigger a violation when the field is missing, false, or nil. In Rego, `not` succeeds when the expression inside it fails, so this rule denies any pod where any container does not have `readOnlyRootFilesystem` explicitly set to `true`. This matches the requirement to deny pods unless the field is `true`.

Answer

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  container.securityContext.readOnlyRootFilesystem == true
  msg := "readOnlyRootFilesystem must be true"
}

Answer

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  not container.securityContext.readOnlyRootFilesystem == false
  msg := "readOnlyRootFilesystem must be true"
}

Answer

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  container.securityContext.readOnlyRootFilesystem == false
  msg := "readOnlyRootFilesystem must be true"
}

Question 9

You want to enable mutual TLS (mTLS) between services in a namespace using Istio. Which custom resource should you configure to enforce STRICT mTLS for all workloads in the namespace?

Accepted Answer

PeerAuthentication with mtls.mode: STRICT. PeerAuthentication is the Istio custom resource specifically designed to define traffic authentication policies between workloads. Setting `mtls.mode: STRICT` enforces that all traffic in the namespace must use mutual TLS (mTLS), rejecting any plain-text or non-mTLS connections. This is the standard way to enforce STRICT mTLS at the namespace level in Istio.

Answer

DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL

Answer

VirtualService with tls.mode: SIMPLE

Answer

ServiceEntry with resolution: NONE

Question 10

You are configuring encryption at rest for Kubernetes secrets. After creating an EncryptionConfiguration with aescbc provider, which additional step is required to enable encryption?

Accepted Answer

Restart the kube-apiserver with --encryption-provider-config flag. The EncryptionConfiguration resource defines how Kubernetes should encrypt data at rest, but it is not automatically applied. The kube-apiserver must be restarted with the `--encryption-provider-config` flag pointing to the configuration file so that it reads and enforces the encryption settings for all subsequent writes to etcd. Without this flag, the apiserver ignores the EncryptionConfiguration entirely.

Answer

Apply the EncryptionConfiguration as a ConfigMap

Answer

Restart the kube-scheduler

Answer

Recreate all secrets in the cluster

Question 11

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 12

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 13

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 14

A pod uses a Secret mounted as a volume. The Secret is updated. How can the pod consume the updated values without restarting?

Accepted Answer

The mounted volume is automatically updated over time. When a Secret is mounted as a volume in Kubernetes, the kubelet periodically syncs the secret data from the API server and updates the files in the volume. This means the pod can consume the updated values without needing a restart, as the files are refreshed automatically (with a default sync period of around 60 seconds). Option C correctly identifies this behavior.

Answer

Use a sidecar container that watches for changes and reloads the application

Answer

Update the pod spec to reference a new Secret version

Answer

Delete and recreate the pod

Question 15

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