CKA Quick Quiz — 10 Questions

Question 1

You run `kubectl port-forward service/my-svc 8080:80`. What does this command do?

Accepted Answer

It forwards local port 8080 to port 80 on a Pod selected by the Service, bypassing the Service's ClusterIP.. The `kubectl port-forward` command forwards connections from a local port to a port on a Pod. When you specify a Service (e.g., `service/my-svc`), kubectl automatically selects an active Pod matching the Service's selector and forwards the traffic directly to that Pod. It completely bypasses the Service's ClusterIP and kube-proxy routing.

Answer

It forwards traffic from port 80 to port 8080 within the cluster.

Answer

It creates a LoadBalancer Service on port 8080 forwarding to port 80.

Answer

It exposes the Service on each node's port 8080.

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

A CronJob runs every hour. The job takes 45 minutes to complete. What is the default behavior if the next scheduled time occurs while the previous job is still running?

Accepted Answer

The next job starts immediately, running concurrently. By default, CronJobs in Kubernetes have a concurrencyPolicy of 'Allow'. This means that if a new job is scheduled while a previous job is still running, the new job starts immediately and runs concurrently with the previous one. Option C correctly describes this default behavior. If you want to prevent concurrent executions, you must explicitly set concurrencyPolicy to 'Forbid'.

Answer

The next job is queued and starts after the previous finishes

Answer

The next job is skipped

Answer

The CronJob is suspended

Question 4

Which three are possible reasons for a pod being in Pending state? (Choose three.)

Accepted Answer

PersistentVolumeClaim not bound. Pending means the pod hasn't been scheduled. Reasons include insufficient resources, persistent volume claim not bound, and taints/tolerations mismatch. Image pull issues cause ImagePullBackOff, not Pending.

Answer

Liveness probe failing

Answer

Container image does not exist

Question 5

A pod is configured to use a PersistentVolumeClaim (PVC). The PVC is bound to a PersistentVolume (PV) that uses a cloud disk. The pod fails to start with the error 'MountVolume.SetUp failed for volume ... mount failed: exit status 32'. What is the most likely cause?

Accepted Answer

The underlying storage device is still attached to a previous node. The error 'MountVolume.SetUp failed for volume ... mount failed: exit status 32' typically indicates a filesystem-level mount failure. When a cloud disk (e.g., AWS EBS, GCE PD) is still attached to a previous node, the new node cannot mount it because the disk is already in use or has a stale filesystem lock. Kubernetes requires the disk to be detached from the old node before it can be attached and mounted on the new node.

Answer

The PV's access mode is ReadOnlyMany

Answer

The PV is not created

Answer

The PVC is unbound

Question 6

A pod is stuck in Pending state. You describe the pod and see: '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate.' What is the most likely reason?

Accepted Answer

All nodes in the cluster are NotReady. The error message '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate' indicates that every node in the cluster is tainted with node.kubernetes.io/not-ready, which is automatically applied by the node controller when a node becomes unreachable or fails its health checks. Since no node is Ready, the pod cannot be scheduled, and the only way to schedule it would be to add a toleration for this taint, but that would not fix the underlying node issue. Therefore, the most likely reason is that all nodes are in the NotReady state.

Answer

The pod needs a toleration for node.kubernetes.io/not-ready

Answer

The pod has a resource request that cannot be met

Answer

The scheduler is not running

Question 7

You run 'kubectl get nodes' and one node shows 'NotReady'. You SSH into the node and run 'systemctl status kubelet'. Kubelet is active but 'journalctl -u kubelet -n 50' shows 'network plugin is not ready: cni config uninitialized'. What is the most likely cause?

Accepted Answer

The CNI configuration file is missing or incorrect. The CNI plugin configuration is missing, causing the network plugin to be unready.

Answer

The container runtime is not installed

Answer

Kubelet is not running

Answer

The node's IP address has changed

Question 8

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 9

A team is designing a storage solution for a Cassandra cluster on Kubernetes. Each pod must have its own dedicated storage, and the cluster must be able to scale up and down dynamically. Which Kubernetes resource should be used to manage the storage?

Accepted Answer

StatefulSet with a volumeClaimTemplate. StatefulSet is the correct choice because it provides stable, unique network identities and dedicated storage for each pod via a volumeClaimTemplate. This ensures each Cassandra pod gets its own PersistentVolume, which is essential for stateful applications that require data persistence and ordered scaling. The volumeClaimTemplate automatically provisions a unique PersistentVolumeClaim for each replica, enabling dynamic scaling up and down while preserving data integrity.

Answer

ReplicaSet with emptyDir volumes

Answer

DaemonSet with hostPath volumes

Answer

Deployment with a single PersistentVolume shared by all pods

Question 10

Which THREE of the following are valid commands to troubleshoot network connectivity between pods? (Select 3)

Accepted Answer

kubectl exec pod-a -- nslookup service-name. kubectl exec can run networking tools inside a pod. curl is a common tool. nslookup tests DNS. ping tests basic connectivity.

Answer

kubectl describe node | grep Network

Answer

kubectl logs pod-a | grep network