CKS Practice Questions 1 — 50 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?

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

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

Question 11

You are implementing supply chain security for container images. Which tool would you use to scan a local directory of Dockerfiles and Kubernetes manifests for known vulnerabilities?

Accepted Answer

trivy fs. D is correct because `trivy fs` scans a local filesystem (including directories containing Dockerfiles and Kubernetes manifests) for known vulnerabilities. It parses these files, checks base images against vulnerability databases, and detects misconfigurations or CVEs. This tool is designed for supply chain security, covering both package vulnerabilities and infrastructure-as-code issues. The `fs` subcommand of trivy combines filesystem scanning with configuration analysis, making it suitable for the stated task.

Answer

kubectl scan

Answer

syft

Answer

cosign sign

Question 12

A security admin runs 'trivy image --severity CRITICAL,HIGH myrepo/myapp:latest' and sees many CVEs. The admin wants to ensure that only images with no CRITICAL or HIGH severity vulnerabilities are deployed to the cluster. Which admission controller should be configured to enforce this policy?

Accepted Answer

ImagePolicyWebhook. The ImagePolicyWebhook admission controller is specifically designed to evaluate container images against an external policy backend before they are admitted into the cluster. By configuring it to reject images with CRITICAL or HIGH severity vulnerabilities (as reported by Trivy), the admin can enforce that only compliant images are deployed. This controller intercepts Pod creation requests and queries an external webhook to decide whether to allow or deny the image based on the policy.

Answer

PodSecurityPolicy

Answer

ValidatingAdmissionWebhook

Answer

MutatingAdmissionWebhook

Question 13

Which of the following is a best practice for storing sensitive data like passwords in Kubernetes?

Accepted Answer

Store them in Secrets and mount them as volumes [CORRECT]. Kubernetes Secrets are designed to store sensitive data such as passwords, API keys, and certificates. Mounting a Secret as a volume ensures the data is written to a tmpfs in-memory filesystem (not to disk), reducing the risk of exposure via host filesystem access. This approach also avoids leaking secrets through environment variable dumps or logs, and supports automatic rotation when the Secret is updated.

Answer

Store them in ConfigMaps [wrong]

Answer

Store them as environment variables in the Pod spec [wrong]

Answer

Store them as labels on Pods [wrong]

Question 14

A Falco rule is written to detect when a shell is spawned inside a container. The rule condition is: `spawned_process and container and proc.name = bash`. The rule is not triggering. Which of the following is the most likely reason?

Accepted Answer

The `spawned_process` macro may not match because the process was inherited (not spawned), e.g., from an entrypoint. The `spawned_process` macro in Falco specifically matches processes that are created via `execve` or `fork` system calls. If a shell is inherited from the container's entrypoint (e.g., the container runs `bash` as PID 1 directly), it is not considered a spawned process but rather the initial process of the container. Falco's default `spawned_process` macro filters out such inherited processes, so the rule condition fails to match even though `proc.name = bash` is true.

Answer

The rule is missing `proc.name in (bash, sh, zsh)` because only bash is checked

Answer

Falco is not running with the required syscall capabilities

Answer

The priority is set to `ERROR` but the output is being filtered

Question 15

Which TWO of the following are valid arguments for the kubectl command to create a secret from a file? (Select TWO)

Accepted Answer

--from-file. Options D and E are correct because both --from-file and --from-env-file are valid arguments for the kubectl create secret command when creating a secret from a file. --from-file reads the entire file content and uses the filename as the key. --from-env-file reads a file containing key=value lines, which is suitable for environment variable-style secrets. Option B (--from-literal) is incorrect because it specifies key-value pairs directly on the command line, not from a file. Option A (--dry-run) is a flag, not an argument for specifying secret data. Option C (--from-yaml) is not a valid argument for kubectl create secret.

Answer

--dry-run

Answer

--from-literal

Answer

--from-yaml

Question 16

A pod running in the cluster is in a CrashLoopBackOff state. You run 'kubectl describe pod <pod>' and see the following event: 'Warning BackOff Back-off restarting failed container'. Which command would you run to see the standard error output of the container?

Accepted Answer

kubectl logs --previous. `kubectl logs --previous` retrieves the logs from the previous instance of a crashed or restarting container. When a pod is in CrashLoopBackOff, the current container may have already restarted, so the standard error output from the failed run is only available in the previous container's logs. This command specifically fetches those logs, which typically contain the stderr output that caused the crash.

Answer

kubectl exec <pod> -- cat /var/log/syslog

Answer

kubectl describe pod <pod>

Answer

kubectl logs <pod>

Question 17

Which of the following is a best practice for securing container images?

Accepted Answer

Use distroless base images to minimize the attack surface. Distroless base images contain only the application and its runtime dependencies, omitting package managers, shells, and other utilities that could be exploited. This dramatically reduces the attack surface and aligns with the principle of least functionality, making it a best practice for securing container images in Kubernetes environments.

Answer

Run containers as root to ensure all permissions are available

Answer

Use the 'latest' tag for base images to get the latest features

Answer

Embed secrets directly in the Dockerfile for easy access

Question 18

You want to run a container with gVisor (runsc) runtime for sandboxing. Which resource is required to use a non-default runtime?

Accepted Answer

RuntimeClass resource. In Kubernetes, to use a non-default runtime like gVisor (runsc), you must define a RuntimeClass resource that references the runtime handler (e.g., 'runsc') configured on the node. The RuntimeClass acts as a bridge between the Pod spec and the node's container runtime configuration, allowing the scheduler to select the appropriate runtime for sandboxing. Without a RuntimeClass, the default runtime (typically runc) is used, which does not provide the same isolation level.

Answer

PodSecurityPolicy

Answer

ContainerRuntime resource

Answer

Node runtime configuration only

Question 19

You need to encrypt Kubernetes secrets at rest. Which resource should you configure?

Accepted Answer

EncryptionConfiguration. Kubernetes uses an `EncryptionConfiguration` object to configure encryption at rest for secrets and other resources in etcd. This YAML-based resource defines which providers (e.g., `aescbc`, `kms`, `secretbox`) are used to encrypt data before it is written to the underlying storage. The API server reads this configuration from a file specified via the `--encryption-provider-config` flag, enabling transparent encryption and decryption of resource data.

Answer

EncryptionProvider

Answer

SecretEncryptionConfig

Answer

KMSProvider

Question 20

You need to enforce that all pods in the 'production' namespace run with read-only root filesystems. Which OPA Gatekeeper resource do you create first?

Accepted Answer

A ConstraintTemplate containing a Rego policy that checks for readOnlyRootFilesystem: true. OPA Gatekeeper requires a ConstraintTemplate first to define the Rego policy logic that checks for `readOnlyRootFilesystem: true`. The ConstraintTemplate is a custom resource that tells Gatekeeper what rule to enforce; without it, you cannot create a Constraint to apply the policy to the 'production' namespace. This follows the Gatekeeper workflow: template → constraint → enforcement via admission webhooks.

Answer

A ConfigMap containing the Rego policy, then reference it in a custom admission controller

Answer

A Constraint resource that enforces the readOnlyRootFilesystem rule

Answer

A ValidatingWebhookConfiguration that points to the Gatekeeper service