Auto Scaling And Reliability Design — AWS SysOps Administrator (SOA-C03)
Scaling Policy Choice Changes the Operational Burden
A step scaling policy and a target tracking policy can both grow an Auto Scaling group in response to load. The instinct is to treat them as interchangeable. The exam does not. Target tracking removes tuning burden and reacts to sustained load automatically; step scaling gives operators granular control at the cost of ongoing policy maintenance. When the scenario specifies "minimal operational overhead," that phrase eliminates step scaling as the answer.
What This Pattern Tests
The exam describes a scaling scenario and tests which auto-scaling policy type applies. Target tracking maintains a metric at a target value (simplest, best for most cases). Step scaling adds specific capacity at specific thresholds (when CPU > 70% add 2, when > 90% add 4). Scheduled scaling adds capacity on a schedule (scale up at 9am Monday, scale down at 6pm Friday). Predictive scaling uses ML to pre-scale based on patterns. The trap is using step scaling for a simple "keep CPU around 60%" requirement (target tracking is simpler) or target tracking for a known daily traffic spike (scheduled scaling pre-provisions before the spike hits).
Decision Axis
Traffic pattern determines scaling policy: steady growth = target tracking, threshold responses = step, predictable peaks = scheduled, learned patterns = predictive.
Associated Traps
More Top Traps on This Exam
Decision Rules
Whether changing the ASG health check type from EC2 to ELB is sufficient to propagate ALB target health into ASG replacement logic versus adding a CloudWatch alarm on UnhealthyHostCount, which detects the failure but does not cause the ASG to initiate automatic replacement.
Whether to change the ASG health check type from EC2 to ELB versus adding a CloudWatch alarm on ALB UnHealthyHostCount — only changing the health check type propagates ELB target health directly into ASG instance lifecycle decisions, closing the gap between OS-level and application-level health.
Whether to configure a target tracking policy that continuously recalculates desired capacity to hold CPU at a declared target, or a step scaling policy that requires manually defined CloudWatch alarm bands that go stale as traffic patterns shift.
Whether to use a target tracking scaling policy — which treats the metric ceiling as its setpoint and continuously recalculates desired capacity without manual alarm definitions — versus a step scaling policy, which requires the operator to define, test, and periodically recalibrate CloudWatch alarm bands, violating the minimal-overhead constraint under unpredictable load.
Domain Coverage
Difficulty Breakdown