CKS Timed Practice Test 1 — 10 Questions

Question 1

A DevOps team uses a CI/CD pipeline to build container images and push them to a private registry. To minimize the risk of supply chain attacks, which of the following is the most effective security control to implement?

10 minute time limit — choose an answer to begin.

Accepted Answer

Sign all container images using a private key and verify the signature before deployment.. Signing container images with a private key and verifying the signature before deployment ensures image integrity and authenticity, directly mitigating supply chain attacks where an attacker could tamper with images in transit or at rest. This control, often implemented using tools like Notary or Cosign (part of the Sigstore project), provides cryptographic proof that the image was produced by a trusted source and has not been altered. Without signature verification, even a vulnerability-scanned image could be replaced with a malicious one, bypassing other controls.

Answer

Scan all images for vulnerabilities using Trivy before pushing to the registry.

Answer

Restrict access to the registry using Kubernetes RBAC and service accounts.

Answer

Implement network policies to restrict traffic to the registry endpoint.

Question 2

Arrange the steps to create and enforce a Pod Security Policy (PSP) in a Kubernetes cluster.

Accepted Answer

Enable the PodSecurityPolicy admission controller, create a PodSecurityPolicy resource, grant RBAC access to the policy, and verify enforcement by testing a pod.. PSPs require enabling the admission controller, creating the policy, granting access via RBAC, and binding to subjects. Testing confirms enforcement.

Answer

Create a PodSecurityPolicy resource, enable the PodSecurityPolicy admission controller, grant RBAC access, and verify enforcement.

Answer

Grant RBAC access to the PodSecurityPolicy, enable the admission controller, create the policy, and verify enforcement.

Answer

Enable the PodSecurityPolicy admission controller, create a PodSecurityPolicy resource, verify enforcement, and grant RBAC access.

Question 3

Which of the following YAML snippets correctly configures a ServiceAccount with automountServiceAccountToken set to false?

Accepted Answer

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-sa
automountServiceAccountToken: false. It uses the correct field name `automountServiceAccountToken` at the top level of the ServiceAccount spec, which is the proper way to disable automatic mounting of the service account token in pods that use this ServiceAccount. This setting prevents the Kubernetes API token from being automatically injected into pods, enhancing security by reducing the attack surface for token theft.

Answer

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-sa
token:
  automount: false

Answer

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: my-sa
  automountServiceAccountToken: false

Answer

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-sa
  automountServiceAccountToken: false

Question 4

You are using `crictl` to debug a container that is not responding. Which command should you use to get the list of running containers?

Accepted Answer

crictl ps. `crictl ps` is the correct command because it lists running containers managed by the CRI-compatible runtime (e.g., containerd, CRI-O). This is analogous to `docker ps` but for the Kubernetes container runtime interface, allowing you to see container IDs, names, and statuses for debugging.

Answer

crictl pods

Answer

crictl images

Answer

crictl stats

Question 5

You are responding to a security incident where a pod named `compromised-pod` in namespace `default` is suspected of being used for cryptocurrency mining. You need to immediately isolate the pod from the network while preserving evidence. Which command sequence should you use?

Accepted Answer

kubectl label pod compromised-pod isolated=true && kubectl apply -f networkpolicy.yaml. The correct approach is to label the pod and apply a deny-all NetworkPolicy that selects pods with that label. This immediately isolates the pod from all network traffic while preserving the pod for forensic analysis. The command sequence is: kubectl label pod compromised-pod isolated=true && kubectl apply -f networkpolicy.yaml where the networkpolicy.yaml defines an ingress/egress deny-all policy for pods with label isolated=true.

Answer

kubectl cordon <node-of-compromised-pod>

Answer

kubectl delete pod compromised-pod && kubectl describe pod compromised-pod

Answer

kubectl exec compromised-pod -- killall miner-process

Question 6

A cluster has both ImagePolicyWebhook and a mutating webhook that adds a sidecar. The admin notices that even when ImagePolicyWebhook rejects an image, the mutating webhook has already added the sidecar. What admission ordering issue is occurring?

