CKS Minimize Microservice Vulnerabilities Practice Test 4 — 15 Questions

Question 1

An administrator wants to use OPA Gatekeeper to enforce that all pods have a resource limits section defined. Which of the following is the correct combination to implement this policy?

Accepted Answer

Create a ConstraintTemplate with a Rego policy that checks for 'spec.containers[*].resources.limits', then create a Constraint targeting pods.

Answer

Create a NetworkPolicy to block pods without limits.

Answer

Create a MutatingWebhookConfiguration to add resource limits automatically.

Answer

Create a ValidatingWebhookConfiguration that calls an external service to validate pod limits.

Question 2

Which kubectl command creates a secret named 'mysecret' from a file called 'credentials.json'?

Accepted Answer

kubectl create secret generic mysecret --from-file=credentials.json. `kubectl create secret generic` is the command to create a generic (opaque) secret from a file. The `--from-file` flag reads the contents of `credentials.json` and stores them as the secret's data, using the filename as the key by default. This is the standard method for injecting sensitive file-based data into a Kubernetes secret.

Answer

kubectl apply -f credentials.json

Answer

kubectl create configmap mysecret --from-file=credentials.json

Answer

kubectl create secret tls mysecret --cert=credentials.json

Question 3

A pod is configured with securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000

The volume mounted at /data is owned by user 1000 and group 2000. The container process inside the pod writes to /data. Which statement about file ownership is true?

Accepted Answer

Files created in /data will be owned by user 1000 and group 2000.. The `fsGroup: 2000` in the pod's securityContext causes Kubernetes to recursively change the group ownership of the volume to group 2000 and enable a setgid bit on the mount directory. When the container process (running as user 1000) writes new files to /data, those files inherit the group ownership of the directory (2000) due to the setgid bit, while the user ownership remains 1000 (the runAsUser). Thus, new files are owned by user 1000 and group 2000.

Answer

Files created in /data will be owned by root:root because of the volume mount.

Answer

Files created in /data will be owned by user 1000 and group 3000.

Answer

Files created in /data will be owned by user 1000 and group 1000.

Question 4

An administrator needs to encrypt secrets at rest in etcd. Which of the following steps is required?

Accepted Answer

Create an EncryptionConfiguration resource and pass it to the kube-apiserver via the --encryption-provider-config flag.. Kubernetes does not have a native `kubectl encrypt secrets` command, and etcd itself does not handle encryption configuration directly. Instead, encryption at rest is configured by creating an `EncryptionConfiguration` YAML resource that defines providers (e.g., `aescbc`, `secretbox`) and passing it to the `kube-apiserver` via the `--encryption-provider-config` flag. The API server then transparently encrypts secrets before writing them to etcd and decrypts them on read.

Answer

Use kubectl encrypt secrets command.

Answer

Modify the etcd configuration to enable encryption.

Answer

Set the environment variable ENCRYPT_SECRETS=true on all nodes.

Question 5

An administrator wants to use gVisor to sandbox containers in a Kubernetes cluster. Which resource must be created to enable this?

Accepted Answer

RuntimeClass with handler: runsc. To use gVisor as a container runtime sandbox in Kubernetes, you must create a RuntimeClass resource with the handler set to 'runsc'. This tells the kubelet which runtime handler to use when running pods that reference this RuntimeClass, enabling gVisor's user-space kernel (runsc) to intercept and sandbox system calls.

Answer

DaemonSet to install gVisor on nodes

Answer

PodSecurityPolicy with gVisor enabled

Answer

SecurityContext with runtime: gvisor

Question 6

A pod is running with the following security context:

```yaml
securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault
```

The pod is in a CrashLoopBackOff. The logs show: "exec user process caused: operation not permitted". What is the most likely cause?

Accepted Answer

The allowPrivilegeEscalation: false prevents the container from starting.. The 'operation not permitted' error occurs during the runtime execution of the container's entrypoint. With allowPrivilegeEscalation: false, Kubernetes sets the no_new_privs flag, which causes the kernel to reject exec of binaries that would gain additional privileges (e.g., setuid or file capabilities). This leads to CrashLoopBackOff. runAsNonRoot: true checks the image's configured user at pod creation and would result in an error like 'container has runAsNonRoot and image will run as root' rather than an exec failure. The seccomp RuntimeDefault profile does not block execve, and missing CAP_SYS_ADMIN is not relevant to this startup error.

Answer

The container image is set to run as root, which conflicts with runAsNonRoot.

Answer

The container is missing the CAP_SYS_ADMIN capability.

Answer

The seccomp profile is blocking necessary system calls.

Question 7

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 8

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 9

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 10

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 11

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 12

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 13

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 14

A security best practice is to avoid storing secrets in environment variables. Which is a secure alternative for injecting secrets into a pod?

Accepted Answer

Use the Kubernetes Secret Store CSI driver to mount from external store. Both mounting the Secret as a volume (D) and using the Kubernetes Secret Store CSI driver to mount from an external store (A) are secure alternatives to environment variables. D uses tmpfs to avoid persisting secrets to disk, while A integrates with external secret stores and avoids storing secrets in etcd. The original explanation only justifies D and does not address why A is incorrect.

Answer

Store secrets in ConfigMap and reference them in the pod

Answer

Embed the secret directly in the pod definition YAML

Question 15

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