CKS Practice Questions 2 — 50 Questions

Question 1

You are a security engineer at a fintech startup. The company runs a Kubernetes cluster in production with hundreds of microservices. Recently, a container image from a public registry was compromised, and the attacker injected a backdoor that exfiltrated customer data. The CISO mandates that all images must come from an internal registry that only stores approved, scanned, and signed images. Currently, developers build images locally and push them to Docker Hub, then reference those images in Kubernetes manifests. You have deployed Harbor as a private registry with vulnerability scanning and Cosign for signing. However, you notice that some pods are still running images directly from Docker Hub. You need to enforce that only images from your internal Harbor registry can be used in the cluster. You cannot change the Kubernetes manifests immediately because of a large backlog. You have access to the cluster's kubelet configuration and can modify cluster-level components. Which single action will most effectively block any pod that tries to use an image not hosted on your internal registry?

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

Accepted Answer

Configure the containerd configuration on each node to use Harbor as a mirror for all registries and set endpoint to Harbor only, disabling direct pull from public registries.. Configuring containerd to use Harbor as a mirror for all registries and setting the endpoint to Harbor only effectively blocks pulls from any external registry at the container runtime level. This approach works even if Kubernetes manifests reference Docker Hub images, as the kubelet will redirect all image pull requests to the internal Harbor registry, preventing direct pulls from public registries. It enforces the policy without requiring immediate changes to existing manifests, which aligns with the constraint of not modifying them due to a large backlog. Option D (admission webhook) would require either modification of existing manifests or the webhook to deny pods that do not use the internal registry, but since manifests cannot be changed immediately, this would not affect already running pods unless they are recreated, making it less effective than runtime configuration. Option B (NetworkPolicy) only blocks network traffic but does not prevent the kubelet from pulling images from Docker Hub if the registry is reachable via a different path, and cached images can still be used.

Answer

Enforce a PodSecurityStandard that restricts containers from running with root privileges.

Answer

Apply a Kubernetes NetworkPolicy that blocks egress traffic from nodes to Docker Hub.

Answer

Deploy an admission webhook (e.g., OPA/Gatekeeper) that denies pods whose image registry is not the internal Harbor.

Question 2

Order the steps to perform a Kubernetes cluster upgrade from version 1.24 to 1.25.

Accepted Answer

Upgrade kubeadm, then Drain the node, then Upgrade kubelet and kubectl, then Uncordon the node. Upgrade involves upgrading kubeadm, draining, applying upgrade, upgrading worker nodes, and verifying.

Answer

Drain the node, then Upgrade kubeadm, then Upgrade kubelet and kubectl, then Uncordon the node

Answer

Upgrade kubeadm, then Upgrade kubelet and kubectl, then Drain the node, then Uncordon the node

Answer

Upgrade kubeadm, then Drain the node, then Uncordon the node, then Upgrade kubelet and kubectl

Question 3

Which command creates a validating webhook configuration that checks all pods in the cluster?

Accepted Answer

kubectl create validatingwebhookconfiguration my-webhook --from-file=webhook.yaml. `kubectl create validatingwebhookconfiguration` is the specific command to create a ValidatingWebhookConfiguration resource from a YAML file, which can be configured to intercept and validate pod creation requests across the cluster. This resource allows you to define a webhook that checks all pods before they are admitted, enforcing custom validation logic.

Answer

kubectl create mutatingwebhookconfiguration my-webhook --from-file=webhook.yaml

Answer

kubectl run webhook --image=webhook

Answer

kubectl apply -f webhook.yaml --validating

Question 4

Which TWO of the following are correct about container sandboxing technologies? (Select TWO)

Accepted Answer

