CKA Practice Test 5 — 25 Questions

Question 1

You have a Service named 'my-service' in namespace 'ns1'. Another pod in namespace 'ns2' needs to resolve 'my-service' using DNS. What FQDN should the pod use?

Accepted Answer

my-service.ns1.svc.cluster.local. Kubernetes DNS resolves services using the FQDN format `..svc.cluster.local`. Since the pod in namespace 'ns2' needs to resolve 'my-service' which resides in namespace 'ns1', the FQDN must include the target namespace 'ns1' to perform a cross-namespace DNS lookup. Omitting the namespace would default to the pod's own namespace, which would fail to resolve the service.

Answer

my-service.svc.cluster.local

Answer

my-service.cluster.local

Answer

my-service.ns2.svc.cluster.local

Question 2

A NetworkPolicy named 'deny-all' has only a podSelector matching all pods and no rules. What is the effect?

Accepted Answer

Denies all ingress traffic to all pods in the namespace. A NetworkPolicy with a podSelector matching all pods and no rules defaults to denying all ingress traffic because the policy's empty `ingress` rules array means no traffic is allowed. This implements a default-deny ingress behavior for the selected pods, as Kubernetes NetworkPolicy rules are whitelist-based: any traffic not explicitly allowed is denied.

Answer

Has no effect because NetworkPolicy requires at least one rule

Answer

Allows all traffic because there are no explicit deny rules

Answer

Denies all egress traffic from all pods in the namespace

Question 3

You want to run a batch job that processes a queue and then terminates. The job should be run only once. Which Kubernetes resource should you use?

Accepted Answer

Job. A Kubernetes Job is designed to run a specified number of pods to completion, making it the correct choice for a batch process that runs once and then terminates. Unlike controllers that maintain a desired state (like Deployments or DaemonSets), a Job tracks pod completion and will not restart the pod once it succeeds, perfectly matching the requirement of a single execution.

Answer

CronJob

Answer

DaemonSet

Answer

Deployment

Question 4

A ClusterIP Service is not reachable from within the cluster. You verify that the Service has endpoints. Which of the following could be the cause? (Select two.)

Accepted Answer

kube-proxy is not running on the node.. Kube-proxy is responsible for implementing ClusterIP Service networking rules (iptables/IPVS) on each node; if it is not running, traffic to the Service's ClusterIP will not be forwarded to endpoints. Option B is correct because if the container is listening on a different port than the Service's targetPort, the connection will fail at the pod level. Option C is incorrect because a failing readiness probe would cause the pod to be removed from the Service's endpoints, contradicting the premise that the Service has endpoints. Option D is incorrect because service name length is not a factor for reachability (max is 63 characters).

Answer

The pod's readiness probe is failing.

Answer

The Service name is too long.

Question 5

You have a Deployment 'db' with 3 replicas. Each pod writes to a PersistentVolumeClaim (PVC). A StatefulSet is required for stable network identities and ordered pod management. Which of the following is a key characteristic that differentiates a StatefulSet from a Deployment?

Accepted Answer

StatefulSets maintain a sticky identity for each pod, including stable hostnames and persistent storage. StatefulSets assign each pod a unique, stable network identity (e.g., a hostname derived from the StatefulSet name and ordinal index) and guarantee that each pod's PersistentVolumeClaim is bound to the same PersistentVolume across rescheduling. This ensures that each pod retains its identity and data, which is critical for stateful applications like databases. Deployments, in contrast, treat pods as interchangeable and do not guarantee stable hostnames or persistent storage binding.

Answer

StatefulSets support rolling updates but not canary deployments

Answer

StatefulSets automatically create a Service for each pod

Answer

StatefulSets cannot use PersistentVolumeClaims

Question 6

You run 'kubectl get pods' and see a pod with status 'CrashLoopBackOff'. You check the logs with 'kubectl logs <pod> --previous' and see: 'Error: unable to connect to database at db-svc:5432 (connection refused)'. What is the most likely cause?

Accepted Answer

The database service is not running or is unreachable. The error message 'connection refused' indicates that the pod is attempting to connect to the database at 'db-svc:5432' but the target service is not accepting TCP connections on port 5432. This typically means the database pod or service is not running, or a network policy is blocking the connection. The 'CrashLoopBackOff' status confirms the application container repeatedly fails due to this startup dependency.

Answer

The pod's liveness probe is misconfigured

Answer

The pod's container image is missing

Answer

The pod has a memory limit that is too low

Question 7

Which command shows all events in the cluster sorted by timestamp?

Accepted Answer

kubectl get events --sort-by=.metadata.creationTimestamp. According to the official Kubernetes Cheat Sheet, the standard and documented command to list events sorted by timestamp is `kubectl get events --sort-by='.metadata.creationTimestamp'`. While modern versions of kubectl apply some default sorting, using the explicit `--sort-by` flag is the precise, guaranteed, and exam-expected method.

Answer

kubectl describe events

Answer

kubectl get events

Answer

kubectl logs --all-namespaces

Question 8

A new Kubernetes administrator runs 'kubeadm join --token

:6443 --discovery-token-ca-cert-hash sha256:' on a worker node. The join fails with 'error execution phase preflight: couldn't validate the identity of the API Server'. What is the most likely cause?

Accepted Answer

