CKS Minimize Microservice Vulnerabilities Practice Test 9 — 15 Questions

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

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"
}

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 2

You have a Pod that uses a ServiceAccount token mounted via a projected volume. You want to ensure that the token has an expiration time and that the pod is not using a long-lived token. What is the most secure way to mount the token?

Accepted Answer

Use a projected volume with 'serviceAccountToken' and set 'expirationSeconds'. Using a projected volume with `serviceAccountToken` and setting `expirationSeconds` allows you to explicitly control the token's lifetime, ensuring it is short-lived and automatically rotated. This is the most secure approach as it prevents the use of long-lived tokens that could be compromised. The default service account token is a long-lived token with no expiration, which violates the principle of minimizing credential exposure.

Answer

Mount the default service account token at /var/run/secrets/kubernetes.io/serviceaccount

Answer

Set automountServiceAccountToken: false and manually mount a Secret containing a token

Answer

Use a ConfigMap to inject the token

Question 3

You need to create a NetworkPolicy that denies all ingress traffic to pods with label 'app: web' in the 'frontend' namespace, except for traffic from pods with label 'app: ingress' in the 'ingress' namespace. Which NetworkPolicy spec correctly achieves this?

Accepted Answer

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: ingress
    podSelector:
      matchLabels:
        app: ingress. It uses a single `from` entry with both a `namespaceSelector` (matching the `ingress` namespace by its `kubernetes.io/metadata.name` label) and a `podSelector` (matching pods with `app: ingress`). This combination restricts ingress traffic to only pods that are both in the `ingress` namespace AND have the label `app: ingress`, while implicitly denying all other ingress traffic to pods labeled `app: web` in the `frontend` namespace.

Answer

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        name: ingress
    podSelector:
      matchLabels:
        app: ingress

Answer

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        app: ingress
    podSelector: {}

Answer

ingress:
- from:
  - podSelector:
      matchLabels:
        app: ingress
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: ingress

Question 4

Which TWO of the following are valid ways to enforce that a container runs as a non-root user?

Accepted Answer

Set runAsNonRoot: true in the pod securityContext. Setting `runAsNonRoot: true` in the pod's `securityContext` explicitly instructs the kubelet to validate that the container's user ID is not 0 (root) before starting the container. If the container attempts to run as root, the kubelet will refuse to start it, providing a strong enforcement mechanism at the Kubernetes level.

Answer

Set the container image to use a root user

Answer

Use a PodSecurityPolicy (PSP)

Answer

Set runAsUser: 0 in the container securityContext

Question 5

Which THREE of the following are capabilities that should typically be dropped from a container to minimize vulnerabilities?

Accepted Answer

NET_ADMIN. NET_ADMIN (B) is a powerful Linux capability that allows a container to perform network administration tasks such as modifying routing tables, firewall rules (iptables/nftables), and network interface configurations. Dropping this capability prevents a compromised container from altering the host's network stack or bypassing network policies, which is critical for minimizing the attack surface in a microservice environment.

Answer

CHOWN

Answer

KILL

Question 6

You want to use an external secret management system like HashiCorp Vault to manage database credentials for your application. Which of the following are valid approaches to integrate Vault with Kubernetes?

Accepted Answer

Store Vault tokens in a Kubernetes Secret and mount them. Storing Vault tokens in a Kubernetes Secret and mounting them into pods is a valid integration approach. The token is retrieved from Vault (e.g., via a Kubernetes auth method) and stored as a Secret, which is then mounted as a volume or environment variable, allowing the application to authenticate with Vault and fetch secrets dynamically.

Answer

Use environment variables from Vault with a script

Answer

Store Vault tokens in a ConfigMap and mount them into pods

Question 7

You are tasked with creating a ConstraintTemplate in OPA/Gatekeeper that denies pods running with the 'latest' image tag. Which Rego rule should the ConstraintTemplate include?

Accepted Answer

violation[{"msg": msg}] { ... }. In OPA/Gatekeeper ConstraintTemplates, the Rego rule must be named `violation` to define the logic that triggers a denial when a resource violates the constraint. The `violation` rule returns a message in the `msg` field, which Gatekeeper uses to reject the resource. Option B is correct because it follows the required syntax for Gatekeeper constraints, where `violation[{"msg": msg}]` is the standard entry point for enforcing policies.

Answer

admit[{"msg": msg}] { ... }

Answer

reject[{"msg": msg}] { ... }

Answer

deny[{"msg": msg}] { ... }

Question 8

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 9

