CKS Minimize Microservice Vulnerabilities Practice Test 2 — 15 Questions

Question 1

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 2

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 3

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 4

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 5

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

Question 6

An OPA/Gatekeeper ConstraintTemplate is written to enforce that all Deployments have the label 'app.kubernetes.io/name'. However, the Constraint does not deny Deployments without the label. What is the most likely cause?

Accepted Answer

The Rego rule does not set 'violation' to true when the label is missing. Gatekeeper ConstraintTemplates use Rego to define violation rules. A common mistake is to use 'violation' with a generic message but not actually deny the request. The Rego must contain a 'deny' rule or use the 'violation' keyword correctly. In Gatekeeper, the default Rego rule name is 'violation' and it must be set to true when a violation occurs. If the rule is empty or incorrectly written, it will not deny.

Answer

The Constraint is not bound to any namespaces

Answer

The Deployment has the label set but with a different value

Answer

Gatekeeper is not installed in the cluster

Question 7

An administrator wants to prevent pods from using secrets as environment variables and enforce that secrets are only mounted as volumes. Which admission controller could be used to achieve this?

Accepted Answer

MutatingWebhookConfiguration. A MutatingWebhookConfiguration can intercept Pod creation requests and mutate them to enforce that Secrets are only mounted as volumes, not used as environment variables. This admission controller allows you to define a webhook that modifies the Pod spec before it is persisted, enabling custom validation and mutation logic beyond built-in controllers.

Answer

NetworkPolicy

Answer

PodSecurityPolicy (deprecated)

Answer

ValidatingWebhookConfiguration

Question 8

Which TWO of the following are valid methods to securely manage secrets in Kubernetes? (Select 2)

Accepted Answer

Use an external secrets manager like HashiCorp Vault with a CSI driver or operator. Option A is correct because integrating an external secrets manager such as HashiCorp Vault via the Secrets Store CSI driver or the Vault Agent Injector/Operator keeps secret material outside etcd and injects it at runtime, providing centralized rotation, auditing, and encryption. Option C is correct because Kubernetes Secret volumes and projected volumes mount secret data as tmpfs-backed files inside the pod, avoiding persistence to node disk and allowing fine-grained, read-only delivery. Option B is wrong because baking secrets into container images exposes them in image layers and registries, making rotation and revocation impractical. Option D is wrong because ConfigMaps are not designed for confidential data and are stored unencrypted in etcd by default. Option E is wrong because environment variables from Secrets can leak via process listings, crash dumps, and child processes, and are not updated after pod start.

Answer

Store secrets directly in container images as files

Answer

Store secrets in ConfigMaps

Answer

Pass secrets as environment variables from a Secret resource

Question 9

Which THREE of the following are valid ways to enforce mTLS in an Istio service mesh? (Select 3)

Accepted Answer

DestinationRule with trafficPolicy.tls.mode set to ISTIO_MUTUAL. Option A is correct because a DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL configures the client side of the connection to originate Istio mutual TLS, using Istio-provisioned certificates for authentication between workloads. Option B is correct because PeerAuthentication with mtls.mode: STRICT enforces that the server side only accepts mTLS traffic, rejecting any plaintext connections to the workload. Option C is correct because a ServiceEntry can define a TLS/mTLS configuration (e.g., tls.mode: MUTUAL with clientCertificate, privateKey, and caCertificates) to enforce mTLS for traffic to external services registered in the mesh. Option D is not correct because AuthorizationPolicy operates at L7/L4 on already-established connections and cannot itself enforce or require mTLS; it only allows/denies requests based on identity, namespace, or attributes. Option E is not correct because Kubernetes NetworkPolicy works at L3/L4 and can only allow or block traffic by IP/port/protocol, not enforce TLS or mTLS handshakes.

Answer

AuthorizationPolicy with deny rules for non-mTLS traffic

Answer

NetworkPolicy with ingress rules to allow only TLS traffic

Question 10

Which field in a PodSecurityContext ensures that the container cannot gain privileges beyond its parent process?

Accepted Answer

allowPrivilegeEscalation. `allowPrivilegeEscalation` directly controls whether a process can gain more privileges than its parent process, such as via setuid binaries or file capabilities. When set to `false` in the PodSecurityContext, it ensures that no child process can obtain elevated privileges, which is a key security control to prevent privilege escalation attacks within a container.

Answer

privileged

Answer

readOnlyRootFilesystem

Answer

runAsNonRoot

Question 11

An administrator creates a Pod with the following securityContext:
securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
The container image has a binary that requires read/write access to /data, which is an emptyDir volume mounted by the Pod. The container fails to start with 'Permission denied' when writing to /data. What is the most likely cause?

Accepted Answer