The --discovery-token-ca-cert-hash value is incorrect. The error 'couldn't validate the identity of the API Server' indicates that the CA certificate hash provided with --discovery-token-ca-cert-hash does not match the actual hash of the API server's CA certificate. This hash is used to verify the API server's identity during the TLS bootstrap process. An incorrect hash value will cause the preflight check to fail, as the worker node cannot confirm it is connecting to the legitimate control plane.

Answer

The token has expired

Answer

The kubelet is not running on the worker node

Answer

The API server is not reachable on port 6443

Question 9

Which two commands can be used to view the logs of a container that has crashed? (Choose two.)

Accepted Answer

kubectl logs pod-name --previous. To view the logs of a container that has crashed, you can use `kubectl logs pod-name` (Option E) to view the logs of the current container instance (even if it is currently in a terminated or waiting state), or `kubectl logs pod-name --previous` (Option B) to view the logs of the previous instance if the container has restarted.

`journalctl -u kubelet` (Option A) and `systemctl status kubelet` (Option D) show the logs and status of the kubelet system service itself, not the stdout/stderr of individual containers. `kubectl describe pod` (Option C) shows pod events and metadata but does not display the container's stdout/stderr logs.

Answer

journalctl -u kubelet

Answer

kubectl describe pod pod-name

Answer

systemctl status kubelet

Question 10

You are troubleshooting a scenario where a pod cannot communicate with another pod in the same namespace via service name. Which THREE steps would you take to diagnose the issue? (Select 3)

Accepted Answer

Run 'kubectl get endpoints' to verify the service has healthy endpoints. Options B, C, and E are correct. Checking endpoints (B) verifies the service has healthy pods. Exec into the pod and using curl (C) tests connectivity to the service's cluster IP. Exec into the pod and running nslookup (E) checks DNS resolution of the service name. Option A checks node status, which is not directly related to pod-to-pod communication via service name. Option D checks logs of the target pod, which may not reveal network issues.

Answer

Run 'kubectl get nodes' to check node status

Answer

Run 'kubectl logs' on the target pod to check application logs

Question 11

You need to check the status of control plane components. Which TWO commands are appropriate?

Accepted Answer

kubectl get pods -n kube-system. To check the status of control plane components in a kubeadm-established cluster, use 'kubectl get pods -n kube-system' to inspect the static pods. 'kubectl get componentstatuses' (deprecated but still a valid status check) reports health of the control plane components. 'systemctl status kube-apiserver' is not appropriate because the API server runs as a static pod, not a systemd service.

Answer

systemctl status kube-apiserver

Answer

top -u kube

Answer

systemctl list-units --type=service

Question 12

You are troubleshooting a pod that is in 'Pending' state. 'kubectl describe pod' shows '0/1 nodes are available: 1 Insufficient memory, 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate'. Which TWO actions can resolve the issue?

Accepted Answer

Reduce the memory request in the container spec to fit available memory. The pod is pending because the single node in the cluster (0/1 nodes available) has two blocking issues: 1) Insufficient memory to satisfy the pod's request, and 2) a control-plane taint that the pod does not tolerate. To resolve this and allow the pod to schedule on this node, both issues must be addressed: you must reduce the memory request in the container spec to fit the available memory (Option A) AND add a toleration for the control-plane taint to the pod spec (Option E).

Answer

Add a node selector to the pod spec to target a specific node

Answer

Increase the memory request to prioritize scheduling

Answer

Add resource limits without changing requests

Question 13

Which annotation is commonly used to trigger a rollout restart of a Deployment when a ConfigMap is updated?

Accepted Answer

kubectl.kubernetes.io/restartedAt. The annotation `kubectl.kubernetes.io/restartedAt` is commonly used with `kubectl rollout restart` to trigger a rolling restart of a Deployment. When a ConfigMap is updated, Pods using it via `envFrom` or `volumes` are not automatically updated; adding or updating this annotation on the Deployment's pod template forces a new ReplicaSet to be created, picking up the latest ConfigMap data.

Answer

configmap.kubernetes.io/update-trigger

Answer

field.cattle.io/updateStrategy

Answer

kubectl.kubernetes.io/last-applied-configuration

Question 14

You are troubleshooting a node that is in 'NotReady' state. Which command should you use to check the kubelet logs for errors?

Accepted Answer

journalctl -u kubelet. The kubelet is the primary node agent that communicates with the control plane and manages pods. When a node is in 'NotReady' state, checking the kubelet logs is the first step to diagnose issues such as certificate errors, resource pressure, or network problems. The command `journalctl -u kubelet` retrieves logs from the systemd unit for the kubelet service, which is the correct way to view its output on systems using systemd.

Answer

journalctl -u docker

Answer

journalctl -u kube-apiserver

Answer

journalctl -u kube-controller-manager

Question 15

A DevOps engineer is designing a Kubernetes cluster for a production environment. Which of the following is a best practice for etcd deployment?

Accepted Answer

Deploy etcd on dedicated nodes with SSD storage.. Etcd is the Kubernetes cluster's primary data store, and its performance directly impacts the entire cluster's stability and responsiveness. Dedicated nodes prevent resource contention from other workloads, while SSD storage provides the low-latency, high-IOPS performance required for etcd's frequent write operations (especially with the default 1 MB write-ahead log). This isolation is a recommended best practice in the official Kubernetes documentation for production clusters.

Answer

Deploy etcd on exactly 2 nodes for simplicity.

Answer

Deploy etcd on all worker nodes to maximize redundancy.

Answer

Deploy etcd on the same nodes as GPU-accelerated workloads.

Question 16

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?

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 17

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 18

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 19

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 20

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