DVA-C02 Troubleshooting and Optimization 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.

• ✗

  Increase the desired count of tasks.

  Why it's wrong here

  Increasing the desired count of tasks distributes incoming requests across more running containers. However, if the application's performance bottleneck is due to insufficient CPU allocated *per task* for its individual processing requirements, simply adding more tasks that are similarly under-resourced will not improve the execution speed of complex operations within each task. This approach might only spread the existing CPU constraint across more units, potentially increasing costs without resolving the core performance issue.

• ✓

  Increase the CPU value in the task definition and redeploy the service.

  Why this is correct

  The "cpu" parameter in an ECS Fargate task definition directly controls the amount of virtual CPU units allocated to each running task. By increasing this value, the application container within the task gains access to more processing power, enabling it to execute computations faster and reduce its overall CPU utilization percentage. Redeploying the service ensures that all new tasks launched by ECS will utilize this updated, higher CPU allocation, directly addressing the bottleneck.

• ✗

  Increase the memory value in the task definition.

  Why it's wrong here

  The "memory" parameter in an ECS Fargate task definition specifies the amount of RAM available to the container within the task. While adequate memory is essential to prevent out-of-memory errors and ensure efficient data handling, increasing memory will not alleviate a CPU bottleneck. An application that is CPU-bound is limited by its processing capacity, not its ability to store data, so adjusting memory will not improve its computational speed.

• ✗

  Switch to EC2 launch type.

  Why it's wrong here

  Switching to the EC2 launch type for ECS provides greater control over the underlying compute infrastructure, such as selecting specific EC2 instance types. However, this change alone does not inherently increase the CPU resources available to individual tasks; it merely shifts the responsibility of instance management to the user. To increase per-task CPU, one would still need to select larger EC2 instances and configure the task definition appropriately, while also incurring the operational overhead that Fargate aims to abstract away.

Go deeper

Related to this question