Courseiva

SAA-C03 Design Resilient Architectures Practice Question

An Auto Scaling group behind an Application Load Balancer frequently replaces new EC2 instances. The application needs ~6 minutes to warm up after instance launch. However, the ALB target group health checks start immediately and mark the targets unhealthy until the application is ready. Because the targets become unhealthy early, the Auto Scaling group then terminates the instances and launches replacements, creating a repeated unhealthy/termination loop.

What configuration change will most directly improve recovery by preventing premature ASG termination while the application is warming up?

⚠ Common exam trap

A common mix-up: candidates think disabling health checks or changing the health check type is a valid fix, but the correct solution is to use the ASG's built-in grace period to decouple early health check failures from termination decisions.

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 a health check grace period on the Auto Scaling group that exceeds the application startup/warm-up time.

The health check grace period on an Auto Scaling group (ASG) allows a newly launched EC2 instance to bypass health check failures for a specified duration. By setting this grace period to exceed the application's ~6-minute warm-up time, the ASG will not prematurely terminate the instance based on ALB health check results. This directly breaks the unhealthy/termination loop while the application initializes.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✓

    Set a health check grace period on the Auto Scaling group that exceeds the application startup/warm-up time.

    Why this is correct

    A health check grace period delays when the Auto Scaling group starts evaluating instance health. This prevents the ASG from terminating instances due to ALB/target health being unhealthy during the initial warm-up window, breaking the unhealthy/termination loop.

  • ✗

    Increase the Auto Scaling group's desired capacity to a higher number than required.

    Why it's wrong here

    Raising desired capacity does not fix the underlying problem of instances being terminated before the application finishes starting. The ASG will still perform ELB health checks and mark any instance that fails the configured health check as unhealthy, even during startup, and will replace it. A larger fleet only hides the symptom by providing extra capacity, but it also increases cost and can lead to a continuous cycle of launching and terminating instances during provisioning.

    When this WOULD be correct

    This option would be correct in a scenario where the application requires a minimum number of healthy instances to handle traffic, and the current desired capacity is too low to meet demand, causing performance issues or scaling events.

  • ✗

    Disable ALB target group health checks so instances are considered healthy as soon as they register.

    Why it's wrong here

    Disabling ALB target group health checks does not stop the ASG from considering instances unhealthy; if the ASG health check type is ELB, it relies on the target group's health status, so disabling checks will cause the ALB to always report healthy, which prevents the ASG from detecting genuine application failures. Meanwhile, the ALB will still route traffic to instances that are still warming up, causing 5xx errors for users, because the target is considered healthy regardless of actual readiness. This is an anti-pattern that sacrifices correctness for a false sense of stability.

    When this WOULD be correct

    If the application has no external dependencies and health checks are causing false negatives due to a bug or misconfiguration, disabling them temporarily for troubleshooting or during a migration where health checks are not yet reliable could be correct.

  • ✗

    Change the Auto Scaling health check type from ELB to EC2 so the ALB will no longer determine instance health.

    Why it's wrong here

    Even if EC2 status checks pass, the application may still not be ready. The instance can remain in service while still causing failed requests, and the ASG will not use ALB readiness to enforce correct routing behavior.

    When this WOULD be correct

    This option would be correct if the question stated that the ALB health checks are misconfigured (e.g., checking a port that is not open) and the instances are actually healthy, but the ALB incorrectly marks them unhealthy. In that case, switching to EC2 health checks would prevent unnecessary terminations.

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 a health check grace period on the Auto Scaling group that exceeds the application startup/warm-up time.Correct answer▾

Why this is correct

A health check grace period delays when the Auto Scaling group starts evaluating instance health. This prevents the ASG from terminating instances due to ALB/target health being unhealthy during the initial warm-up window, breaking the unhealthy/termination loop.

✗Increase the Auto Scaling group's desired capacity to a higher number than required.Wrong answer — click to see why▾

Why this is wrong here

Increasing desired capacity does not prevent the Auto Scaling group from terminating instances that fail health checks; it only adds more instances, which may also fail and be terminated, perpetuating the loop.

★ When this WOULD be the correct answer

This option would be correct in a scenario where the application requires a minimum number of healthy instances to handle traffic, and the current desired capacity is too low to meet demand, causing performance issues or scaling events.

Why candidates choose this

Candidates might think that adding more instances will compensate for the ones being terminated, but this ignores the root cause of premature termination due to health checks.

✗Disable ALB target group health checks so instances are considered healthy as soon as they register.Wrong answer — click to see why▾

Why this is wrong here

Disabling ALB target group health checks would prevent the ALB from routing traffic to healthy instances, causing service disruption. The issue is premature termination by ASG, not health check failure; the grace period directly addresses this.

★ When this WOULD be the correct answer

If the application has no external dependencies and health checks are causing false negatives due to a bug or misconfiguration, disabling them temporarily for troubleshooting or during a migration where health checks are not yet reliable could be correct.

Why candidates choose this

Candidates may think that eliminating health checks stops the termination loop, but they overlook that health checks are essential for traffic routing and that the grace period is the designed solution for warm-up delays.

✗Change the Auto Scaling health check type from ELB to EC2 so the ALB will no longer determine instance health.Wrong answer — click to see why▾

Why this is wrong here

Changing the health check type to EC2 would make the Auto Scaling group ignore ALB health check results, but the ALB would still route traffic to unhealthy instances, causing application errors. The question requires preventing premature termination during warm-up, not ignoring health checks entirely.

★ When this WOULD be the correct answer

This option would be correct if the question stated that the ALB health checks are misconfigured (e.g., checking a port that is not open) and the instances are actually healthy, but the ALB incorrectly marks them unhealthy. In that case, switching to EC2 health checks would prevent unnecessary terminations.

Why candidates choose this

Candidates may think that bypassing ALB health checks will stop the termination loop, but they overlook that the ALB still needs to know instance health for routing traffic, and the real issue is the warm-up time, not the health check type.

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?”

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 →

How Courseiva writes practice questions · Editorial policy

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.