How many Troubleshooting Scenario Questions questions are on this page?

This page has 15 Troubleshooting Scenario Questions scenario questions for the CKA exam, each with detailed explanations and wrong-answer analysis.

How should I approach CKA scenario questions?

Read the full scenario before looking at the answer options. Identify the constraint or requirement in the scenario, then eliminate options that are generally true but wrong for this specific case. Scenario questions reward careful reading over pattern matching.

← Back to Certified Kubernetes Administrator CKA questions

Scenario-based practice

Troubleshooting Scenario Questions

Practise Certified Kubernetes Administrator CKA practice questions — original exam-style scenarios covering every exam domain, with detailed explanations, wrong-answer analysis, and common exam traps.

Start full practice test Read exam guide

scenario questions

CKA

exam code

CNCF

vendor

Scenario guide

How to approach troubleshooting scenario questions

These questions describe a network symptom and ask you to identify the root cause or the correct fix. They appear across all certification exams and reward systematic thinking over memorisation. The best candidates follow a consistent troubleshooting framework even under time pressure.

Quick answer

Troubleshooting Scenario Questions questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Practice scenarios

Question 1hardmultiple choice

Full question →

You are tasked with troubleshooting a web application that is deployed in a Kubernetes cluster. The application consists of a Deployment named 'web-app' with 3 replicas, each running a container that listens on port 3000. A Service named 'web-service' of type ClusterIP with selector 'app: web' and port 80 targeting port 3000 has been created. Additionally, an Ingress resource named 'web-ingress' is configured with a host rule for 'example.com' and backend service 'web-service' on port 80. Users report that accessing http://example.com results in a 503 Service Unavailable error. You verify that all pods are running and ready (kubectl get pods shows 3/3 ready). The Ingress controller logs show 'upstream connect error or disconnect/reset before headers'. You check the endpoints: 'kubectl get endpoints web-service' shows no endpoints. The pods have the label 'app: web'. What should you do to resolve the issue?

A
Change the Service type to NodePort to bypass the Ingress.
Why wrong: Changing Service type does not affect endpoint creation; the root cause is missing endpoints.
B
Update the Ingress to use a different backend service.
Why wrong: The Ingress is correctly configured; the issue is with the Service itself.
C
Check the container port and readiness probe configuration; the pods may not be listening on the expected port or the readiness probe is failing.
Empty endpoints indicate no ready pods matching the selector; despite 'Ready' status, the readiness probe might be failing if not configured, or the container might not be listening on 3000.
D
Modify the Service selector to match the pod labels exactly.
Why wrong: The selector already matches 'app: web'; this would not change anything.

Full breakdown with real-world context →

Question 2easymultiple choice

Full question →

An administrator is tasked with setting up a new Kubernetes cluster using kubeadm. They have two nodes: one control plane and one worker. After initializing the control plane with 'kubeadm init', the worker node fails to join with the error 'error execution phase preflight: [preflight] Some fatal errors occurred: [ERROR CRI]: container runtime is not running'. What should the administrator check first?

A
Ensure that containerd is installed and running on the worker node.
The CRI error indicates the runtime is not running.
B
Verify that the control plane node is healthy.
Why wrong: The error is on the worker node.
C
Check if the join token has expired.
Why wrong: Token expiry would give a different error.
D
Install a network plugin like Calico on the control plane.
Why wrong: Network plugin is not related to CRI error.

Full breakdown with real-world context →

Question 3easymulti select

Full question →

Which TWO commands show cluster events that can help in troubleshooting?

A
kubectl cluster-info
Why wrong: Shows cluster endpoints, not events.
B
kubectl logs <pod-name>
Why wrong: Shows container logs, not events.
C
kubectl top pods
Why wrong: Shows resource usage, not events.
D
kubectl describe pod <pod-name>
Includes events related to the pod.
E
kubectl get events
Lists recent events in the cluster.

Full breakdown with real-world context →

Question 4mediummatching

Full question →

Match each troubleshooting scenario to its likely cause.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Insufficient resources or unschedulable Node

Application crashes repeatedly

Missing or incorrect Endpoint selector labels

Kubelet not reporting or network issue

Invalid image name or registry authentication failure

Question 5mediummultiple choice

