CKA Practice Exam 53 — 20 Questions

Question 1

Based on the exhibit, what is the most likely cause of the pod not running?

Accepted Answer

The Secret 'my-secret' does not exist in the namespace.. The correct answer is D because the pod's status indicates it is waiting for a secret to be mounted, and the error message 'secret "my-secret" not found' directly points to the missing Secret resource. Without the Secret existing in the same namespace as the pod, the volume mount fails, preventing the pod from starting.

Answer

The volume driver is not installed on node-1.

Answer

The pod has exceeded its resource limits.

Answer

The node 'node-1' is experiencing disk pressure.

Question 2

You need to investigate why a service is not reachable from within the cluster. Which of the following is the first step?

Accepted Answer

Check if the service has endpoints. Option C is correct because the most fundamental check when a service is unreachable from within the cluster is to verify whether the service has any endpoints. A service without endpoints means no pods are matching its selector, so traffic cannot be forwarded regardless of DNS or kube-proxy status. The `kubectl get endpoints <service>` command directly reveals this, making it the logical first step before deeper diagnostics.

Answer

Check kube-proxy logs on the nodes

Answer

Check DNS resolution

Answer

Restart the service

Question 3

You have a pod that is CrashLoopBackOff. The logs show 'error: dial tcp: lookup service.default.svc.cluster.local: no such host'. What is the most likely cause?

Accepted Answer

The service 'service' does not exist in the 'default' namespace. The error message 'no such host' indicates that the DNS lookup for 'service.default.svc.cluster.local' failed because the hostname does not exist. In Kubernetes, this FQDN resolves only if a Service named 'service' exists in the 'default' namespace. Since the lookup fails with 'no such host', the most likely cause is that the Service does not exist, not a DNS infrastructure issue.

Answer

The CoreDNS pod is down

Answer

The pod's DNS policy is set to 'None'

Answer

A network policy is blocking UDP port 53

Question 4

A pod is in CrashLoopBackOff state. Which command should you use to see the logs of the previous instance?

Accepted Answer

kubectl logs -p . When a pod is in CrashLoopBackOff state, the current container instance has crashed and Kubernetes is restarting it. The `-p` flag (or `--previous`) in `kubectl logs` retrieves logs from the previous terminated container instance, which contains the crash output. Option B is correct because `kubectl logs -p ` is the exact syntax to view logs of the previous instance.

Answer

kubectl logs <pod-name>

Answer

kubectl describe pod <pod-name>

Answer

kubectl logs --previous <pod-name>

Question 5

You run kubectl get nodes and see one node is NotReady. The kubelet is running on the node. What is the most likely cause?

Accepted Answer

Network connectivity issue between kubelet and API server. When a node is NotReady but the kubelet is running, the most common cause is a network connectivity issue between the kubelet and the API server. The kubelet reports node status via periodic heartbeats (node-status-update-frequency, default 10s) and if the API server cannot receive these updates due to network problems (e.g., firewall rules, DNS resolution failure, or dropped packets), the node controller marks the node as NotReady after the node-monitor-grace-period (default 40s). The kubelet being running eliminates installation issues, and the API server being down would affect all nodes, not just one.

Answer

The kubelet is not installed

Answer

The node has been cordoned

Answer

The API server is down

Question 6

A user reports that a pod is stuck in 'ContainerCreating' state. Which command would you run first to diagnose the issue?

Accepted Answer

kubectl describe pod <pod-name>. The 'ContainerCreating' state indicates the pod has been scheduled but the container runtime is failing to start the container. `kubectl describe pod` provides detailed events, status conditions, and error messages from the kubelet, such as image pull failures, volume mount errors, or CNI plugin issues, which are the most direct source of diagnostic information for this state.

Answer

kubectl logs <pod-name>

Answer

kubectl get events --watch

Answer

kubectl exec -it <pod-name> -- /bin/sh

Question 7

A pod is running but cannot be accessed via its ClusterIP service from another pod in the same namespace. The service endpoints list shows the pod's IP. What is the most likely cause?

Accepted Answer

A NetworkPolicy is blocking the traffic. Option B is correct because a NetworkPolicy can explicitly deny ingress traffic to a pod even when the service endpoints are correctly populated. Since the endpoints list shows the pod's IP, the service and pod are communicating at the network layer, but a NetworkPolicy with an ingress rule that does not allow traffic from the source pod's labels or CIDR will cause the packet to be dropped by the node's iptables or eBPF rules, resulting in a connection timeout or reset from the client pod.

Answer

