The city needs HTTPS-ready HTTP routing so host permit.city.example path / reaches Service permit-ui on port 80. Which Ingress configuration expresses that intent?
Select an answer to reveal the explanation.
Short Explanation
Ingress is the front-desk map: this hostname and path go to that Service. Put permit.city.example and path / on a rule that backends to permit-ui:80. NetworkPolicies and ConfigMaps are not HTTP host routers.
Full Explanation
HTTPS-ready HTTP routing that sends host permit.city.example path / to Service permit-ui on port 80 is expressed with an Ingress rule: host permit.city.example, path /, and a backend Service named permit-ui with port 80. That is the core Ingress model—hostname and path match, then forward to a Service port. Municipal permit UIs typically start with this host/path/backend shape before adding TLS and extra paths.
A NetworkPolicy egress rule listing permit.city.example as an allowed CIDR confuses DNS names with packet CIDR policy and does not configure HTTP routing. A headless Service whose selector is the hostname is invalid selector usage and not an Ingress. A ConfigMap key host=permit.city.example mounted into Pods is configuration data, not a cluster HTTP routing mechanism.
Exam caveat: Ingress backends reference Service name and Service port (not Pod IPs). pathType should be set intentionally (Prefix/Exact/ImplementationSpecific) on modern APIs. Operational check: apply the Ingress, ensure an Ingress controller is running, curl -H Host:permit.city.example against the controller entrypoint, and kubectl describe ingress to confirm the backend. Record host and Service mapping in the city’s public DNS/runbook checklist.