Full question →

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?

A
Change the Service type to NodePort
Why wrong: NodePort exposes the service externally but does not affect internal session stickiness.
B
Set service.spec.sessionAffinity to ClientIP
ClientIP session affinity ensures requests from the same client are routed to the same pod, resolving intermittent connectivity due to session state.
C
Remove the ClusterIP Service and use headless service
Why wrong: Headless service returns pod IPs directly, which may cause DNS caching issues and worsen connectivity.
D
Add a readiness probe to the pods
Why wrong: Readiness probes ensure pods are ready but do not provide session stickiness.

Full breakdown with real-world context →

Question 6mediumdrag order

Full question →

Drag and drop the steps to troubleshoot a CrashLoopBackOff pod into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Question 7mediumdrag order

Full question →

Drag and drop the steps to troubleshoot a Node that is in NotReady state into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Question 8hardmultiple choice

Full question →

A DevOps engineer notices that the kubelet on a node is unable to register with the Kubernetes API server. The kubelet logs show 'Failed to get bootstrap CA certificate' and the node is not yet part of the cluster. What is the most likely cause?

A
The kubelet configuration file has incorrect node IP.
Why wrong: That would cause connection issues, not bootstrap CA failure.
B
The node's RBAC permissions are misconfigured.
Why wrong: RBAC is checked after the node is registered.
C
The API server is not running.
Why wrong: The API server is assumed running if the kubelet can connect.
D
The bootstrap token used for TLS bootstrapping has expired.
Expired token prevents CA certificate retrieval.

Full breakdown with real-world context →

Question 9mediummultiple choice

Full question →

A pod is failing with 'CrashLoopBackOff'. You run 'kubectl logs mypod' and see no output. What is the first troubleshooting step?

Question 10hardmultiple choice

Full question →

You are troubleshooting a pod that is in 'Pending' state. Running 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate.' What is the most likely cause?

A
The pod requires more CPU than any node can provide
Why wrong: The event specifically mentions taint, not resource constraints.
B
The pod is using a hostPort that conflicts with another pod
Why wrong: HostPort conflict would show a different event.
C
The pod has a node selector that doesn't match any node
Why wrong: No node selector is mentioned; the event is about taints.
D
The pod is trying to schedule on the master node which has a taint that is not tolerated
Master nodes typically have a taint to prevent non-system pods from scheduling. The pod must have a toleration to be scheduled on that node.

Full breakdown with real-world context →

Question 11mediummultiple choice

Read the full DNS explanation →

A pod is unable to resolve DNS names of services in other namespaces. Which DNS configuration is most likely missing?

A
CoreDNS is not deployed in the cluster.
Why wrong: If CoreDNS were missing, no cluster DNS would work, not just cross-namespace.
B
The pod's dnsPolicy is set to 'Default'.
'Default' uses the node's DNS, which does not include cluster DNS records.
C
The pod is in a different namespace than the service.
Why wrong: Cross-namespace DNS works with FQDN.
D
The service does not have a ClusterIP assigned.
Why wrong: A service without a ClusterIP (headless) still has DNS records.

Full breakdown with real-world context →

Question 12hardmultiple choice

Full question →

A pod is unable to communicate with a Service in the same namespace. The administrator checks kube-proxy logs and finds no errors. Which command would help diagnose whether the iptables rules for the Service are correctly programmed?

A
ss -tuln
Why wrong: Shows listening ports, not iptables rules.
B
kubectl describe svc
Why wrong: Describes the Service but does not show iptables rules.
C
kubectl exec -n kube-system <kube-proxy-pod> -- iptables -L
Why wrong: This would show iptables rules but not filtered to the specific Service.
D
iptables-save | grep <service-name>
Shows iptables rules containing the Service name.

Full breakdown with real-world context →

Question 13hardmulti select

Read the full DNS explanation →

You are troubleshooting a Service connectivity issue. A pod in namespace 'frontend' cannot reach a Service in namespace 'backend' by its DNS name. CoreDNS is running. Which statements are true? (Select TWO.)

