DVA-C02 Development with AWS Services 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.

• ✗

  Configure an Auto Scaling step scaling policy based on MemoryReservation metric.

  Why it's wrong here

  Configuring an Auto Scaling step scaling policy based on the MemoryReservation metric is incorrect because MemoryReservation is primarily a metric for container services like Amazon ECS, indicating allocated memory for tasks, not a standard CloudWatch metric for EC2 instance CPU utilization. For a typical Elastic Beanstalk web application running on EC2 instances, CPU utilization is the most direct indicator of processing load, and memory reservation does not accurately reflect the need for CPU-based horizontal scaling.

• ✗

  Use AWS CloudFront to cache responses and reduce load on the application.

  Why it's wrong here

  Using AWS CloudFront to cache responses and reduce load on the application is a valid strategy for improving performance and reducing the *number* of requests reaching the backend. However, CloudFront is a Content Delivery Network (CDN) that caches content at edge locations; it does not automatically scale the underlying compute resources (EC2 instances) within the Elastic Beanstalk environment. While it can mitigate the *need* for scaling by offloading traffic, it does not provide the dynamic scaling capability for the application servers themselves.

• ✓

  Configure an Auto Scaling simple scaling policy based on Average CPU Utilization > 70% for scale-out and < 30% for scale-in.

  Why this is correct

  Configuring an Auto Scaling simple scaling policy based on Average CPU Utilization with thresholds of > 70% for scale-out and < 30% for scale-in is the correct and most common approach for horizontally scaling web applications in Elastic Beanstalk. High CPU utilization directly indicates that the existing instances are struggling to process requests, necessitating more compute capacity. Conversely, low CPU utilization suggests instances are underutilized, allowing for cost-efficient scale-in.

• ✗

  Configure an Auto Scaling target tracking policy based on NetworkIn metric.

  Why it's wrong here

  Configuring an Auto Scaling target tracking policy based on the NetworkIn metric is inappropriate for addressing latency caused by CPU bottlenecks. While NetworkIn (bytes received by the instance) can be a relevant metric for scaling network-intensive applications, it does not directly correlate with the processing power required by the CPU to handle application logic. Scaling based on NetworkIn would address network throughput issues, not the computational load on the instance's processor, which is the root cause of CPU-related latency.