CKA Practice Test 1 — 30 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

Question 11

A cluster administrator notices that nodes are not joining the cluster after a kubeadm init. The kubelet logs show: 'failed to run Kubelet: could not init service: open /var/lib/kubelet/config.yaml: permission denied'. What is the most likely cause?

Accepted Answer

The kubelet configuration file has incorrect ownership or permissions.. The error message 'open /var/lib/kubelet/config.yaml: permission denied' indicates that the kubelet process does not have the necessary read permissions to access its configuration file. This is typically caused by incorrect file ownership (e.g., owned by root instead of the kubelet user) or restrictive file permissions (e.g., 600 instead of 644). Since kubelet runs as a systemd service, it requires appropriate access to this file to initialize properly.

Answer

The kubelet is running out of disk space.

Answer

The kubelet is not able to reach the API server.

Answer

The kubelet binary is missing.

Question 12

An administrator runs 'kubeadm init' on a machine that previously had a Kubernetes cluster. The command fails with the above errors. What is the best course of action?

Accepted Answer

Run 'kubeadm reset' to clean up the previous installation and then re-run kubeadm init.. When `kubeadm init` fails on a machine that previously hosted a Kubernetes cluster, it is typically because residual configuration files, certificates, and control plane static pod manifests from the prior installation conflict with the new initialization. Running `kubeadm reset` is the official cleanup command that removes these artifacts (e.g., `/etc/kubernetes/`, CNI configurations, and iptables rules), restoring the node to a pre-init state so that `kubeadm init` can succeed cleanly.

Answer

Manually delete the /etc/kubernetes/manifests/kube-apiserver.yaml file and kill the process using port 6443.

Answer

Use a different port for the API server by specifying --apiserver-bind-port.

Answer

Run kubeadm init with --force flag to override the errors.

Question 13

A Service of type ClusterIP is not reachable from within the cluster. Pods backing the Service are running and healthy. What is the most likely cause?

Accepted Answer

kube-proxy not running or misconfigured. When Pods are healthy but a ClusterIP Service is unreachable from within the cluster, the most common cause is that kube-proxy is not running or is misconfigured. kube-proxy is responsible for implementing the ClusterIP virtual IP by programming iptables (or IPVS) rules on each node to forward traffic to the selected Pods. Without these rules, packets destined for the ClusterIP are dropped or rejected, even though the Service and Endpoints objects exist.

Answer

DNS resolution failure

Answer

Ingress controller not set up

Answer

Service type should be NodePort

Question 14

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 15

A pod is stuck in Pending with event '0/4 nodes are available: 1 node(s) had taint "node.kubernetes.io/disk-pressure", and 3 node(s) had taint "node.kubernetes.io/memory-pressure", that the pod didn't tolerate'. What is the best approach to schedule the pod?

Accepted Answer

Free up disk space and reduce memory usage on the affected nodes. The cluster has nodes with disk-pressure and memory-pressure taints. These are typically added by the node controller when resources are low. The pod does not tolerate these taints. The best approach is to free resources on the nodes or add tolerations; however, tolerating pressure taints is not recommended as it can cause further instability. Usually, you should resolve the underlying resource issues.

Answer

Use 'kubectl taint nodes --all node.kubernetes.io/disk-pressure- node.kubernetes.io/memory-pressure-' to remove the taints

Answer

Add tolerations for both taints to the pod spec

Answer

Delete the pod and recreate it with higher resource requests

Question 16

Which of the following are valid methods to debug a failing CoreDNS pod? (Select TWO)

Accepted Answer

kubectl logs -n kube-system -l k8s-app=kube-dns. `kubectl logs -n kube-system -l k8s-app=kube-dns` retrieves the logs from all CoreDNS pods (which are labeled `k8s-app=kube-dns` in the `kube-system` namespace). This is a direct method to inspect errors, crashes, or misconfigurations in the DNS service. Option C is correct because `kubectl get endpoints -n kube-system kube-dns` shows the IP addresses of the pods backing the `kube-dns` service; if the endpoint list is empty, it indicates that no CoreDNS pods are ready to serve DNS requests, which is a common failure point.

Answer

kubectl delete pod -n kube-system -l k8s-app=kube-dns

Answer

kubectl scale deployment coredns --replicas=2

Answer

kubectl run -it --rm test --image=busybox -- nslookup kubernetes.default

Question 17

A node in the cluster is showing status 'NotReady'. You run 'kubectl describe node worker1' and see that the kubelet has not posted node status for more than 1 minute. Which command should you run on the node to check the kubelet logs?

Accepted Answer

journalctl -u kubelet. On systemd-based systems, 'journalctl -u kubelet' is the standard command to view kubelet logs. 'journalctl -f -u kubelet' follows the log, but the question asks for checking logs, not following.

Answer

cat /var/log/kubelet/kubelet.log

Answer

kubectl logs kubelet -n kube-system

Answer

systemctl restart kubelet

Question 18

A pod is in CrashLoopBackOff. The YAML for the initContainer is:

apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  initContainers:
  - name: init
    image: busybox
    command: ['sh', '-c', 'sleep 5 && exit 1']
  containers:
  - name: app
    image: nginx

What is the most likely reason for the CrashLoopBackOff?

Accepted Answer

The init container exits with non-zero exit code. Init containers must complete successfully (exit 0) before the main container starts. An exit code 1 causes the pod to fail and restart.

Answer

The main container image nginx is not pulled successfully

Answer

The init container command is misspelled

Answer

The pod has insufficient memory

Question 19

You suspect the kubelet on a worker node has stopped. Which two commands should you run to confirm the kubelet status and check its logs?

Accepted Answer

systemctl status kubelet and journalctl -u kubelet. To check if the kubelet is running, use 'systemctl status kubelet'. To view logs, use 'journalctl -u kubelet'. The other options target the wrong service or are not applicable.

Answer

systemctl status docker and tail -f /var/log/syslog

Answer

kubectl get nodes and kubectl describe node <node>

Answer

systemctl restart kubelet and journalctl -u containerd

Question 20

A node shows status NotReady. You SSH into the node and run 'systemctl status kubelet' which shows the kubelet is active (running). What is the next most likely step to diagnose the issue?

Accepted Answer

Check kubelet logs with journalctl -u kubelet. Even if the kubelet is running, it may be unhealthy. Checking the kubelet logs with 'journalctl -u kubelet' can reveal errors such as network plugin failures or node pressure.

Answer

Restart the kubelet with systemctl restart kubelet

Answer

Check the container runtime status

Answer

Reboot the node