A developer creates a valid Ingress object for a clinic booking UI, but no external HTTP routing appears. Cluster admins confirm no Ingress controller is running. What does that imply for the developer?
Select an answer to reveal the explanation.
Short Explanation
An Ingress YAML is a work order, not the worker. Without a controller (NGINX, Traefik, cloud LB controller, and so on) watching the API, nothing programs the actual HTTP routers. Creating the object alone does not light up the path.
Full Explanation
A valid Ingress object alone does nothing until an Ingress controller watches and implements it. If a developer creates a correct Ingress for a clinic booking UI but cluster admins confirm no Ingress controller is running, external HTTP routing will not appear. Ingress is a declarative wish list stored in the API; the controller is the worker that programs proxies or load balancers for municipal sites. Without that worker, YAML validity does not equal traffic.
Kubernetes does not always ship a built-in global Ingress data plane that activates any Ingress instantly on every cluster. Replacing the Ingress with a ConfigMap named ingress does not automatically enable routing. Setting Service type ClusterIP does not force kubelet to act as an Ingress controller for HTTP host rules.
Exam caveat: CKAD exam clusters typically already run a controller; real city clusters may not—verify controller and IngressClass before blaming application manifests. Operational check: kubectl get pods -A | grep -i ingress (or consult platform docs); kubectl get ingressclass; after a controller is available, re-check Ingress status/ADDRESS and curl the host. Escalate missing controllers to the platform team rather than endlessly rewriting working Ingress rules that simply have no implementer.