CKS Minimize Microservice Vulnerabilities Practice Test 2 — 15 Questions

Question 1

Match each Kubernetes network security concept to its definition.

Accepted Answer

NetworkPolicy: A Kubernetes resource that defines rules for ingress and egress traffic to and from pods.. Correct matches: NetworkPolicy defines ingress/egress rules; Calico network policy extends with advanced features; Ingress rule controls inbound traffic; Egress rule controls outbound traffic; Default deny blocks all unless allowed. Common confusions include swapping ingress and egress definitions and mistaking non-native policies as native.

Answer

Egress rule: In a NetworkPolicy, specifies which incoming traffic is allowed to reach pods.

Answer

Calico network policy: A Kubernetes native resource for network segmentation.

Question 2

Which of the following OPA Gatekeeper Rego policies would deny a pod that sets `securityContext.runAsUser: 0`?

Accepted Answer

violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.containers[_].securityContext.runAsUser == 0 }. It uses the correct Rego path to match the `runAsUser` field inside each container's `securityContext`. The `containers[_]` iterator ensures the policy checks every container in the pod spec, and `runAsUser == 0` correctly identifies containers running as root. This is the standard way to enforce a 'no root' policy at the container level in OPA Gatekeeper.

Answer

violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.containers[_].securityContext.capabilities.drop == "ALL" }

Answer

violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.securityContext.runAsUser == 0 }

Answer

violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.containers[_].securityContext.runAsNonRoot == true }

Question 3

Which Istio resource is used to enforce mutual TLS (mTLS) for all services in a namespace, ensuring that traffic between services is encrypted?

Accepted Answer

PeerAuthentication. PeerAuthentication is the correct Istio resource for enforcing mutual TLS (mTLS) at the namespace level. It defines the TLS mode for traffic between services, and when set to `STRICT`, it requires that all traffic within the namespace uses mTLS, encrypting both the request and response. This is part of Istio's security features under the `security.istio.io/v1beta1` API group.

Answer

DestinationRule

Answer

ServiceEntry

Answer

VirtualService

Question 4

Which kubectl command would you use to create a ValidatingWebhookConfiguration from a YAML file?

Accepted Answer

kubectl apply -f webhook.yaml. `kubectl apply -f webhook.yaml` is the standard command to create or update Kubernetes resources from a YAML file, including a ValidatingWebhookConfiguration. This command uses declarative management, applying the configuration defined in the file to the cluster, which is the recommended approach for creating admission webhooks.

Answer

kubectl run webhook --image=webhook --restart=Never

Answer

kubectl create -f webhook.yaml

Answer

kubectl expose deployment webhook --port=443

Question 5

A cluster administrator has configured EncryptionConfiguration to encrypt secrets at rest using a local key. After applying the configuration, the administrator creates a new secret. How can they verify that the secret is encrypted at rest?

Accepted Answer

Use etcdctl to read the secret directly from etcd and verify it is encrypted.. Encryption at rest is applied at the etcd storage layer, not at the Kubernetes API level. To verify that a secret is actually encrypted when stored, you must read it directly from etcd using etcdctl (with the appropriate endpoint and certificate flags). If the encryption configuration is working, the secret data will appear as base64-encoded ciphertext (e.g., starting with 'k8s:enc:aescbc:...') rather than plaintext base64 of the original secret data.

Answer

Run kubectl get secret -o yaml and check for an encryption annotation.

Answer

Use kubectl describe secret and look for 'Encrypted: true'.

Answer

Check the apiserver logs for encryption status messages.

Question 6

A pod is using a RuntimeClass that specifies gVisor (runsc). Which of the following scenarios is most likely to cause the pod to fail?

Accepted Answer

The pod attempts to mount a hostPath directory with privileged access.. GVisor (runsc) operates as a sandboxed kernel that intercepts system calls, and it does not support privileged operations such as mounting hostPath directories with privileged access. The `privileged: true` flag attempts to bypass the sandbox, which gVisor explicitly denies, causing the pod to fail. This is a core security constraint of gVisor, which aims to minimize microservice vulnerabilities by restricting host-level interactions.

Answer

The pod runs a web server listening on port 8080.

Answer

The pod mounts a ConfigMap as a volume.

Answer

The pod uses a PersistentVolumeClaim for storage.

Question 7

Which Kubernetes admission controller is responsible for mutating and validating pod requests based on policies defined by OPA Gatekeeper?

Accepted Answer

ValidatingAdmissionWebhook. OPA Gatekeeper uses the ValidatingAdmissionWebhook admission controller to intercept pod creation requests and enforce policies defined as ConstraintTemplates and Constraints. This webhook validates requests against Rego policies before they are persisted, rejecting non-compliant pods. The ValidatingAdmissionWebhook is the correct mechanism because Gatekeeper does not mutate requests—it only validates them.

Answer

PodSecurityPolicy

Answer

ServiceAccount

Answer

NodeRestriction

Question 8

A pod fails to start with the error 'Container runtime network not ready', and the node uses Kata Containers (RuntimeClass: kata). What is the most likely cause?

Accepted Answer

