SAA-C03 Design Resilient Architectures Practice Question
A high-traffic application uses an Application Load Balancer (ALB) and an Auto Scaling group (ASG). During peak hours, some EC2 instances fail, but the ASG does not replace them immediately because the instances are still in a 'running' state despite the application being unresponsive. How should the architect fix this?
⚠ Common exam trap
SAA-C03 often tests the difference between EC2 and ELB health check types, and candidates mistakenly believe that increasing the grace period or adding CloudWatch alarms will make the ASG replace unresponsive instances.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Change the ASG health check type from EC2 to ELB.
By default, an Auto Scaling group uses EC2 health checks, which only detect instance-level failures (e.g., stopped or terminated instances) and not application-level unresponsiveness. Changing the health check type to ELB makes the ASG rely on the load balancer's health checks, which actively probe the application on each instance; if an instance fails the ELB health check, the ASG marks it unhealthy and replaces it. This directly resolves the issue of running-but-unresponsive instances.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Change the ASG health check type from EC2 to ELB.
Why this is correct
The ELB health check type ensures that the Auto Scaling group considers an instance unhealthy if the Application Load Balancer determines the application is not responding correctly. This provides a more accurate view of application health than basic EC2 status checks, which only monitor the underlying hardware and network connectivity of the virtual machine.
- ✗
Increase the ASG health check grace period to 600 seconds.
Why it's wrong here
Increasing the grace period only delays the initial health check after an instance starts. This would actually make the problem worse by allowing unresponsive instances to stay in service longer before the ASG attempts to evaluate their health. It does not address the core issue of the ASG not recognizing application-level failures.
- ✗
Create a CloudWatch alarm for high CPU usage to trigger replacement.
Why it's wrong here
While CPU usage can be an indicator of load, it is not a direct measure of application health. An application might be unresponsive due to a deadlock or database connection issue while CPU usage remains low. Relying on CPU alarms for instance replacement would lead to both false positives and missed application failures.
- ✗
Configure a Lambda function to manually terminate unresponsive instances.
Why it's wrong here
Developing a custom Lambda function to manage instance lifecycles adds unnecessary complexity and operational overhead. AWS provides native integration between ELB health checks and Auto Scaling groups to handle this exact scenario automatically. Using native features is always preferred over custom scripts to ensure long-term maintainability and reliability of the architecture.
Visual reference
About these practice questions
Courseiva writes every SAA-C03 question from scratch — 149 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.