Kata Containers run containers in lightweight VMs, providing hardware-level isolation.. Kata Containers provide hardware-level isolation by running each container or pod in a lightweight VM with its own guest kernel using KVM. Option B is correct because gVisor implements a user-space kernel (called Sentry) that intercepts system calls, providing a kernel-level sandbox without dedicated VMs. Option C is incorrect because Kata Containers use a guest kernel, not the host kernel. Option D is incorrect because gVisor does not run containers in separate VMs; it runs as a kernel within the user space. Option E is incorrect because although RuntimeClass is commonly used to select non-default runtimes in Kubernetes, the statement is not universally required; it is a mechanism but not a strict requirement for using these technologies, making the claim that both 'require' RuntimeClass too absolute and thus false.

Answer

Kata Containers use the host kernel for system calls.

Answer

gVisor runs containers in separate VMs for each pod.

Answer

Both gVisor and Kata Containers require RuntimeClass to be used in Kubernetes.

Question 5

A pod runs with a service mesh sidecar (Istio). The team wants to enforce mutual TLS (mTLS) for all traffic between services in the 'production' namespace. Which resource should be applied?

Accepted Answer

PeerAuthentication with mode: STRICT in the namespace. PeerAuthentication with mode: STRICT enforces mutual TLS at the service mesh level by requiring all traffic within the namespace to use TLS certificates for both sides of the connection. This is the correct Istio resource to enforce mTLS for all services in the 'production' namespace, as it sets a namespace-wide policy that overrides any permissive defaults.

Answer

DestinationRule with trafficPolicy: tls: mode: ISTIO_MUTUAL

Answer

VirtualService with TLS settings

Answer

ServiceEntry with mTLS enabled

Question 6

Which ONE of the following is a valid Rego policy construct used in OPA Gatekeeper ConstraintTemplates to enforce security policies?

Accepted Answer

violation[{"msg": msg}] { condition }. In OPA Gatekeeper ConstraintTemplates, the only Rego construct that directly triggers a constraint violation is `violation[{"msg": msg}] { condition }`. When the condition evaluates to true, Gatekeeper generates a violation message. The `allow` and `deny` rules are not standard constructs for enforcing constraints in Gatekeeper; they are general Rego rules used in other OPA contexts but not within ConstraintTemplates to report violations. Options D (`audit`) and E (`warn`) are also not valid Rego constructs for Gatekeeper constraints.

Answer

allow { condition }

Answer

deny[{"msg": msg}] { condition }

Answer

audit { condition }

Answer

warn[{"msg": msg}] { condition }

Question 7

A pod uses a Secret mounted as a volume. The Secret is updated. How can the pod consume the updated values without restarting?

Accepted Answer

The mounted volume is automatically updated over time. When a Secret is mounted as a volume in Kubernetes, the kubelet periodically syncs the secret data from the API server and updates the files in the volume. This means the pod can consume the updated values without needing a restart, as the files are refreshed automatically (with a default sync period of around 60 seconds). Option C correctly identifies this behavior.

Answer

Use a sidecar container that watches for changes and reloads the application

Answer

Update the pod spec to reference a new Secret version

Answer

Delete and recreate the pod

Question 8

You need to drop all Linux capabilities from a container. Which YAML snippet is correct?

Accepted Answer

securityContext: { capabilities: { drop: ["ALL"] } }. In Kubernetes, to drop Linux capabilities from a container, you must use the `capabilities.drop` field inside `securityContext`. Option D correctly nests `capabilities` under `securityContext`. Option B is incorrect because it places `capabilities` directly under the container spec without the `securityContext` wrapper, which is not valid in most Kubernetes API versions. Options A and C use invalid keywords (`remove` and `none`). Therefore, only Option D is correct.

Answer

capabilities: { remove: ["ALL"] }

Answer

capabilities: { drop: ["ALL"] }

Answer

capabilities: { none: true }

Question 9

A pod is failing with status 'CrashLoopBackOff'. The pod manifest includes a liveness probe that runs every 10 seconds. You suspect the probe is causing the crash. Which command would you use to verify the liveness probe configuration?

Accepted Answer

kubectl describe pod . `kubectl describe pod ` displays the pod's full configuration, including the liveness probe's exact parameters (e.g., initialDelaySeconds, periodSeconds, failureThreshold, and the probe action like HTTP GET, TCP socket, or exec command). This allows you to verify if the probe is misconfigured (e.g., too aggressive or pointing to a non-existent endpoint) and causing the CrashLoopBackOff.

