CKS Minimize Microservice Vulnerabilities Practice Test 12 — 15 Questions

Question 1

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?

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

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 2

Which kubectl command would you use to create a Secret from a file named 'db-password.txt'?

Accepted Answer

kubectl create secret generic db-password --from-file=db-password.txt. `kubectl create secret generic` is the command to create a generic (opaque) Secret from a file using the `--from-file` flag. This reads the content of `db-password.txt` and stores it as a key-value pair in the Secret, where the key defaults to the filename. This is the standard method for creating a Secret from a plaintext file in Kubernetes.

Answer

kubectl apply -f db-password.txt

Answer

kubectl create configmap db-password --from-file=db-password.txt

Answer

kubectl create secret tls db-password --cert=db-password.txt

Question 3

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 4

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 5

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 6

A security engineer needs to ensure that all containers in a cluster run as non-root users. Which Pod Security Context field should be set to enforce this requirement?

Accepted Answer

runAsNonRoot: true. Setting `runAsNonRoot: true` in the Pod Security Context explicitly instructs the container runtime to verify that the container's user ID is non-zero (i.e., not root). If the container image is configured to run as root (UID 0), the Pod will fail to start, enforcing the requirement that all containers run as non-root users.

Answer

runAsUser: 1000

Answer

privileged: false

Answer

allowPrivilegeEscalation: false

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

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 9

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 10

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 11

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 12

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 13

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

Question 14

An OPA/Gatekeeper ConstraintTemplate is defined with the following Rego rule:

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

What happens when a pod is submitted with a container that has runAsNonRoot: true?

Accepted Answer

The pod is admitted. The Rego rule `container.securityContext.runAsNonRoot != true` only triggers a violation when the field is not set to `true`. When `runAsNonRoot: true` is explicitly set, the condition evaluates to `false`, so no violation is generated, and the pod is admitted without any denial or mutation. OPA/Gatekeeper by default enforces constraints by denying admission; it does not mutate resources or generate audit logs unless specifically configured for dry-run or audit mode.

Answer

The pod is admitted but an audit log is generated

Answer

The pod is denied with a message

Answer

The pod is mutated to set runAsNonRoot

Question 15

Which THREE of the following security context settings help mitigate container breakout attacks? (Select 3)

Accepted Answer

readOnlyRootFilesystem: true. Option A (readOnlyRootFilesystem: true) is correct because mounting the container's root filesystem read-only prevents an attacker who gains code execution from writing malicious binaries, scripts, or modifying system files needed to escalate or persist during a breakout attempt. Option C (allowPrivilegeEscalation: false) is correct because it sets the kernel's no_new_privs flag on the container process, blocking setuid/setgid binaries and file capabilities from granting the process more privileges than its parent — a key vector for escaping to the host. Option E (runAsNonRoot: true) is correct because it forces the container to run as a non-root UID, so even if the process escapes the container boundary it lacks root privileges on the host, dramatically reducing the impact of a breakout. Option B (privileged: true) is not correct because privileged containers get all Linux capabilities and direct device access, which is precisely what enables breakouts rather than mitigating them. Option D (capabilities: add: ['NET_ADMIN']) is not correct because adding NET_ADMIN expands the container's kernel attack surface (e.g., manipulating network interfaces, iptables), increasing breakout risk instead of reducing it.

Answer

privileged: true

Answer

capabilities: add: ['NET_ADMIN']