A media company deploys by replacing targets inside its only target group. The last bad build left no prior group for the listener to return to. How should the next deploy make rollback a listener change?
Select an answer to reveal the explanation.
Short Explanation
Keep the old stage standing so you can drop the curtain on a bad act. Rollback should point the listener rule back at the previous target group, which you left intact. The trap is editing the only group until there is nothing left to return to.
Full Explanation
An Application Load Balancer listener rule forwards to a target group. When the previous group still holds the last good targets, rollback is a rule change back to that group, and new requests move without rebuilding targets by hand. A shorter DNS TTL only affects how long resolvers cache the load balancer name and does not create a prior group behind that name. Editing the same target group again after the failure is another in-place change, and during that edit there is still no standing group that matches the last good build. Deleting the listener removes the entry point and is an outage, not a rollback. The previous group has to stay registered and healthy, and targets that leave the new group still follow the deregistration delay for in-flight requests. After a test cutover, switch the rule back and confirm new requests reach targets that belong to the previous group. Keep the previous group registered until the new build is accepted, because an emptied group cannot take the listener back.