Answer

kubectl logs <pod>

Answer

kubectl exec <pod> -- cat /etc/kubernetes/manifests/pod.yaml

Answer

kubectl get pod <pod> -o yaml

Question 10

An admin runs 'kubectl run test-pod --image=busybox --command -- sleep 3600' and then executes 'kubectl exec test-pod -- cat /var/run/secrets/kubernetes.io/serviceaccount/token'. The admin wants to prevent such access to the service account token. What is the correct action?

Accepted Answer

Set automountServiceAccountToken: false in the pod spec. Setting `automountServiceAccountToken: false` in the pod spec prevents the automatic mounting of the service account token into the container's filesystem. By default, Kubernetes mounts a token at `/var/run/secrets/kubernetes.io/serviceaccount/token`, which can be read via `kubectl exec` as shown. Disabling this mount blocks direct access to the token from within the pod, mitigating the risk of token theft or misuse.

Answer

Remove the service account from the pod

Answer

Set securityContext.runAsNonRoot: true

Answer

Use a NetworkPolicy to block access to the API server

Question 11

You need to encrypt secrets at rest in a Kubernetes cluster. What must be configured?

Accepted Answer

Create an EncryptionConfiguration object in the cluster and pass it to kube-apiserver via --encryption-provider-config. Kubernetes encrypts secrets at rest by defining an EncryptionConfiguration object that specifies which encryption providers (e.g., AES-CBC, secretbox, or KMS) to use, and then passing the configuration file to the kube-apiserver via the `--encryption-provider-config` flag. This ensures that when the API server writes secrets to etcd, they are encrypted before storage, and decrypted on read, meeting the requirement for encrypting secrets at rest.

Answer

Set the environment variable ENCRYPT_SECRETS=true on the kube-controller-manager

Answer

Use a MutatingWebhookConfiguration to encrypt secrets before storage

Answer

Enable the 'SecretEncryption' feature gate on all control plane components

Question 12

A development team uses a custom container image for their application, built from a base image that includes multiple CVEs. The security team requires that no container runs with known critical vulnerabilities. Which approach best ensures that only images with no critical vulnerabilities are deployed in production?

Accepted Answer

Integrate an image scanner (e.g., Trivy) into the CI/CD pipeline to block builds with critical vulnerabilities.. Integrating an image scanner like Trivy into the CI/CD pipeline ensures that any image with critical vulnerabilities is blocked before it is even built or pushed to a registry. This shift-left approach prevents vulnerable images from ever reaching the production environment, aligning with the security team's requirement to deploy only images with no critical vulnerabilities.

Answer

Configure a Kubernetes admission controller (e.g., Kyverno) to reject pods using images with critical vulnerabilities.

Answer

Scan the base image before building the application image.

Answer

Manually review vulnerability reports after the image is deployed.

Question 13

Which ONE of the following is a valid method to restrict a container's filesystem to read-only in Kubernetes?

Accepted Answer

Set readOnlyRootFilesystem: true in the container's securityContext. The only valid method listed. Setting `readOnlyRootFilesystem: true` in the container's securityContext directly makes the container's root filesystem read-only. Options A, B, and D only make specific volumes read-only (ConfigMap, hostPath, emptyDir), but do not prevent writes to the container's own filesystem (e.g., /etc, /tmp, /var). Therefore, only option C correctly restricts the container's filesystem to read-only.

Answer

Use a ConfigMap volume with defaultMode 0444

Answer

Set readOnly: true on a hostPath volume mount

Answer

Mount an emptyDir volume with readOnly: true

Question 14

A team wants to use an external secret manager (HashiCorp Vault) to inject secrets into pods. Which approach is most aligned with Kubernetes best practices?

Accepted Answer

