CKA Practice Test 3 — 10 Questions

Question 1

A user tries to create a pod with the YAML file that requests 2 CPUs as a limit. The cluster has a ResourceQuota named 'compute-quota' with limits.cpu: 2. The user sees the above error. What is the likely issue?

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

Accepted Answer

The current total CPU limit usage in the namespace is 1, and adding a pod with limit 2 would exceed the quota of 2.. The ResourceQuota 'compute-quota' sets a hard limit of 2 CPUs for all pods in the namespace. If the current total CPU limit usage is already 1, adding a new pod with a limit of 2 would bring the total to 3, exceeding the quota. Kubernetes enforces ResourceQuota at admission time, rejecting the pod creation to prevent the namespace from exceeding its configured limits.

Answer

The pod is requesting 2 CPUs as a request, but the quota limits requests.

Answer

The pod is being created in the wrong namespace.

Answer

The pod is trying to use more CPU than the node capacity.

Question 2

A company deploys a web application with multiple replicas in a Kubernetes cluster. Users report intermittent connectivity issues. The application pods are exposed via a ClusterIP Service. To ensure stable connectivity, which action should be taken?

Accepted Answer

Set service.spec.sessionAffinity to ClientIP. Intermittent connectivity issues with multiple replicas often stem from requests being distributed across different pods, which can break session state if the application is not stateless. Setting `service.spec.sessionAffinity` to `ClientIP` ensures that all requests from a given client IP are routed to the same pod, providing stable connectivity for stateful sessions without changing the service type or removing the ClusterIP.

Answer

Change the Service type to NodePort

Answer

Remove the ClusterIP Service and use headless service

Answer

Add a readiness probe to the pods

Question 3

Which TWO of the following are valid reasons to use a Headless Service?

Accepted Answer

To enable a client to discover all pod IPs for a StatefulSet.. A Headless Service (with `clusterIP: None`) does not provide a single stable IP or load balancing. Instead, it returns DNS A/AAAA records for all pod IPs that match the service's selector. This is essential for StatefulSets, where each pod has a unique identity and clients need to discover and connect to specific pods directly, such as in a database cluster.

Answer

To provide a single stable IP address for the service.

Answer

To expose a service externally via a cloud load balancer.

Answer

To provide load-balanced access to a set of pods.

Question 4

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 5

Which command shows resource usage (CPU and memory) for nodes in a cluster?

Accepted Answer

kubectl top nodes. kubectl top nodes displays resource usage if metrics-server is installed.

Answer

kubectl describe nodes

Answer

kubectl logs nodes

Answer

kubectl get nodes -o wide

Question 6

Which TWO actions can help troubleshoot a service that is not reachable from within a pod?

Accepted Answer

Use kubectl exec to curl the service IP from a pod. Checking endpoints and using curl from a pod are direct troubleshooting steps.

Answer

Use kubectl delete svc and recreate

Answer

Use kubectl logs on the service pod to see application logs

Answer

Use kubectl top nodes to check resource usage

Question 7

A pod is unable to start because the PersistentVolumeClaim it references is still in 'Pending' state. What is the most likely cause?

Accepted Answer

The PersistentVolumeClaim's storage class does not exist or cannot provision a volume. A PersistentVolumeClaim (PVC) remains in 'Pending' state when it cannot find a suitable PersistentVolume (PV) to bind to or when its storage class cannot dynamically provision one. The most common cause is that the referenced storage class does not exist, is misspelled, or lacks a provisioner that can create the volume, leaving the PVC unbound and the pod unable to start.

Answer

The pod's YAML has a syntax error

Answer

The pod is using a hostPath volume

Answer

The node has insufficient CPU resources

Question 8

A pod is stuck in Pending state. You run 'kubectl describe pod my-pod' and see the event '0/1 nodes are available: 1 Insufficient cpu'. What is the most likely cause?

Accepted Answer

The pod's CPU request exceeds available node CPU. The event indicates that no node has enough free CPU to satisfy the pod's CPU request.

Answer

The pod's memory limit is too low

Answer

The pod is trying to use a GPU that is not available

Answer

The kubelet on the node is not running

Question 9

A pod is in ImagePullBackOff. Which command would help determine the exact reason?

Accepted Answer

kubectl describe pod . The `kubectl describe pod ` command provides detailed information about the pod, including the container state, the exact error message from the image pull (e.g., 'ImagePullBackOff'), and the underlying reason (e.g., 'Back-off pulling image', 'manifest for image not found', or 'unauthorized: authentication required'). This is the most direct way to see the specific error without needing to access the container or parse raw events.

Answer

kubectl logs <pod>

Answer

kubectl get events

Answer

kubectl exec -it <pod> -- sh

Question 10

A pod is in CrashLoopBackOff. 'kubectl logs my-pod --previous' shows: 'Error: failed to start: exec: "/app/start.sh": stat /app/start.sh: no such file or directory'. What is the most likely cause?

Accepted Answer

The container image is missing the startup script.. The error indicates the specified entrypoint script is missing. This is often due to the container image not containing the script at the expected path, or the command/args in the pod spec referencing a non-existent file.

Answer

The pod's service account lacks permissions.

Answer

The pod's liveness probe is misconfigured.

Answer

The pod has run out of memory.