CKA Troubleshooting Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  kubectl exec pod-a -- nslookup service-name

  Why this is correct

  This command launches nslookup inside pod-a's network namespace, querying the cluster's CoreDNS/kube-dns service to resolve the name "service-name". Successful resolution proves that DNS pod(s), kube-dns service, and the pod's resolv.conf are functioning, and it returns the ClusterIP or headless endpoints needed for service discovery. It is a valid connectivity test because without DNS, application-level communication via service names fails regardless of reachable pods.

• ✗

  kubectl describe node | grep Network

  Why it's wrong here

  kubectl describe node fetches the Node object's status and metadata, and piping to grep Network simply isolates lines containing the word "Network," such as pod CIDR assignments or the internal IP field. This is a static snapshot of node configuration, not an active probe: it cannot tell you whether packets can actually traverse the CNI, whether a remote pod is listening, or if network policies permit traffic. Therefore it does not test pod-to-pod connectivity and is not a valid troubleshooting command for this scenario.

• ✗

  kubectl logs pod-a | grep network

  Why it's wrong here

  kubectl logs pod-a streams the container's captured stdout/stderr from its runtime; grepping "network" merely filters those log lines for the literal string, which may reveal application-level errors if the app logs network failures. However, it generates no traffic, sends no packets to another pod, and cannot test reachability, DNS, routing, or service connectivity. At best it is a passive observation aid, so it is not a valid command to actively troubleshoot network connectivity between pods.

• ✓

  kubectl exec pod-a -- curl http://pod-b

  Why this is correct

  This command uses kubectl exec to run curl inside pod-a and sends an HTTP request to http://pod-b, where pod-b is either a service name or a resolvable pod address. It actively traverses the pod network, verifies L3/L4 reachability, confirms the destination container is listening, and yields an HTTP status code that reflects the application's health. Because service names may not be resolvable from within a pod unless DNS is configured correctly, this also tests DNS and service routing, making it a high-value troubleshooting tool.

• ✓

  kubectl exec pod-a -- ping pod-b-ip

  Why this is correct

  Executing ping pod-b-ip from inside pod-a sends ICMP echo requests to the pod's IP address, testing raw L3/IP connectivity across the cluster's network without relying on DNS or application listeners. This is valid for verifying that the CNI is routing pod-to-pod traffic and that no network policy or firewall is dropping packets at the IP layer. However, ICMP is often blocked by network policies or cloud environments, so a failed ping does not definitively prove broken connectivity, while a successful ping only proves IP reachability, not that a service is ready.

Go deeper

Related to this question