Use a mutating webhook that injects a sidecar container to fetch secrets and mount them as volumes. It follows the Kubernetes best practice of using a mutating admission webhook to inject a sidecar container (e.g., Vault Agent or Bank-Vaults) that authenticates with HashiCorp Vault, fetches secrets, and mounts them as volumes into the pod. This approach avoids storing secrets in etcd (as ConfigMaps or environment variables do) and eliminates the need for manual secret injection, aligning with the principle of least privilege and dynamic secret management.

Answer

Use a ConfigMap to mount secrets as files

Answer

Store secrets as environment variables in the pod spec

Answer

Use kubectl exec to copy secrets into the container at startup

Question 15

During a runtime incident, you suspect a container has a reverse shell. Which kubectl command can you use to examine the container's running processes?

Accepted Answer

kubectl exec -- ps aux. `kubectl exec -- ps aux` runs the `ps aux` command inside the container, which lists running processes. It is the only kubectl command that allows you to inspect container processes. Options A, C, and D do not provide process listings.

Answer

kubectl logs <pod-name>

Answer

kubectl top pod <pod-name>

Answer

kubectl describe pod <pod-name>

Question 16

You need to configure Kubernetes audit logging to log all requests to the 'secrets' API. Which audit policy level captures the body of the request?

Accepted Answer

Request. The 'Request' audit level logs the request metadata and the request body, which includes the body of the request. This is exactly what the question asks for. 'RequestResponse' adds the response body, which is not required per the question. Therefore, the correct answer is A.

Answer

None

Answer

RequestResponse

Answer

Metadata

Question 17

An administrator wants to enable audit logging on the API server. Which three flags are required to set up basic audit logging?

Accepted Answer

--audit-log-maxage=30. For basic audit logging in Kubernetes, three flags are required: `--audit-log-path` specifies the file path for audit logs, `--audit-policy-file` defines the policy controlling which events are logged, and `--audit-log-maxage` sets the retention period in days. These ensure logging is enabled, filtered, and rotated. The `--audit-log-format` flag is optional because JSON is the default, and `--audit-log-maxbackup` and `--audit-log-maxsize` can be added but are not required for basic setup.

Answer

--audit-log-format=json

Question 18

Which tool can be used to generate an SBOM (Software Bill of Materials) for a container image?

Accepted Answer

syft. Syft is a CLI tool specifically designed to generate a Software Bill of Materials (SBOM) from container images and filesystems. It uses static analysis to catalog packages (e.g., APK, DEB, RPM, Python, Java) and outputs the SBOM in formats like SPDX or CycloneDX, which are industry standards for supply chain transparency. This makes it the correct choice for generating an SBOM from a container image in a CKS context.

Answer

trivy

Answer

kubesec

Answer

checkov

Question 19

You have a requirement to encrypt secrets at rest in etcd. Which resource and apiVersion should be used?

Accepted Answer

EncryptionConfiguration with apiVersion apiserver.config.k8s.io/v1. The Kubernetes API server uses an `EncryptionConfiguration` resource with `apiVersion apiserver.config.k8s.io/v1` to define how secrets and other resources are encrypted at rest in etcd. This resource specifies providers (e.g., `aescbc`, `secretbox`) and keys, and is loaded via the `--encryption-provider-config` flag on the API server. The `v1` version is the stable, production-ready API version for this configuration.

Answer

EtcdEncryption with apiVersion apiserver.config.k8s.io/v1beta1

Answer

EncryptionConfig with apiVersion v1

Answer

SecretEncryption with apiVersion v1

Question 20

A pod is running with AppArmor enabled using a profile named 'k8s-apparmor-profile'. You want to verify that the profile is loaded and set to enforce mode. Which command should you run on the node?

Accepted Answer

aa-status. `aa-status` is the standard AppArmor utility that displays the status of AppArmor, including which profiles are loaded and their enforcement mode (enforce, complain, or unconfined). Running this command on the node will show whether 'k8s-apparmor-profile' is loaded and set to enforce mode, which directly answers the verification requirement.

Answer

aa-profile --status

Answer

aa-enabled

Answer

cat /sys/kernel/security/apparmor/profiles