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.

• ✗

  Switch to a Network Load Balancer.

  Why it's wrong here

  Switching to a Network Load Balancer operates at Layer 4 and bypasses Layer-7 features, but it does not change the fact that each EC2 instance must still process the same aggregate request volume. If the bottleneck is per-target CPU, memory, or application concurrency, the ALB's Layer-7 overhead is negligible compared to the queueing delay on the instances themselves. Therefore, replacing the ALB with an NLB would not lower the latency you're experiencing — it only changes how traffic is forwarded, not how much work each instance has to do.

• ✓

  Add more EC2 instances to the target group.

  Why this is correct

  Adding more EC2 instances to the target group horizontally scales the application and directly reduces the number of concurrent requests each instance must handle. Since the ALB already distributes traffic at the request level, an increase in target count lets the same request rate be spread across more processing capacity, lowering queue wait times and therefore end-to-end latency. This is the standard approach when per-instance CPU utilization is high or when the request queue delay is proportional to the load per target. It is the correct choice among the options.

• ✗

  Enable sticky sessions on the ALB.

  Why it's wrong here

  Enabling sticky sessions on the ALB ties a client's subsequent requests to the same backend instance using a cookie, which actually works against smoothing out load. If one client has aggressive retries or a long-running session, that instance can become oversaturated while other instances remain idle, increasing the overall mean latency. Sticky sessions are useful for preserving in-memory session state, but they do nothing to increase backend capacity and can make uneven distribution more severe, so they won't fix the latency problem.

• ✗

  Reduce the idle timeout on the ALB.

  Why it's wrong here

  Reducing the idle timeout on the ALB changes how long an inactive connection is kept open before being closed, which is unrelated to the time required to process active requests. A shorter timeout may cause clients to re-establish connections more frequently, adding connect handshake overhead and potentially increasing latency. Since the reported latency is observed on real requests, not on idle keep-alive connections, lowering the idle timeout will not reduce response times and can actually degrade perceived performance.

Go deeper

Related to this question