SAA-C03 Design High-Performing Architectures Practice Question
A company runs a stateless containerized web application on Amazon ECS with the Fargate launch type behind an Application Load Balancer. The application must scale out quickly when request latency rises and scale in when traffic drops, and the operations team wants a managed target-tracking approach. Which solution meets these requirements?
⚠ Common exam trap
The trap here is reaching for EC2 Auto Scaling group mechanics out of habit, when a Fargate service is scaled through Application Auto Scaling at the task level.
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
✓
Configure an Application Auto Scaling target-tracking scaling policy on the ECS service using the ALBRequestCountPerTarget metric.
Application Auto Scaling target tracking on the ECS service is the managed mechanism that adjusts desired task count in response to a metric. ALBRequestCountPerTarget reflects how much work each task is receiving from the load balancer, so it scales out before latency degrades and scales in as traffic falls, and it works natively with the Fargate launch type.
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 Application Auto Scaling target-tracking scaling policy on the ECS service using the ALBRequestCountPerTarget metric.
Why this is correct
Application Auto Scaling supports target tracking for ECS services, and ALBRequestCountPerTarget is a predefined metric that scales tasks based on the load each task receives from the load balancer. It responds to demand changes automatically, works with Fargate because no EC2 capacity needs to be managed, and requires no custom scaling logic.
- ✗
Use a scheduled scaling action on the ECS service to add tasks at the start of each business day.
Why it's wrong here
Scheduled scaling changes task count at fixed times and cannot react to rising request latency or unexpected traffic patterns. It would either over-provision during quiet periods or under-provision during an unanticipated spike. The scenario requires responsiveness to actual demand, which scheduled actions do not provide.
- ✗
Create an EC2 Auto Scaling group with a target-tracking policy and register the ECS tasks as instances.
Why it's wrong here
The Fargate launch type does not use EC2 instances that the customer manages, so an EC2 Auto Scaling group has nothing to scale. ECS tasks on Fargate are scheduled by ECS, and scaling must be expressed as a desired task count on the service. This approach also mixes control planes and would not respond to task-level demand.
- ✗
Deploy the application on EC2 instances in an Auto Scaling group and use the ECS-optimized AMI, replacing Fargate.
Why it's wrong here
Switching to EC2 capacity changes the launch type and adds instance management overhead that the team explicitly wants to avoid. EC2 Auto Scaling scales instances, not tasks, so task-level responsiveness requires additional configuration. This does not meet the requirement for a managed target-tracking approach on the existing Fargate service.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SAA-C03 question from scratch — 935 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.