CKA Practice Test 12 — 15 Questions

Question 1

A StatefulSet named 'db' has 3 replicas. You need to update the pod template to change the resource limits. After applying the change, you run 'kubectl rollout status sts db' and it hangs. What is the most likely reason?

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

Accepted Answer

The StatefulSet's pod management policy is OrderedReady, and the first pod to update (db-2) is not becoming Ready.. StatefulSets with the default OrderedReady pod management policy update pods sequentially in reverse order (from highest ordinal to lowest). When `kubectl rollout status sts db` hangs, it indicates that the update is stuck waiting for the first pod in the update sequence (db-2) to become Ready. If db-2 fails to become Ready due to the new resource limits (e.g., insufficient cluster resources or misconfigured limits), the rollout cannot proceed to update db-1 and db-0, causing the command to hang indefinitely.

Answer

The update strategy is set to OnDelete, and you need to delete pods manually.

Answer

The maxSurge setting is preventing the update from starting.

Answer

The StatefulSet's service name is incorrect, causing DNS resolution failures.

Question 2

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The 'OOMKilled' status indicates that the container was terminated because it exceeded its memory limit. Since the pod ran successfully for days before crashing, the most likely cause is a memory leak or increased workload demand. Increasing the memory limit in the container's resource specification allows the pod to use more memory without being killed, directly addressing the root cause.

Answer

Increase the CPU request for the container

Answer

Delete and recreate the pod to clear the crash loop

Answer

Delete the namespace and redeploy all workloads

Question 3

A Kubernetes cluster was upgraded from v1.28 to v1.29. After the upgrade, nodes report NotReady. You check kubelet logs and see: 'error: failed to run Kubelet: misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"'. What is the most likely cause?

Accepted Answer

The kubelet configuration has a different cgroup driver than the container runtime. The error message explicitly states that the kubelet's cgroup driver (systemd) differs from the container runtime's cgroup driver (cgroupfs). In Kubernetes, the kubelet and the container runtime must use the same cgroup driver to manage resource limits correctly. After upgrading from v1.28 to v1.29, the kubelet configuration may have been reset or changed, causing this mismatch, which prevents the kubelet from starting and the node from becoming Ready.

Answer

The container runtime version is incompatible with Kubernetes v1.29

Answer

The kubelet cannot connect to the API server

Answer

The kubelet was not restarted after the upgrade

Question 4

A StatefulSet named 'web' has 3 replicas. You need to update the container image from 'nginx:1.19' to 'nginx:1.20' using a rolling update with ordered pod management. What must you ensure in the StatefulSet spec?

Accepted Answer

Set spec.podManagementPolicy to OrderedReady (default). For a StatefulSet to perform a rolling update with ordered pod management (pods updated one at a time in reverse ordinal order), the podManagementPolicy must be set to OrderedReady. This is the default policy and ensures that pods are created, deleted, and updated in a strict sequential order, maintaining the stable identity and startup ordering required by stateful applications.

Answer

Set spec.updateStrategy.rollingUpdate.maxSurge to 1

Answer

Set spec.updateStrategy.rollingUpdate.partition to 0

Answer

Set spec.podManagementPolicy to Parallel

Question 5

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. OOMKilled means the container exceeded its memory limit and was killed by the kernel OOM killer. The solution is to increase the memory limit in the container's resource specification. Option A would delete the namespace and all workloads, which is too drastic and would affect other pods. Option B increases CPU request, which does not address the memory issue. Option D deletes and recreates the pod without fixing the resource limits, so the crash loop would continue.

Answer

Delete the namespace and redeploy all workloads

Answer

Increase the CPU request for the container

Answer

Delete and recreate the pod to clear the crash loop

Question 6

You have a pod named 'web-pod' that is in a CrashLoopBackOff state. To examine the logs from the previous instance of the container, which command should you use?

Accepted Answer

kubectl logs web-pod --previous. The correct command is kubectl logs web-pod --previous (Option A). This retrieves the logs from the previous instance of the container, which is essential when a pod is in CrashLoopBackOff because the container has restarted and the current logs may be empty or not show the error from the previous run. Option B uses kubectl exec to read a log file, but it does not access previous logs and requires the container to be running. Option C shows pod details but not logs. Option D shows current logs only, which may not capture the crash reason.

Answer

kubectl exec web-pod -- cat /var/log/app.log

Answer

kubectl describe pod web-pod

Answer

kubectl logs web-pod

Question 7

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The pod is in CrashLoopBackOff with an OOMKilled message, which means the container was terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it exceeded its memory limit. The correct fix is to increase the memory limit in the container's resource specification, allowing the container to use more memory without being killed. Simply deleting and recreating the pod would not resolve the underlying memory constraint, and adjusting CPU or deleting the namespace are irrelevant actions.

Answer

Increase the CPU request for the container

Answer

Delete and recreate the pod to clear the crash loop

Answer

Delete the namespace and redeploy all workloads

Question 8

Which volume type in Kubernetes allows a Pod to share data between its containers, with the data being deleted when the Pod is removed?

Accepted Answer

emptyDir. The emptyDir volume type is created when a Pod is assigned to a node and exists as long as the Pod is running. It provides a shared writable directory for all containers within the same Pod, and its contents are deleted when the Pod is removed from the node. This makes it the correct choice for ephemeral data sharing between containers.

Answer

hostPath

Answer

configMap

Answer

secret

Question 9

A developer wants to mount a ConfigMap as a volume in a pod. However, the pod should only see specific keys from the ConfigMap, not all keys. What is the best approach?

