CKA CrashLoopBackOff DNS issue 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.

• ✗

  The CoreDNS pod is down

  Why it's wrong here

  If CoreDNS were actually down, all DNS resolution in the cluster would fail, not just the lookup for one Service name. The pod would be unable to resolve any cluster domain, including kubernetes.default.svc.cluster.local, and would almost certainly emit generic timeouts or 'no such host' errors for every name it tries to resolve. The fact that the error specifically points to a missing Service named 'service' indicates the DNS resolver is functioning and responding with NXDOMAIN, which is why a CoreDNS outage cannot be the cause of this particular CrashLoopBackOff.

• ✓

  The service 'service' does not exist in the 'default' namespace

  Why this is correct

  The application's connection string or manifest refers to a Kubernetes Service by the DNS name "service", but no Service object with that name exists in the "default" namespace. When the pod attempts to resolve it, CoreDNS returns NXDOMAIN because no A/AAAA record has been created for a non-existent Service, so the application fails to connect to its required dependency and exits, causing Kubernetes to restart the pod in a CrashLoopBackOff state. This is a configuration error in the workload definition, not an infrastructure or DNS-server failure.

• ✗

  The pod's DNS policy is set to 'None'

  Why it's wrong here

  Setting dnsPolicy: None in the pod spec disables the cluster's default DNS configuration entirely, forcing the pod to supply its own resolv.conf through dnsConfig. That would break resolution for all hostnames, both internal and external, because the pod would not be using CoreDNS at all; it would not produce a targeted error about a specific Service in the 'default' namespace. Moreover, dnsPolicy: None is an explicit, intended configuration chosen by the workload author, and it would not manifest as a repeated crash loop caused by one missing Service record while other DNS lookups remain successful.

• ✗

  A network policy is blocking UDP port 53

  Why it's wrong here

  A NetworkPolicy that blocks UDP port 53 would prevent the pod's DNS queries from ever reaching CoreDNS, causing all name resolution attempts to time out or fail with a generic network error. The application would not be able to resolve any cluster service, so it would not be able to distinguish that a Service named 'service' is missing—it would simply see that every DNS query is unreachable. Since the observed error is specific to the non-existence of the Service record, a network-level block on DNS traffic cannot be the explanation for this CrashLoopBackOff.

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The CKA exam frequently reuses these exact scenarios with slightly different constraints.

Analysis generated from the official CKAblueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

Go deeper

Related to this question