A hospital target group has its deregistration delay set to zero. Every deploy removes targets while requests are still in flight, and those requests fail. What should change?
Select an answer to reveal the explanation.
Short Explanation
You do not yank the tablecloth while the plates are still coming down. Your deregistration delay is zero, so the target disappears immediately and in-flight requests die. The trap is turning off health checks, which never gives those requests time to finish.
Full Explanation
Deregistration delay is the draining window on the target group. At zero, a target that a deploy removes stops taking new requests and the load balancer does not wait for work already in flight, so those requests fail on every deploy. Raising the delay keeps the target in draining long enough for in-flight requests to complete. Disabling health checks changes whether targets are considered healthy and does not add a drain period when a deploy deregisters them. Turning stickiness off changes whether a later request returns to the same target and does not preserve a request that was already on a target being removed. The healthy threshold is how many successful checks a target needs before it is marked healthy, and it does not keep a deregistered target in service. The delay should cover real request time, and a very long delay slows deploys by holding capacity in draining, so the window has to match the requests rather than stay at zero. Deregister one test target with the raised delay and confirm in-flight requests complete while new requests stop arriving.