SOA-C02 Reliability and Business Continuity Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Stop the NLB, replace instances, and restart the NLB

  Why it's wrong here

  Stopping the NLB takes down the entire load balancer, immediately dropping all client sessions across every target, not just the instances being replaced. The NLB has no pause-and-resume capability; restarting it creates a fresh network path, and any in-flight TCP/UDP flows to all instances are lost. Instead, you should use target-group deregistration with connection draining to selectively retire only the desired instances while the rest of the fleet keeps serving traffic.

• ✓

  Deregister the old instances from the target group with connection draining enabled, then register new instances

  Why this is correct

  Deregistering the old instances from the target group with connection draining (the deregistration delay attribute on the NLB target group) causes the load balancer to stop sending new connections to those instances while continuing to allow existing connections to complete up to the configured timeout, which defaults to 300 seconds. This preserves active user sessions for the stateful application, and only after the drain period expires are the instances fully removed. Registering new instances after the old ones have fully drained provides a clean handoff without abrupt termination; for even higher availability, you can register the new instances before starting the drain so fleet capacity is never reduced.

• ✗

  Update the target group health check to remove old instances faster

  Why it's wrong here

  Health check settings on a target group define how the NLB determines whether a target is healthy enough to receive new traffic, but adjusting them only changes how quickly an unresponsive instance is taken out of rotation. Making health checks stricter—for example, more frequent checks or lower thresholds—does not gracefully close in-flight sessions; when an instance is marked unhealthy, the load balancer immediately stops sending new requests, yet active TCP connections are not given time to finish unless a deregistration delay is already configured. Thus, tuning health checks is a detection mechanism, not a session-draining mechanism, and it will likely cause the very session drops you are trying to avoid.

• ✗

  Terminate the old instances immediately and launch new ones

  Why it's wrong here

  Immediately terminating the EC2 instances severs every established TCP connection and kills all in-flight requests, causing an instant outage for any user with an active session on those instances. A stateful application also loses any in-memory session data, which can lead to corrupted state and user-visible errors. You must allow the instances to gracefully finish existing work via connection draining before terminating them; immediately killing the instances provides no opportunity for cleanup or session handoff.

Go deeper

Related to this question