A county creates several Ingress objects for internal tools, but none of the hostnames respond. What prerequisite is most likely missing?
Select an answer to reveal the explanation.
Short Explanation
Ingress manifests without a controller are like traffic signs with no traffic lights installed. You need a live Ingress controller to watch those objects and actually route requests.
Full Explanation
When a county’s Ingress objects exist but hostnames never respond, the most likely missing prerequisite is a running Ingress controller that watches Ingress resources and programs the data plane. Manifests without a controller are traffic signs with no signal cabinet—rules remain declarative only. Controllers often filter by IngressClass; both presence and class association matter for internal tool portals.
A StorageClass named ingress does not mount certificate volumes for routing and is unrelated to whether HTTP rules take effect. Disabling ClusterIP Services so Ingress can bind Pod IPs directly breaks the normal backend model—Ingress targets Services, not a mandate to delete ClusterIPs. Setting every Pod’s restartPolicy to Never does not make routes sticky or enact Ingress.
Exam caveat: multiple controllers can coexist; the wrong or missing IngressClass looks like “nothing responds.” Also check DNS and LoadBalancer/NodePort exposure for the controller Service itself.
Operational check: list IngressClasses and controller Pods in the ingress namespace, describe the Ingress for events/class, ensure backend Services have endpoints, then test from outside the cluster to the controller’s published address.