Accepted Answer

Validating webhooks should run before mutating webhooks. In Kubernetes, admission controllers are invoked in a fixed order: mutating admission controllers (including MutatingAdmissionWebhook) run before validating ones (including ImagePolicyWebhook and ValidatingAdmissionWebhook). Therefore, the mutating webhook that adds the sidecar runs before ImagePolicyWebhook validates the image. This means even if ImagePolicyWebhook rejects the image, the sidecar has already been added. The issue is that validating webhooks should run before mutating webhooks to prevent such problems, but the fixed order prevents this. Option B is wrong because using a validating webhook still runs after mutating webhooks. Option C is a workaround but not related to the ordering issue. Option D is incorrect because you cannot change the order of built-in admission controllers; the order is fixed.

Answer

Use a validating webhook instead of ImagePolicyWebhook

Answer

The mutating webhook should be configured to skip pods with certain images

Answer

The ImagePolicyWebhook should be placed before the mutating webhook in the webhook configuration

Question 7

You run kube-bench on a node and it reports a failure for 'Ensure that the --anonymous-auth argument is set to false' for the kubelet service. Which file must you modify to fix this?

Accepted Answer

/var/lib/kubelet/config.yaml. Kube-bench checks the kubelet configuration for the `--anonymous-auth` flag, which is set in the kubelet's configuration file. By default, the kubelet reads its configuration from `/var/lib/kubelet/config.yaml` (or a path specified by `--config` in the kubelet service). Setting `anonymous-auth: false` in this file disables anonymous requests to the kubelet API, enforcing authentication.

Answer

/etc/kubernetes/manifests/kube-apiserver.yaml

Answer

/etc/kubernetes/pki/ca.crt

Answer

/etc/kubernetes/kubelet.conf

Question 8

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 9

You are auditing RBAC and find a ClusterRoleBinding named 'admin-binding' that binds the 'cluster-admin' ClusterRole to a service account in the 'default' namespace. What is the security concern?

Accepted Answer

It grants too broad permissions to the service account. The 'cluster-admin' ClusterRole grants super-user permissions across the entire cluster, including access to all namespaces and all resources. Binding this role to a service account via a ClusterRoleBinding gives that service account unrestricted cluster-wide privileges, which violates the principle of least privilege. This is a significant security concern because if the service account is compromised, an attacker gains full control over the cluster.

Answer

The binding should be a RoleBinding instead of ClusterRoleBinding

Answer

The service account name must be changed

Answer

The binding is fine as long as the service account is used in the default namespace

Question 10

You are a security engineer for a financial services company running a Kubernetes cluster with 50 nodes. The cluster uses containerd as the container runtime and Calico for networking. The security team has detected unusual outbound network connections from a pod running in the 'payments' namespace to an external IP address known to be a command-and-control server. The pod is part of a Deployment named 'payment-processor' with 3 replicas. The cluster has a Falco daemonset deployed with default rules, and audit logging is enabled for the API server. You need to quickly identify the compromised container and contain the threat. Which action should you take FIRST?

Accepted Answer

Identify the node hosting the suspicious pod using 'kubectl get pod -o wide', then SSH to that node and use 'crictl ps' to list containers, then 'crictl stop' the container. It follows the proper incident response workflow for a compromised container: first identify the node hosting the suspicious pod using `kubectl get pod -o wide`, then SSH to that node and use `crictl ps` (the containerd CLI) to list running containers and their IDs, then use `crictl stop` to immediately halt the compromised container. This approach directly isolates the threat at the container runtime level without relying on potentially compromised in-pod tools or deleting the pod (which could be recreated by the Deployment controller).

Answer

Use 'kubectl exec -it <pod> -- bash' to inspect the container, then kill the malicious process from within

Answer

Scale the 'payment-processor' Deployment to 0 replicas to immediately stop all pods

Answer

Check the Falco logs for an alert containing the pod name, then use 'kubectl delete pod' to remove the compromised pod