The container is running as user 1000, but the volume is owned by root (uid 0) and the fsGroup 2000 does not give write permission.. The container runs as UID 1000 with GID 3000, and the emptyDir volume is owned by root (uid 0). The fsGroup 2000 causes Kubernetes to change the volume's group ownership to 2000 and set group-writable permissions, but the process's primary GID is 3000, not 2000, so it does not get write access via group membership. The result is 'Permission denied' when the binary tries to write to /data.

Answer

The container's base image has a restrictive umask that overrides the pod's security context.

Answer

The fsGroup is set but the volume's fsGroupChangePolicy is missing.

Answer

The emptyDir volume is not writable by default; it needs to be explicitly configured.

Question 12

You need to set up a ValidatingWebhookConfiguration to deny pods that run as root. The webhook server is deployed in the 'webhook' namespace with service 'webhook-svc' on port 443. Which of the following is a correct snippet for the webhook configuration?

Accepted Answer

clientConfig:
  service:
    name: webhook-svc
    namespace: webhook
    path: /validate
    port: 443. It properly defines a service reference with the required fields: name, namespace, and path. The port field is explicitly set to 443, matching the webhook server's listening port. In Kubernetes, when using a service reference and the webhook server's certificate is signed by the cluster's CA (which is typical for in-cluster services), the caBundle field may be omitted as the API server can use its own CA bundle to verify the connection. Thus, the configuration in A is complete and valid for this scenario.

Answer

clientConfig:
  url: https://10.96.0.1:443/validate

Answer

clientConfig:
  url: https://webhook-svc.webhook.svc:443/validate

Answer

clientConfig:
  service:
    name: webhook-svc
    namespace: webhook
    path: /validate
  caBundle: <base64>

Question 13

You are writing a Rego policy for OPA Gatekeeper to deny pods that do not have 'runAsNonRoot: true' set in their security context. The ConstraintTemplate expects an input parameter 'runAsNonRoot' that is a boolean. Which Rego rule correctly denies such pods?

Accepted Answer

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  not container.securityContext.runAsNonRoot
  msg := "Container must run as non-root"
}

violation[{"msg": msg}] {
  pod := input.review.object
  not pod.spec.securityContext.runAsNonRoot
  msg := "Pod must run as non-root"
}. The correct Rego rule must check both the pod-level securityContext and the container-level securityContext for runAsNonRoot, because Kubernetes allows setting runAsNonRoot at either level. The correct answer (A) includes two violation rules: one that iterates over containers and checks container.securityContext.runAsNonRoot, and another that checks pod.spec.securityContext.runAsNonRoot. This ensures that if either level lacks the setting, a violation is triggered. The other options only check one level or use incorrect syntax.

Answer

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  not has_field(container, "securityContext") or not container.securityContext.runAsNonRoot
  msg := "Container must set runAsNonRoot: true"
}

Answer

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  not container.securityContext.runAsNonRoot
  msg := "Container must run as non-root"
}

Answer

violation[{"msg": msg}] {
  pod := input.review.object
  not pod.spec.securityContext.runAsNonRoot
  msg := "Pod must run as non-root"
}

Question 14

An administrator deploys a Pod with the following security context:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000

However, the Pod fails to start with an error: 'container has runAsNonRoot and image will run as root'. What is the most likely cause?

Accepted Answer

The container image specifies USER root in its Dockerfile. Kubernetes checks runAsNonRoot by determining the effective UID. When runAsUser is explicitly set to a non-zero value (e.g., 1000), the container runs as that UID, overriding any USER directive in the image. The error message 'container has runAsNonRoot and image will run as root' is only returned by the kubelet when runAsUser is not specified or is set to 0, and the image's default user is root. Therefore, the given scenario would not produce that error; the most likely cause would be a container-level securityContext that sets runAsUser to 0, or the runAsUser field being omitted—not merely the image specifying USER root.

Answer

The container runtime does not support runAsNonRoot

Answer

The pod is missing a seccomp profile

Answer

The runAsUser field is set to 1000, which is a non-root user

Question 15

An administrator wants to use gVisor as the container runtime for specific high-security workloads. After installing gVisor, what Kubernetes resource must be created to allow pods to request gVisor?

Accepted Answer

RuntimeClass with handler: runsc. A is correct because gVisor uses a user-space kernel (runsc) that intercepts system calls. Kubernetes uses a RuntimeClass resource to tell the kubelet which container runtime handler to use for a pod. By creating a RuntimeClass with handler: runsc, pods can specify runtimeClassName: gvisor in their spec to request gVisor.

Answer

CustomResourceDefinition for gVisor

Answer

PodSecurityPolicy with runtimeClass: gvisor

Answer

ConfigMap with runtime handler mapping