SAA-C03 Design Resilient Architectures Practice Question
Network Topology
Based on the exhibit, the application tier is not replacing unhealthy instances even though the Auto Scaling group spans two Availability Zones. What change most directly improves automatic recovery when the application process fails?
⚠ Common exam trap
Test-takers frequently assume the default EC2 health check is sufficient for application-level failures, but it only checks instance state (running/stopped), not the application process, so the ASG never triggers replacement for application crashes.
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
✓
Set the Auto Scaling group health check type to ELB so target group health determines replacement.
Setting the Auto Scaling group health check type to ELB allows the ASG to use the target group's health checks, which monitor application-level health (e.g., HTTP 200 responses). When the application process fails, the ELB marks the instance as unhealthy, and the ASG immediately terminates and replaces it. This directly addresses the issue of unhealthy instances not being replaced, as the default EC2 health check only verifies instance status (e.g., running vs. stopped), not application responsiveness.
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 ASG desired capacity so that extra instances absorb the failed ones.
Why it's wrong here
Raising the desired capacity only launches more instances; it does not alter the Auto Scaling group's health check type, which remains EC2 status checks that pass because the OS and hypervisor are healthy. The application's HTTP 500 response occurs at the endpoint level, so the extra instances would either also return 500 and remain in service, or at best mask the symptom without removing the failing instances. This action neither detects the application failure nor triggers replacement.
When this WOULD be correct
In a scenario where the ASG is correctly configured to replace unhealthy instances but the application needs to handle sudden traffic spikes without downtime, increasing desired capacity ensures enough healthy instances are always available to absorb load.
- ✓
Set the Auto Scaling group health check type to ELB so target group health determines replacement.
Why this is correct
This makes Auto Scaling replace instances that fail the load balancer health check even when EC2 status checks still pass. The exhibit shows the application health endpoint returns 500 while EC2 checks remain passing, so EC2-only health checks miss the failure. ELB-based health checks align replacement with real application availability.
- ✗
Replace the Application Load Balancer with a Network Load Balancer to improve failover speed.
Why it's wrong here
A Network Load Balancer operates at Layer 4 and its health checks only verify TCP connectivity, not HTTP response codes such as the 500 shown by the application's health endpoint. Replacing the ALB with an NLB would therefore still report the instance as healthy, and the ASG's default EC2 health checks would also continue to pass. This change alters the traffic layer but leaves the actual detection and replacement mechanism unchanged.
When this WOULD be correct
When the requirement is to handle sudden traffic spikes with minimal latency and the application can tolerate connection-level health checks, or when the architecture needs to preserve the source IP address of clients.
- ✗
Increase the HealthCheckGracePeriod to the maximum value so the instances have more time to stabilize.
Why it's wrong here
The health check grace period applies only after an instance is launched, delaying the start of health checks so a new instance has time to stabilize; it has no effect on instances that are already running and returning HTTP 500s. The exhibit shows a steady-state failure, not a boot-time issue, so increasing this value to the 3600-second maximum would only postpone evaluation of new replacements, leaving the current unhealthy instances untouched. It also does not change the health check type from EC2 status checks to ELB, so application failures remain invisible.
When this WOULD be correct
This option would be correct in a scenario where instances are being prematurely terminated because health checks begin before the application finishes booting, causing false positives. Increasing the grace period gives the application more time to become healthy.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.
✓Set the Auto Scaling group health check type to ELB so target group health determines replacement.Correct answer▾
Why this is correct
This makes Auto Scaling replace instances that fail the load balancer health check even when EC2 status checks still pass. The exhibit shows the application health endpoint returns 500 while EC2 checks remain passing, so EC2-only health checks miss the failure. ELB-based health checks align replacement with real application availability.
✗Increase the ASG desired capacity so that extra instances absorb the failed ones.Wrong answer — click to see why▾
Why this is wrong here
Increasing desired capacity adds more instances but does not fix the health check configuration; the ASG still uses EC2 status checks, which may not detect application-level failures, so unhealthy instances are not replaced.
★ When this WOULD be the correct answer
In a scenario where the ASG is correctly configured to replace unhealthy instances but the application needs to handle sudden traffic spikes without downtime, increasing desired capacity ensures enough healthy instances are always available to absorb load.
Why candidates choose this
Candidates think that adding more instances provides redundancy, but they overlook that the core issue is the health check type not detecting application failures, so extra instances won't be triggered to replace unhealthy ones.
✗Replace the Application Load Balancer with a Network Load Balancer to improve failover speed.Wrong answer — click to see why▾
Why this is wrong here
The question is about replacing unhealthy instances based on application process failure, not about failover speed. An NLB does not provide application-level health checks, so it would not detect application process failures.
★ When this WOULD be the correct answer
When the requirement is to handle sudden traffic spikes with minimal latency and the application can tolerate connection-level health checks, or when the architecture needs to preserve the source IP address of clients.
Why candidates choose this
Candidates may think that an NLB's faster failover and lower latency would improve recovery, but they overlook that the issue is about detecting application-level health, which requires an ALB's HTTP health checks.
✗Increase the HealthCheckGracePeriod to the maximum value so the instances have more time to stabilize.Wrong answer — click to see why▾
Why this is wrong here
Increasing HealthCheckGracePeriod only delays the start of health checks, but does not fix the root cause: the ASG is using EC2 status checks (default) instead of ELB health checks, so it never detects application-level failures.
★ When this WOULD be the correct answer
This option would be correct in a scenario where instances are being prematurely terminated because health checks begin before the application finishes booting, causing false positives. Increasing the grace period gives the application more time to become healthy.
Why candidates choose this
Candidates may think that giving instances more time to stabilize will prevent unnecessary replacements, but they overlook that the ASG must first be configured to use ELB health checks to detect application failures at all.
Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
This SAA-C03 question is part of Courseiva's 935-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.