A security best practice is to avoid storing sensitive data in environment variables. Instead, secrets should be mounted as volumes. Which of the following YAML snippets correctly mounts a Kubernetes Secret named 'db-secret' as a volume at /etc/secrets?

Accepted Answer

volumes:
- name: secret-volume
  secret:
    secretName: db-secret
containers:
- name: app
  volumeMounts:
  - name: secret-volume
    mountPath: /etc/secrets. It uses the `secret` volume type with the `secretName` field to reference the 'db-secret' Secret, and mounts it at /etc/secrets via a volumeMount. This adheres to the best practice of mounting secrets as volumes rather than injecting them as environment variables, which can be exposed in process listings or logs.

Answer

volumes:
- name: secret-volume
  secret:
    name: db-secret
containers:
- name: app
  volumeMounts:
  - name: secret-volume
    mountPath: /etc/secrets

Answer

volumes:
- name: secret-volume
  configMap:
    name: db-secret
containers:
- name: app
  volumeMounts:
  - name: secret-volume
    mountPath: /etc/secrets

Answer

containers:
- name: app
  env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password

Question 10

An administrator wants to enforce mTLS between all services in the 'mesh' namespace using Istio. Which resource should be applied to require mutual TLS for all workloads in that namespace?

Accepted Answer

PeerAuthentication with mtls.mode: STRICT in the namespace. PeerAuthentication defines the authentication policy for workloads within a namespace. Setting `mtls.mode: STRICT` in a PeerAuthentication resource for the 'mesh' namespace enforces that all services in that namespace require mutual TLS for incoming traffic, ensuring that only authenticated and encrypted connections are accepted. This is the correct Istio resource to enforce mTLS at the namespace level.

Answer

VirtualService with tls mode

Answer

DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL

Answer

ServiceEntry for external services

Question 11

To encrypt secrets at rest in Kubernetes, an administrator configures an EncryptionConfiguration. What is the correct flag to pass to the kube-apiserver to use this configuration?

Accepted Answer

--encryption-provider-config=/path/to/config.yaml. The `--encryption-provider-config` flag is the exact command-line option that the kube-apiserver expects to locate the EncryptionConfiguration YAML file. This flag tells the API server to read the configuration that defines which encryption providers (e.g., `aescbc`, `secretbox`) to use for encrypting Kubernetes secrets at rest in etcd.

Answer

--feature-gates=EncryptionAtRest=true

Answer

--encryption-key=/path/to/config.yaml

Answer

--encryption-config=/path/to/config.yaml

Question 12

A cluster administrator wants to audit all pod creations and modifications using an admission webhook. Which resource type should be created to register the webhook?

Accepted Answer

ValidatingWebhookConfiguration. A ValidatingWebhookConfiguration is the correct resource type to register an admission webhook that audits pod creations and modifications. This resource tells the API server which external HTTP callbacks to invoke during the admission process, specifically for validation (non-mutating) purposes. It defines the rules for matching API requests (e.g., operations like CREATE and UPDATE on pods) and the webhook endpoint that receives AdmissionReview requests.

Answer

WebhookConfiguration

Answer

MutatingWebhookConfiguration

Answer

AdmissionWebhook

Question 13

Which of the following is a valid approach to enforce that containers cannot escalate privileges?

Accepted Answer

Set securityContext.allowPrivilegeEscalation: false. Setting `securityContext.allowPrivilegeEscalation: false` directly prevents a container from gaining more privileges than its parent process, such as through setuid binaries or `NO_NEW_PRIVS` flag. This is a key control to block privilege escalation attacks even if the container runs with some capabilities. It is enforced at the kernel level via the `no_new_privs` attribute, which disables privilege-gaining operations like `setuid` and `setgid`.

Answer

Set securityContext.readOnlyRootFilesystem: true

Answer

Set securityContext.privileged: false

Answer

Set securityContext.capabilities.drop: ["ALL"]

Question 14

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

Question 15

A security engineer runs the following command to inspect a pod's security context:

kubectl get pod secure-pod -o jsonpath='{.spec.containers[0].securityContext.capabilities}'

The output is: {"drop":["ALL"]}

What does this indicate?

Accepted Answer

The container has all Linux capabilities dropped. The output `{"drop":["ALL"]}` indicates that the container's security context explicitly drops all Linux capabilities via the `drop` field. This is a common security hardening practice to reduce the attack surface by removing all privileged operations, such as `CAP_NET_ADMIN` or `CAP_SYS_ADMIN`, from the container's effective capability set.

Answer

The output is invalid because capabilities should be in add field

Answer

The container has no capability restrictions

Answer

The container has only the NET_ADMIN capability added