CV0-004 Troubleshooting Practice Question
A cloud engineer is troubleshooting an issue where an application running in a container on a Kubernetes cluster is unable to resolve DNS names. The cluster uses CoreDNS. The engineer checks the CoreDNS pod logs and sees no errors. Which of the following should the engineer check next?
⚠ Common exam trap
CV0-004 often tests the assumption that DNS issues are always server-side, leading candidates to overlook client-side configuration like resolv.conf.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The container's /etc/resolv.conf file
The container's /etc/resolv.conf file contains the DNS configuration, including the nameserver IP and search domains. If CoreDNS logs show no errors, the issue may be that the container is not using the correct DNS server or has a misconfigured resolv.conf. Checking this file is the next logical step.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The Kubernetes DNS service IP address
Why it's wrong here
A wrong or missing DNS service IP in the pod's resolv.conf sends queries nowhere, and CoreDNS logs stay clean because requests never arrive. It is tempting to suspect CoreDNS itself, but checking its service address is the right step only when the resolver is confirmed reachable and responding.
- ✓
The container's /etc/resolv.conf file
Why this is correct
With CoreDNS logging no errors, the fault likely lies in the pod's own DNS configuration. The container's /etc/resolv.conf supplies the nameserver and search domains used for lookups, so an incorrect or missing entry there would break name resolution despite healthy cluster DNS.
- ✗
The cloud provider's DNS resolver settings
Why it's wrong here
CoreDNS forwards unresolved names to the upstream resolver configured in its Corefile or the node's /etc/resolv.conf, so provider DNS settings are only relevant once forwarding is confirmed. The engineer should first verify the pod's own DNS policy and resolv.conf, since a broken forward path or missing upstream entry causes silent resolution failures with clean CoreDNS logs.
- ✗
The network policy for the namespace
Why it's wrong here
Network policies control pod ingress and egress traffic, not DNS resolution itself, and CoreDNS logs show no errors. It tempts because blocked traffic can break name resolution, but the next check is whether the pod's DNS configuration points at the correct cluster DNS service IP.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 834 original CV0-004 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CompTIA exam blueprint
This CV0-004 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CV0-004 exam.