Exam AWS Certified Solutions Architect - Associate SAA-C03 topic 1 question 275 discussion

At first, I thought the answer is A. But it is C. It seems that there is no information in the question about CPU or Memory usage. So, we might think the answer is A. why? because what we need is to have the required (desired) number of instances. It already has scheduled scaling that works well in this scenario. Scale down after working hours and scale up in working hours. So, it just needs to adjust the desired number to start from 20 instances. But here is the point it shows A is WRONG!!! If it started with desired 20 instances, it will keep it for the whole day. What if the load is reduced? We do not need to keep the 20 instances always. That 20 is the MAXIMUM number we need, no the DESIRE number. So it is against COST that is the main objective of this question. So, the answer is C

C. Implement a target tracking action triggered at a lower CPU threshold, and decrease the cooldown period. Here's the reasoning: Target Tracking Scaling Policy: With a target tracking scaling policy, you can set a target value for a specific metric, such as CPU utilization. The Auto Scaling group then adjusts the capacity to maintain that target. Lower CPU Threshold: By triggering the target tracking action at a lower CPU threshold, the Auto Scaling group can proactively add instances when the workload increases, helping to address the slowness at the beginning of the day. Decrease Cooldown Period: Reducing the cooldown period allows the Auto Scaling group to scale in and out more rapidly, making adjustments quicker in response to changing demand.

Why A is Correct: Scheduled scaling action increases capacity to 20 instances shortly before office hours. Ensures instances are already running and warm when employees start using the app. This avoids delays caused by dynamic scaling and instance warm-up.

Decreasing cpu threshold could cause more running instance(might have more than two at night) therefore higher cost. Schedule at desired to 20 minutes before the day will solve the issue that the app is very slow at begininng of the day

Exam-wise, you gotta choose A. The problem is explicitly described as slowness at the start of the day, which implies a predictable traffic pattern. Option C argues for a responsive approach (reacting dynamically to real-time demand changes) rather than a predictive approach (pre-scaling based on a known schedule). Also, option A can minimize costs compared to option D as well, because the desired capacity is a flexible number that the Auto Scaling group targets at specific times but doesn’t enforce as a hard minimum. If the emphasis is on handling varying traffic patterns throughout the day, Option C could be considered viable.

Question is about cost effectiveness hence Use target tracking scaling policies to maintain a specific metric, such as CPU utilization or request count per target. This allows the Auto Scaling group to dynamically adjust the number of instances based on real-time demand. We do not need to have 20 instances up and running during start of the day.

Not C because: target tracking scaling attempts to maintain a target metric (like average CPU utilization). While more responsive, it would still react to increased load rather than pre-scaling. The initial slow period would persist as the scaling reacts to the increased demand rather than anticipating it.

A for sure.

Answer is A. Makes more sense to me.

A is not cost effective, it would set the number of instances to maximum even before the first employee arrives. D is not cost effective, it would cause the permanent use of 20 instances B could almost work, but if you configure small steps then it scales too slowly in the morning; if you configure big steps (like "add 8 instances at a time") it would scale in the morning but not be cost-efficient during the day. C would address the requirement, it would scale to meet a certain CPU utilization. Decreasing the cooldown period (which is not possible for the scaling policy itself but for the auto-scaling group) would help 'keeping costs to a minimum'.

The question 369 is exactly the same problem, Since a scheduled scaling doesn't disable the autoscaling later in the day the A works perfectly well.

A. since only a boot storm issue at 9am and settle down in mid morning, 20 instance is enough to support the workload NOT C. Reduce threshold to trigger (lets say 50% from 80% utilization) and lower cool down period, will still take time to ramp up to max 20 instance.

I would go with A. Autoscaling is still there and the problem is clearly in morning.

My mistake, I should have chosen c. A lower threshold can expand in advance, and lowering cooling can increase the expansion frequency.

I choose option A because the root of the problem is the inability of the scaling speed in the morning to meet the demand, rather than what criteria to use for scaling.

To keep costs to a minimum target tracking is the best option. For example the scaling metric is the average CPU utilization of the EC2 auto scaling instances, and their average during the day should always be 80%. When CloudWatch detects that the average CPU utilization is beyond 80% at start of day, it will trigger the target tracking policy to scale out the auto scaling group to meet this target utilization. Once everything is settled and the average CPU utilization has gone below 80% at night, another scale in action will kick in and reduce the number of auto scaling instances in the auto scaling group.

I am going A based on it stating upto 20 so you already know what they maximum they use which is n a sense consistent. however i can see why people have put C. I think they need more clarification on the questions.