Accepted Answer

Use the 'items' field in the ConfigMap volume definition to specify which keys to include.. The `items` field in a ConfigMap volume definition allows you to selectively project only specific keys from the ConfigMap into the pod's filesystem. This is the native Kubernetes mechanism for controlling which keys appear as files, avoiding the need to mount the entire ConfigMap or create a separate ConfigMap.

Answer

Use the ConfigMap to set environment variables instead of a volume mount.

Answer

Mount the entire ConfigMap and use a startup script to remove unwanted files.

Answer

Create a new ConfigMap with only the needed keys.

Question 10

A pod cannot resolve a service DNS name. The cluster uses CoreDNS. Which of the following is the most likely cause if the pod's /etc/resolv.conf contains 'nameserver 10.96.0.10' and the CoreDNS pod is running?

Accepted Answer

The CoreDNS ConfigMap does not have the correct cluster domain.. If the CoreDNS ConfigMap does not specify the correct cluster domain (e.g., `cluster.local`), CoreDNS will not respond to queries for service DNS names within that domain. The pod's `resolv.conf` shows the correct ClusterIP of the CoreDNS service (10.96.0.10), and the CoreDNS pod is running, so the issue is likely a misconfiguration in the CoreDNS plugin settings, specifically the `kubernetes` plugin's `clusterDomain` parameter.

Answer

The pod's DNS policy is set to 'Default'.

Answer

The CoreDNS pod is in CrashLoopBackOff.

Answer

The service's DNS name is misspelled.

Question 11

You are a CKA managing a production cluster with 5 worker nodes. A developer reports that a new deployment 'payment-service' is not accessible from other pods via its Service 'payment-svc' in the 'default' namespace. The Service is of type ClusterIP with selector 'app: payment'. The deployment has 3 replicas, all showing 'Running' status. From a test pod, you run 'curl http://payment-svc:8080' and get 'Connection refused'. You verify that the pods are listening on port 8080 and the container's readiness probe passes. 'kubectl get endpoints payment-svc' shows no endpoints. 'kubectl describe svc payment-svc' shows the selector 'app=payment'. What is the most likely cause?

Accepted Answer

The pods have label 'app: payment-service' instead of 'app: payment', so the service selector does not match.. The most likely cause is that the pods' labels do not match the Service's selector. The Service 'payment-svc' uses selector 'app: payment', but the pods have label 'app: payment-service'. Since the selector does not match any pods, the Service's endpoints list is empty, causing 'Connection refused' when trying to reach the ClusterIP. The pods are running and listening on port 8080, but the Service has no backends to forward traffic to.

Answer

A NetworkPolicy is blocking traffic from the test pod to the service IP.

Answer

The service type should be NodePort to allow in-cluster access.

Answer

The readiness probe is failing on all pods, causing them to be removed from service endpoints.

Question 12

Which kubeconfig context field defines the set of users, clusters, and namespaces for kubectl operations?

Accepted Answer

contexts. The `contexts` field in a kubeconfig file defines a named context that bundles together a specific cluster, user, and default namespace. When you run `kubectl` commands, the current context determines which cluster to authenticate against, which user credentials to use, and which namespace to operate in by default. This is why option A is correct.

Answer

namespaces

Answer

clusters

Answer

users

Question 13

A cluster has multiple namespaces: 'frontend', 'backend', and 'monitoring'. A pod in the 'frontend' namespace needs to reach a Service named 'db-service' in the 'backend' namespace. The 'db-service' Service is of type ClusterIP. Which DNS name should the pod use?

Accepted Answer

db-service.backend.svc.cluster.local. Kubernetes DNS resolves services using the format `..svc.cluster.local`. Since the pod is in the 'frontend' namespace and needs to reach 'db-service' in the 'backend' namespace, the fully qualified domain name (FQDN) must include the namespace and the 'svc' subdomain to be resolved by the cluster DNS (CoreDNS).

Answer

db-service.svc.cluster.local

Answer

db-service

Answer

db-service.backend.cluster.local

Question 14

An administrator needs to expand an existing PersistentVolumeClaim. Which TWO conditions must be met?

Accepted Answer

The StorageClass used by the PVC must have 'allowVolumeExpansion: true'.. The StorageClass must have `allowVolumeExpansion: true` to permit resizing of a PersistentVolumeClaim. This field is a prerequisite in the StorageClass definition; without it, the PVC cannot be expanded even if the underlying volume supports resizing. The CKA exam expects you to know that volume expansion is gated by this StorageClass setting.

Answer

The PVC must be currently mounted by at least one pod.

Answer

The underlying PersistentVolume must be deleted first.

Answer

The PersistentVolume's reclaim policy must be Recycle.

Question 15

A StorageClass named 'fast-ssd' uses the provisioner 'kubernetes.io/gce-pd' and has volumeBindingMode: WaitForFirstConsumer. A PVC 'my-pvc' requests 100Gi storage from this StorageClass. A pod using the PVC is scheduled to a node in zone 'us-central1-a'. When is the PV provisioned?

Accepted Answer

When the pod is scheduled to a node. The StorageClass 'fast-ssd' has volumeBindingMode set to WaitForFirstConsumer. This mode delays volume binding and provisioning until a pod using the PVC is scheduled to a node. When the pod is scheduled to a node in zone 'us-central1-a', the scheduler triggers the provisioning of a PV in that specific zone, ensuring the volume is created in the same zone as the pod.

Answer

Immediately when the PVC is created

Answer

When the pod starts running

Answer

The PV is never provisioned automatically; it must be pre-created