The kube-proxy is not running on the node

Answer

The service's targetPort is incorrect

Answer

The pod is running on a different node without proper routing

Question 8

A Node is in NotReady state. Which action should be taken first to diagnose the issue?

Accepted Answer

kubectl describe node . When a node is in NotReady state, the first diagnostic step is to gather information about the node's current status, conditions, and recent events using `kubectl describe node `. This command reveals the node's conditions (e.g., Ready, DiskPressure, MemoryPressure), the last heartbeat timestamp, and any relevant events that may indicate the root cause, such as network issues or kubelet failures. It provides a high-level overview without requiring direct node access, making it the most efficient initial action.

Answer

Check kubelet logs on the node

Answer

Restart kubelet

Answer

Check API server logs

Question 9

A node in your cluster is reporting a DiskPressure condition. Which kubectl command would you use to get details about the node's condition?

Accepted Answer

kubectl describe node . The `kubectl describe node ` command provides detailed information about a node, including its status, capacity, allocatable resources, and a list of conditions (e.g., DiskPressure, MemoryPressure, PIDPressure, Ready). This is the standard way to inspect the exact reason and timestamps for a DiskPressure condition, as well as related metrics like disk usage and inode consumption.

Answer

kubectl get nodes

Answer

kubectl logs <node-name>

Answer

kubectl get events --field-selector involvedObject.kind=Node

Question 10

A pod has status 'Init:Error'. What does this indicate?

Accepted Answer

An init container failed. The 'Init:Error' status indicates that a pod's init container has failed to complete successfully. Init containers run sequentially before any main containers start, and if one exits with a non-zero exit code, the pod enters this error state. This is distinct from a main container crash, which would show as 'CrashLoopBackOff' or 'Error' after the pod has started.

Answer

The main container has crashed

Answer

The pod is being initialized

Answer

There is a network error during initialization

Question 11

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 three.)

Accepted Answer

kube-proxy is not running on the node.. Option A is correct because kube-proxy is the component responsible for implementing the ClusterIP Service networking rules (e.g., iptables or IPVS) on each node. If kube-proxy is not running, traffic destined for the Service's ClusterIP will not be forwarded to the endpoints, even if the Service has valid endpoints. This is a common cause of unreachable Services.

Answer

The Service name is too long.

Question 12

A pod named 'web-frontend' is in CrashLoopBackOff. You run 'kubectl logs web-frontend' and see: 'Error: listen tcp :8080: bind: address already in use'. What is the most likely cause and how should you fix it?

Accepted Answer

The container process is not terminating gracefully; add a preStop hook or use a proper init system to release the port.. The error 'address already in use' indicates the container process is trying to bind to port 8080, but that port is still held by a previous instance of the process that did not release it. This typically happens when the container process does not handle SIGTERM gracefully (e.g., it ignores the signal or takes too long to shut down), so Kubernetes kills it with SIGKILL, leaving the socket in a TIME_WAIT or lingering state. Adding a preStop hook or using a proper init system (like tini or a signal-aware wrapper) ensures the process releases the port before the container stops, preventing the crash loop.

Answer

The NodePort is conflicting; change the service type to ClusterIP.

Answer

The container is missing an environment variable required for startup; add it via ConfigMap.

Answer

The pod has insufficient memory; increase memory limits in the deployment.

Question 13

A user reports that their application cannot resolve DNS names for services in the cluster. The application runs in a pod with dnsPolicy: ClusterFirst. What is the most likely cause?

Accepted Answer

The CoreDNS deployment has 0 ready replicas.. When dnsPolicy is ClusterFirst, the pod's DNS queries are forwarded to the cluster's DNS service (CoreDNS by default). If the CoreDNS deployment has 0 ready replicas, the DNS service has no backend endpoints to handle queries, causing all DNS resolutions to fail. This is the most direct and common cause of complete DNS failure in a cluster.

Answer

The pod's dnsPolicy is set to Default instead of ClusterFirst.

Answer

The node's network plugin is misconfigured, blocking UDP port 53.

Answer

The pod's /etc/resolv.conf contains incorrect nameserver entries.

Question 14

During a cluster upgrade from v1.28 to v1.29, which component should be upgraded first on the control plane node?

Accepted Answer

etcd. During a Kubernetes cluster upgrade, the control plane components must be upgraded in a specific order to maintain cluster stability and API availability. etcd, as the cluster's backing store, should be upgraded first because all other control plane components (kube-apiserver, kube-scheduler, kube-controller-manager) depend on it for reading and writing cluster state. Upgrading etcd first ensures that the data store is compatible with the new version before the API server and other controllers are updated.

