SOA-C02 Networking and Content Delivery 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.

• ✗

  Disable cross-zone load balancing on the ALB.

  Why it's wrong here

  Disabling cross-zone load balancing on the ALB changes traffic distribution across Availability Zones but does nothing to lower CPU utilization on individual targets. With cross-zone disabled, each AZ's targets receive traffic only from that AZ, which can create hot spots and make CPU spikes worse. The health check failures and 503 errors persist because the underlying capacity shortage is unaddressed, and fault tolerance is reduced.

• ✓

  Configure the Auto Scaling group to scale out based on average CPU utilization and ensure sufficient capacity.

  Why this is correct

  Configure the Auto Scaling group with a target tracking policy based on average CPU utilization, for example a 50% threshold. As CPU approaches the threshold, the ASG launches additional instances in a horizontal scale-out, distributing incoming requests across more targets and reducing CPU load per instance. You must also ensure the minimum, maximum, and desired capacity values are set high enough to absorb peak traffic. This directly eliminates the health check failures caused by CPU saturation, allowing the ALB to register healthy targets and serve requests successfully.

• ✗

  Increase the deregistration delay on the ALB target group to allow in-flight requests to complete.

  Why it's wrong here

  Increasing the deregistration delay on the ALB target group lengthens the draining period during which in-flight requests are allowed to finish before the target is removed. However, targets already failing health checks due to high CPU remain unhealthy throughout this extended delay; they will repeatedly fail probes and still receive traffic from the ALB, which can amplify the 503 errors. The action does not add capacity or relieve CPU pressure, so it fails to address the root cause.

• ✗

  Decrease the health check interval to detect unhealthy instances faster.

  Why it's wrong here

  Decreasing the health check interval makes the ALB send probes more frequently, such as every 5 seconds instead of 30 seconds. This adds a burst of additional HTTP requests to backend instances that are already CPU-saturated, potentially worsening the very condition that caused the health check failures. While it might identify an unhealthy target a few seconds sooner, it does not prevent overload; the correct fix is to scale out to give the fleet enough capacity.

Go deeper

Related to this question