How many Troubleshooting Scenario Questions questions are on this page?

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

How should I approach KCNA 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 Kubernetes and Cloud Native Associate KCNA questions

Scenario-based practice

Troubleshooting Scenario Questions

Practise Kubernetes and Cloud Native Associate KCNA 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

KCNA

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 1mediumdrag order

Full question →

Drag and drop the steps to troubleshoot a Pod stuck in CrashLoopBackOff into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

A
1. Use kubectl describe pod to check events, 2. Use kubectl logs to see application errors, 3. Check resource constraints (CPU/memory limits), 4. Verify image name and command in the pod spec, 5. Fix the issue and redeploy.
This is correct because it follows a logical troubleshooting flow: first gather events and logs to identify the cause, then check resources and configuration, then apply the fix.
B
1. Use kubectl logs to see application errors, 2. Use kubectl describe pod to check events, 3. Verify image name and command in the pod spec, 4. Check resource constraints (CPU/memory limits), 5. Fix the issue and redeploy.
Why it fails: This is incorrect because checking logs before events might miss underlying scheduling or resource issues that the describe command reveals first.
C
1. Check resource constraints (CPU/memory limits), 2. Use kubectl describe pod to check events, 3. Use kubectl logs to see application errors, 4. Verify image name and command in the pod spec, 5. Fix the issue and redeploy.
Why it fails: This is incorrect because starting with resource checks is premature; you need to first understand why the pod is crashing via events and logs.
D
1. Fix the issue and redeploy, 2. Use kubectl describe pod to check events, 3. Use kubectl logs to see application errors, 4. Check resource constraints (CPU/memory limits), 5. Verify image name and command in the pod spec.
Why it fails: This is incorrect because you cannot fix the issue without first diagnosing it; this order attempts to fix without analysis, which is ineffective.

Full breakdown with real-world context →

Question 2hardmulti select

Full question →

A user reports that a web application is not accessible via its Service. The Service is of type ClusterIP. Which TWO steps should be taken to troubleshoot?

A
Verify that the kube-proxy is running on the node
kube-proxy programs the iptables or IPVS rules that implement ClusterIP Service load balancing on each node. If it is not running, traffic to the Service's virtual IP is never forwarded to backend Pods, so verifying it directly addresses the connectivity failure.
B
Check that the container runtime is working
Why it fails: A running container runtime is required for pods to start, but the stem states the application is already deployed behind a ClusterIP Service, so containers are executing. Verifying runtime health is tempting when pods appear down, yet the failure here lies in Service-to-pod routing, such as selector mismatches or missing endpoints.
C
Check the kube-apiserver status
Why it fails: The kube-apiserver is the control plane component serving the API; a ClusterIP Service failing to reach pods does not depend on it, since existing Service and endpoint objects remain programmed. Checking it is tempting because API server outages break kubectl commands, but the stem describes application traffic, not control-plane access.
D
Check if the Service has any endpoints using 'kubectl get endpoints'
A ClusterIP Service routes only to Pods matched by its selector. If the selector matches no Pods, the endpoints list is empty and connections fail. Checking endpoints with kubectl get endpoints confirms whether backends exist, isolating a selector or readiness problem.
E
Restart all nodes in the cluster
Why it fails: Restarting every node disrupts the whole cluster without diagnosing anything, and ClusterIP reachability depends on kube-proxy rules and endpoint objects rather than node uptime. Restarts are tempting as a blunt remedy for stuck workloads, but they would be the choice only after identifying a genuinely unhealthy node, not for Service troubleshooting.

Full breakdown with real-world context →

Question 3hardmultiple choice

Full question →

A cloud-native application uses a service mesh (Istio) for traffic management. The team notices increased latency in inter-service communication. Which likely cause should be investigated first?