A
Service DNS is automatically disabled in Kubernetes; pods must use environment variables.
Why wrong: Service DNS is enabled by default via CoreDNS.
B
The default cluster domain for Kubernetes services is 'cluster'.
Why wrong: The default cluster domain is 'cluster.local'.
C
NetworkPolicy cannot affect service DNS resolution.
Why wrong: NetworkPolicy can block traffic to CoreDNS, impacting resolution.
D
Cross-namespace DNS resolution requires the pod to use the full FQDN of the service.
Pods in a different namespace must use the full FQDN to resolve a service.
E
The pod should use the FQDN 'backend-service.backend.svc.cluster.local' to reach the service.
Services are resolvable via <service>.<namespace>.svc.cluster.local.

Full breakdown with real-world context →

Question 14easymultiple choice

Full question →

A PersistentVolumeClaim named 'my-pvc' is created and remains in 'Pending' state. Which command should the administrator use to investigate the reason?

A
kubectl get pv
Why wrong: This shows PVs but does not provide details about the PVC status.
B
kubectl get pvc my-pvc -o yaml
Why wrong: This shows the PVC definition but may not include recent events.
C
kubectl describe pod my-pvc
Why wrong: This tries to describe a pod, but my-pvc is a PVC, not a pod.
D
kubectl describe pvc my-pvc
This command shows events and conditions that help diagnose why the PVC is pending.

Full breakdown with real-world context →

Question 15hardmultiple choice

Read the full DNS explanation →

You are troubleshooting a DNS issue. From within a pod, you run 'nslookup kubernetes.default.svc.cluster.local' and get 'connection timed out; no servers could be reached'. What is the most likely cause?

A
The pod's /etc/resolv.conf has incorrect nameservers
Why wrong: Incorrect nameservers would cause different errors, but timeout suggests the DNS service IP is unreachable.
B
The node's network plugin is misconfigured
Why wrong: Network plugin issues affect all pods, not just DNS; but the specific symptom points to DNS service.
C
The pod's DNS policy is set to 'None'
Why wrong: DNS policy 'None' omits cluster DNS, but the error would be immediate failure, not timeout.
D
The kube-dns service is not running or is misconfigured
If the DNS service pod is down, no DNS resolution works.

Full breakdown with real-world context →

These CKA practice questions are part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style CKA questions with detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics.

Troubleshooting Scenario Questions

How to approach troubleshooting scenario questions

Quick answer

Related CKA topic practice pages

Cluster Architecture, Installation and Configuration practice questions

Services and Networking practice questions

Workloads and Scheduling practice questions

Storage practice questions

Troubleshooting practice questions

Cluster Architecture, Installation & Configuration practice questions

Workloads & Scheduling practice questions

Services & Networking practice questions

CKA fundamentals practice questions

CKA scenario practice questions

CKA troubleshooting practice questions

Practice scenarios

Which TWO commands show cluster events that can help in troubleshooting?

Match each troubleshooting scenario to its likely cause.

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?

Drag and drop the steps to troubleshoot a CrashLoopBackOff pod into the correct order.

Drag and drop the steps to troubleshoot a Node that is in NotReady state into the correct order.

A DevOps engineer notices that the kubelet on a node is unable to register with the Kubernetes API server. The kubelet logs show 'Failed to get bootstrap CA certificate' and the node is not yet part of the cluster. What is the most likely cause?

A pod is failing with 'CrashLoopBackOff'. You run 'kubectl logs mypod' and see no output. What is the first troubleshooting step?

You are troubleshooting a pod that is in 'Pending' state. Running 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate.' What is the most likely cause?

A pod is unable to resolve DNS names of services in other namespaces. Which DNS configuration is most likely missing?

A pod is unable to communicate with a Service in the same namespace. The administrator checks kube-proxy logs and finds no errors. Which command would help diagnose whether the iptables rules for the Service are correctly programmed?

You are troubleshooting a Service connectivity issue. A pod in namespace 'frontend' cannot reach a Service in namespace 'backend' by its DNS name. CoreDNS is running. Which statements are true? (Select TWO.)

A PersistentVolumeClaim named 'my-pvc' is created and remains in 'Pending' state. Which command should the administrator use to investigate the reason?

You are troubleshooting a DNS issue. From within a pod, you run 'nslookup kubernetes.default.svc.cluster.local' and get 'connection timed out; no servers could be reached'. What is the most likely cause?