One Ingress should serve parks.example to Service parks-web and library.example to Service library-web. Which rule structure supports that name-based virtual hosting?
Select an answer to reveal the explanation.
Short Explanation
Two hostnames, two name tags on the Ingress. parks.example and library.example each get their own host rule pointing at the right Service. That is classic name-based virtual hosting.
Full Explanation
One Ingress should serve parks.example to Service parks-web and library.example to Service library-web using name-based virtual hosting: two Ingress rules (or rule entries) with different hosts, each backing to the corresponding Service. Different Host headers select different municipal sites on the shared controller address. That is the standard way to host multiple city websites behind one edge without separate NodePorts per department application, and it keeps public DNS pointed at a single entry while HTTP routing distinguishes sites by name.
A single path / with two ClusterIP fields on one Service object is not valid multi-host Ingress design. Two NetworkPolicies that each list a hostname as a CIDR block confuse HTTP hosts with packet CIDR peers and cannot route browsers by Host header. Two Deployments that set hostname in securityContext.sysctls do not configure Ingress virtual hosting for citizens’ browsers and misuse securityContext for an unrelated goal.
Exam caveat: when HTTPS is required for both names, include per-host entries under spec.tls with appropriate Secrets for each certificate. Operational check: curl -H Host:parks.example and -H Host:library.example against the controller; kubectl describe ingress shows both hosts and backends. Keep DNS A/AAAA or CNAME records for both names pointed at the city’s edge load balancer or controller address, and verify TLS SNI when certificates differ per host.