After validating the green Deployment behind Service app-green, the team wants live Ingress traffic to cut over from Service app-blue. What is the appropriate Ingress change?
Select an answer to reveal the explanation.
Short Explanation
Blue/green cutover at the front door means repointing the Ingress backend to the green Service. Flip the name, keep the port right, and leave blue around until you are sure.
Full Explanation
After validating the green Deployment behind Service app-green, cutting live Ingress traffic over from Service app-blue is done by updating the Ingress backend service name from app-blue to app-green while keeping the correct port. Blue/green at the Ingress layer for municipal apps is essentially a Service name swap on the edge after green is proven Ready and correct in-cluster. Validate first, cut over second, keep rollback ready.
Deleting the green Deployment so Ingress invents a new backend is the opposite of a controlled cutover and removes the target you intended to serve. Changing only the Pod template labels on blue while leaving the Ingress backend unchanged forever does not move traffic to green—the edge still points at app-blue. Setting replicas to 0 on green before pointing Ingress at it forces a cold outage rather than cutting over to a prepared green Service with healthy Endpoints.
Exam caveat: confirm app-green’s Service selects the green Pods and Endpoints are populated/Ready before the swap. Operational check: curl the green Service in-cluster; patch the Ingress backend to app-green; curl the public host; keep blue available briefly so you can patch the backend name back for rollback if needed. Record cutover and rollback Ingress patches in the city’s release checklist so on-call can reverse quickly.