Answer

kube-apiserver

Answer

kube-scheduler

Answer

kube-controller-manager

Question 15

A Pod is in Pending state for a long time. 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) had taints that the pod didn't tolerate'. What is the most likely issue?

Accepted Answer

The Pod does not have tolerations for the taints on the nodes.. The event '0/3 nodes are available: 3 node(s) had taints that the pod didn't tolerate' directly indicates that all nodes in the cluster have taints applied, and the Pod's spec does not include corresponding tolerations. Taints and tolerations work together to ensure that Pods are only scheduled onto nodes whose taints they tolerate; without matching tolerations, the scheduler will skip those nodes entirely, leaving the Pod in a Pending state.

Answer

The nodes do not have enough CPU or memory to run the Pod.

Answer

The nodes are not tainted, but the Pod has tolerations.

Answer

The scheduler is not running.

Question 16

A company wants to expose a web application running as a Deployment with 3 replicas to external users. They need a stable IP address that does not change and the ability to terminate TLS. Which resource should they use?

Accepted Answer

Ingress resource with a TLS certificate. An Ingress resource with a TLS certificate is the correct choice because it provides a stable IP address (via the underlying LoadBalancer or NodePort Service) and terminates TLS at the ingress controller, allowing the web application to serve HTTPS traffic without modifying the Deployment. This meets the requirements of exposing the application externally with a fixed IP and TLS termination.

Answer

LoadBalancer Service

Answer

ClusterIP Service

Answer

NodePort Service

Question 17

A developer deployed a Pod that is stuck in Pending state. The cluster has one worker node with taint 'node.kubernetes.io/disk-pressure:NoSchedule'. The Pod does not specify any tolerations. What is the most likely cause?

Accepted Answer

The node has a taint that the Pod does not tolerate.. A Pod stuck in Pending state indicates the scheduler cannot find a suitable node. The cluster has a worker node with the taint 'node.kubernetes.io/disk-pressure:NoSchedule', and the Pod has no tolerations. Since taints with effect NoSchedule prevent scheduling of Pods that do not tolerate them, the Pod cannot be placed on that node, leaving it in Pending.

Answer

The Pod was evicted due to resource pressure.

Answer

The Pod requests more CPU than available on the node.

Answer

The scheduler failed to communicate with the API server.

Question 18

Which command creates a ConfigMap named 'app-config' from a file named 'config.properties'?

Accepted Answer

kubectl create configmap app-config --from-file=config.properties. Option A is correct because the `kubectl create configmap` command with the `--from-file` flag creates a ConfigMap from the contents of a specified file. When you use `--from-file=config.properties`, Kubernetes reads the file and creates a ConfigMap with a single key named after the filename (config.properties) and the file's content as the value. This is the standard method for importing configuration data from a properties file into a ConfigMap.

Answer

kubectl create configmap app-config --from-file=app-config=config.properties

Answer

kubectl create configmap app-config --from-env=config.properties

Answer

kubectl create configmap app-config --from-literal=config.properties

Question 19

Which THREE of the following are valid reasons for a Pod to be in Pending state? (Choose THREE.)

Accepted Answer

The node selector does not match any available node.. A Pod enters Pending state when it cannot be scheduled onto a node. Option A is correct because if the Pod's node selector specifies labels that no node in the cluster possesses, the scheduler cannot find a matching node, leaving the Pod unscheduled and in Pending state.

Answer

The Pod has a restartPolicy of OnFailure and the container exits with code 0.

Answer

The container image does not exist.

Question 20

Which TWO statements about Kubernetes pod lifecycle and scheduling are correct? (Select two.)

Accepted Answer

Init containers always run before app containers and must complete successfully for the pod to start.. Init containers are specialized containers that run before any app containers in a pod. They must complete successfully (exit with code 0) before the pod's app containers are started. If an init container fails, Kubernetes restarts it until it succeeds, and the pod will not enter the Running phase until all init containers have succeeded. This is defined in the pod spec under `initContainers` and is a core mechanism for setup tasks like waiting for a service or database to be ready.

Answer

A pod with a nodeSelector that does not match any node will be evicted from the cluster.

Answer

If a pod with higher priority is pending and there are no resources, it will preempt pods with equal or lower priority.

Answer

Static pods are created by the API server based on a manifest file in the kubelet's manifest directory.

CKA Practice Exam 53 — 20 Questions

Exhibit

CKA Practice Exam 53 — 20 Questions

Exhibit