SOA-C02 Bottleneck 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.

• ✗

  The Auto Scaling group is scaling too aggressively, causing thrashing.

  Why it's wrong here

  Auto Scaling thrashing occurs when scaling policies overreact to short-lived spikes, causing frequent launch and termination cycles. This would show up as volatile CPU utilization, repeated CloudWatch Alarm state flapping, and a constantly changing instance count, rather than a steady sub-20% average CPU. Since the problem describes consistently low CPU, a thrashing Auto Scaling group is not the cause, and the symptom would instead be tied to a resource the application is waiting on.

• ✗

  The Application Load Balancer has a sticky session configuration that is not distributing traffic evenly.

  Why it's wrong here

  Sticky sessions (session affinity) pin a client to a specific target for the life of a session, which can cause uneven load distribution if session durations are long or clients are concentrated. However, such imbalance would typically produce a mix of instances with high CPU utilization and others with near-idle CPU, so the fleet-wide average would not uniformly sit below 20%. The scenario gives no indication of skewed per-instance metrics or hot spots, so this configuration is unlikely to explain the persistent slow performance across all application nodes.

• ✓

  The application database is under-provisioned and is causing slow query responses.

  Why this is correct

  An under-provisioned database can directly cause slow application responses while keeping EC2 CPU low because the application nodes spend most of their time blocked on database queries. Inadequate IOPS, insufficient memory for the buffer cache, or a suboptimal schema can lead to high query latency and connection queueing, which is not reflected in the web-tier CloudWatch CPU metric. The low average CPU is a classic sign of an external dependency bottleneck, making the database the most plausible root cause for the degraded user experience.

• ✗

  The EC2 instances are using burstable performance and have exhausted their CPU credits.

  Why it's wrong here

  Incorrect. If burstable instances exhaust CPU credits, they are throttled to baseline performance, which would still result in low CPU utilization but might explain slow performance. However, the most likely cause given common scenarios is a database bottleneck, not CPU credit exhaustion, because low CPU is more typically associated with waiting on external resources.

Go deeper

Related to this question