A
Kubernetes Network Policies blocking traffic
Why it fails: Network Policies block or permit packets, producing connection failures and timeouts rather than the gradual latency increase described; they are the correct focus when services cannot reach each other at all. Latency with successful responses points to proxy processing instead.
B
Misconfigured sidecar proxy settings
Each Istio sidecar proxies every inbound and outbound request, so an incorrect proxy setting—such as a misconfigured concurrency limit, buffer size or timeout—directly adds per-hop latency to inter-service calls. Inspecting sidecar configuration and Envoy stats isolates this overhead before blaming the application or network.
C
Application code is not optimized for the mesh
Why it fails: Istio's sidecar proxies intercept traffic transparently, so application code needs no mesh-specific optimisation; unoptimised code adds latency equally without a mesh. Code profiling is the right investigation when latency traces to inefficient queries or algorithms rather than the service mesh layer.
D
mTLS encryption overhead
Why it fails: mTLS handshakes occur once per connection and are amortised across keep-alive sessions, so they do not explain sustained inter-service latency; encryption overhead is the right suspect when connections are short-lived and renegotiated constantly. Persistent latency instead implicates per-request proxy processing.

Full breakdown with real-world context →

Question 4mediummultiple choice

Full question →

A microservice logs errors when connecting to the database. The logs show 'connection refused'. Which troubleshooting step should be taken first?

A
Verify the database Service and Endpoints in Kubernetes
'Connection refused' means the client reached a host but nothing accepted the connection, so the Service may have no matching Endpoints. Verifying the Service selector and its Endpoints confirms whether pods are actually registered before investigating DNS, network policy or the database itself.
B
Scale up the microservice deployment
Why it fails: Does not address connectivity.
C
Restart the microservice pod
Why it fails: Restarting the pod discards diagnostic state and, if the database or its Service is down, the replacement pod fails identically. Restarts suit recovering a crashed or hung container, not diagnosing a refused TCP connection, which requires confirming the target endpoint is listening.
D
Check the logs of other microservices
Why it fails: Other microservices' logs reveal nothing about this pod's refused connection to the database and delay diagnosis. Comparing peer logs suits detecting a fleet-wide configuration drift or shared dependency outage, not isolating a single client's failed TCP connect.

Full breakdown with real-world context →

Question 5hardmultiple choice

Read the full DNS explanation →

A Service of type ClusterIP has been created, but pods in the same namespace cannot reach it by its DNS name. The Service selector matches the pods. What is a likely cause?

A
The Service YAML does not specify a port
Why it fails: If no port is specified, the Service would not work, but the question implies it is created. Additionally, DNS resolution works regardless of port.
B
The kube-dns or CoreDNS pod is not running
ClusterIP resolution depends on cluster DNS: kubelet points pods at the CoreDNS (or kube-dns) Service via resolv.conf. If those pods are down, the Service still has a stable IP and matching endpoints, yet the DNS name cannot resolve, producing the failure described.
C
The Service is not exposed on a node port
Why it fails: ClusterIP Services are reachable only via cluster-internal virtual IP and DNS; nodePort exposure is irrelevant to in-cluster DNS resolution. The option is tempting because NodePort does add external reachability, and it would be correct if clients outside the cluster needed to connect.
D
The pods are using an incorrect container runtime
Why it fails: Container runtime choice does not affect Service DNS records, which are created by CoreDNS from the Service object independently of pod runtime. It is tempting because runtime faults do break pod networking, and switching runtime would be correct if pods themselves failed to start or communicate.

Full breakdown with real-world context →

These KCNA practice questions are part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style KCNA 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 KCNA topic practice pages

Kubernetes Fundamentals practice questions

Container Orchestration practice questions

Cloud Native Architecture practice questions

Cloud Native Observability practice questions

Cloud Native Application Delivery practice questions

KCNA fundamentals practice questions

KCNA scenario practice questions

KCNA troubleshooting practice questions

Practice scenarios

Drag and drop the steps to troubleshoot a Pod stuck in CrashLoopBackOff into the correct order.

A user reports that a web application is not accessible via its Service. The Service is of type ClusterIP. Which TWO steps should be taken to troubleshoot?

A cloud-native application uses a service mesh (Istio) for traffic management. The team notices increased latency in inter-service communication. Which likely cause should be investigated first?

A microservice logs errors when connecting to the database. The logs show 'connection refused'. Which troubleshooting step should be taken first?

A Service of type ClusterIP has been created, but pods in the same namespace cannot reach it by its DNS name. The Service selector matches the pods. What is a likely cause?