Exam SAA-C03 All QuestionsBrowse all questions from this exam
Question 275

A company runs an internal browser-based application. The application runs on Amazon EC2 instances behind an Application Load Balancer. The instances run in an Amazon EC2 Auto Scaling group across multiple Availability Zones. The Auto Scaling group scales up to 20 instances during work hours, but scales down to 2 instances overnight. Staff are complaining that the application is very slow when the day begins, although it runs well by mid-morning.

How should the scaling be changed to address the staff complaints and keep costs to a minimum?

    Correct Answer: C

    The application experiences poor performance at the start of the workday due to the insufficient number of EC2 instances handling the initial surge in demand. To address this issue, a target tracking action can dynamically adjust the number of instances based on actual CPU utilization. This method ensures that instances are added as needed, reacting swiftly to increased load, while the auto-scaling group can scale down during periods of lower demand, optimizing costs. Decreasing the cooldown period allows the system to respond more rapidly to changes in demand, enhancing responsiveness and further reducing unnecessary costs. Therefore, implementing a target tracking action with a lower CPU threshold and a decreased cooldown period is the best approach.

Discussion
asoliOption: C

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

mandragon

If it stars with 20 instances it will not keep it all day. It will scale down based on demand. The scheduled action in Option A simply ensures that there are enough instances running to handle the increased traffic when the day begins, while still allowing the Auto Scaling group to scale up or down based on demand during the rest of the day. https://docs.aws.amazon.com/autoscaling/ec2/userguide/scale-your-group.html

xdkonorek2

This is right, setting desired capacity doesn't turn off autoscaling policies

TheFivePips

From what I can tell, you must specify an end time, or else it will run indefinitly. So I think A would be right, if they specified an end time. Otherwise C is more cost effective https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html

c10356a

There is no cooldown period in target tracking, but warm-up time.

pentium75

There is a cooldown period in the auto-scaling group, which helps 'keeping costs to a minimum' as instances would be removed sooner.

meowrukiOption: 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.

meowruki

Options A and D involve scheduled actions, which are time-based and may not be as responsive to immediate changes in demand. They also do not dynamically respond to varying workloads.

MoshiurGCPOption: A

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

pentium75

WOuld not keep costs to a minimum

TariqKipkemei

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.

TariqKipkemei

Option C is best

Ramdi1Option: A

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.

pentium75

How would scaling up to the maximum number of instances "keep costs to a minimum"?

pentium75Option: C

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'.

Mikado211Option: A

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.

wearrexdzw3123

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

UzbekistanOption: A

A. Implement a scheduled action that sets the desired capacity to 20 shortly before the office opens.

pentium75

How would scaling up to the maximum number of instances "keep costs to a minimum"?

BrijMohan08Option: A

Scaling Out: In the morning when you schedule the AWS EC2 scaling to have a minimum and maximum of 20 instances, if the load on your application increases beyond the current number of instances, AWS Auto Scaling will automatically launch new instances to meet the demand up to the maximum of 20 instances. Scaling In: As the load on your application decreases in the afternoon or night, AWS Auto Scaling will continuously monitor the health and load of your instances. If the instances are underutilized and can be terminated without affecting your application's performance, AWS Auto Scaling will automatically scale in by terminating excess instances, Why not D? If you specify the min instance, AWS will always keep the minimum number of instances (20 in this case) running.

ChymKuBoyOption: A

A for sure.

foha2012

Answer is A. Makes more sense to me.

Cyberkayu

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.

pentium75

How would scaling up to the maximum number of instances "keep costs to a minimum"?

wearrexdzw3123Option: A

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.

pentium75

How would scaling up to the maximum number of instances "keep costs to a minimum"?

Uzbekistan

CHATGPT says Answers is A A. Implement a scheduled action that sets the desired capacity to 20 shortly before the office opens.

LazyTs

It's A, C will not be fast enough with the sudden influx of the users, if C is fast enough then the original scenario should already be good enough as the 20 is already the max which set to start at working hours(when CPU starts to spin up)

pentium75

How would A "keep costs to a minimum"?

kapalulzOption: C

C. Implement a target tracking action triggered at a lower CPU threshold, and decrease the cooldown period