The CNI plugin is not configured correctly for the kata RuntimeClass. Kata Containers use lightweight VMs for pod isolation, which require a separate CNI plugin (e.g., flannel, calico) to be configured specifically for the kata RuntimeClass. The error 'Container runtime network not ready' indicates that the CNI plugin is either missing, misconfigured, or not compatible with the kata runtime, preventing the pod's network namespace from being set up.

Answer

The node has insufficient memory

Answer

The pod is trying to mount a hostPath volume

Answer

The pod's securityContext sets runAsNonRoot: true

Question 9

Which of the following is the correct way to drop all capabilities in a container's security context?

Accepted Answer

securityContext: capabilities: drop: ['ALL']. In Kubernetes, the `securityContext.capabilities.drop` field is used to explicitly remove Linux capabilities from a container. Setting `drop: ['ALL']` removes all capabilities, ensuring the container runs with the least privilege. This is the standard and recommended way to harden container security.

Answer

securityContext: capabilities: remove: ['ALL']

Answer

securityContext: capabilities: []

Answer

securityContext: capabilities: add: []

Question 10

What is the purpose of the `allowPrivilegeEscalation: false` setting in a container's security context?

Accepted Answer

It prevents processes from gaining additional privileges (e.g., via setuid).. The `allowPrivilegeEscalation: false` setting in a container's security context directly controls whether processes within the container can gain more privileges than their parent process. This is achieved by dropping the `CAP_SETUID`, `CAP_SETGID`, and `CAP_SETPCAP` capabilities and, crucially, by setting the `no_new_privs` flag on the container's process, which prevents the use of setuid/setgid binaries and other privilege-escalation mechanisms. This is a core security control to mitigate container breakout via privilege escalation.

Answer

It prevents the container from running as root.

Answer

It prevents the container from using host networking.

Answer

It prevents the container from accessing host devices.

Question 11

Which TWO of the following are valid ways to securely manage secrets in Kubernetes? (Choose two.)

Accepted Answer

Mount Kubernetes Secrets as volumes into the pod.. Mounting Kubernetes Secrets as volumes into the pod ensures that secret data is stored in the pod's filesystem as files, which are created with in-memory tmpfs to avoid writing to disk. This approach leverages Kubernetes' native secret handling, where the secret data is base64-decoded and presented as plaintext files, and access can be controlled via RBAC and PodSecurityPolicies. It also supports automatic rotation when secrets are updated, provided the pod is restarted or the volume is remounted.

Answer

Use environment variables from the pod spec referencing Secret keys.

Answer

Pass secrets as command-line arguments to the container.

Answer

Store secrets in ConfigMaps with base64 encoded data.

Question 12

Which THREE of the following are best practices for securing a Kubernetes cluster using OPA Gatekeeper? (Choose three.)

Accepted Answer

Enforce that containers set runAsNonRoot: true.. Enforcing `runAsNonRoot: true` via OPA Gatekeeper ensures that containers run with a non-root user ID, mitigating the risk of privilege escalation attacks. This aligns with the Kubernetes Pod Security Standards (PSS) 'restricted' profile and is a key control for minimizing microservice vulnerabilities.

Answer

Allow privileged containers for system-critical workloads.

Answer

Allow containers to use hostNetwork for easier service discovery.

Question 13

Which TWO of the following are valid Kubernetes RuntimeClass handlers for container sandboxing? (Choose two.)

Accepted Answer

runsc. (runsc) is correct because it is the handler for gVisor, a user-space kernel that provides an additional layer of sandboxing between the container and the host kernel. In Kubernetes, a RuntimeClass with handler 'runsc' instructs the container runtime (e.g., containerd) to launch the container using gVisor's runsc runtime, which intercepts system calls to enforce a security boundary.

Answer

docker

Answer

runc

Answer

containerd

Question 14

You are deploying a microservice that must run as a non-root user and have a read-only root filesystem. Which two fields must be set in the PodSecurityContext or container SecurityContext?

Accepted Answer

readOnlyRootFilesystem: true [CORRECT]. To meet the requirements, readOnlyRootFilesystem: true (D) is required for a read-only root filesystem. For running as a non-root user, either runAsUser: 1000 (C) or runAsNonRoot: true (E) is sufficient. Setting both is allowed but not mandatory. Therefore the two fields that must be set are D and one of {C, E}, not a unique pair.

Answer

allowPrivilegeEscalation: false [wrong]

Answer

seLinuxOptions [wrong]

Answer

runAsUser: 1000 [CORRECT]

Question 15

A security engineer wants to encrypt secrets at rest in an existing Kubernetes cluster. The cluster is already running with the default encryption configuration. After creating an EncryptionConfiguration resource and updating the kube-apiserver manifest, which command should be used to ensure the new configuration is applied without restarting the API server?

Accepted Answer

kubectl delete pod -n kube-system -l component=kube-apiserver. After updating the kube-apiserver static pod manifest and the EncryptionConfiguration, the API server reads the encryption config only at startup. Therefore a restart is necessary. The standard method is to delete the kube-apiserver pod so kubelet recreates it. The phrase 'without restarting' in the stem is incorrect.

Answer

kubectl label node control-plane --overwrite encryption=true

Answer

kubectl rollout restart -n kube-system deployment/kube-apiserver

Answer

kubectl apply -f encryption-config.yaml