Exam AWS Certified Solutions Architect - Associate SAA-C02 topic 1 question 416 discussion

A and D

Will take A and D B is not needed as you can configure auto scaling for RDS C and E don't answer the qn at all on scaling

https://aws.amazon.com/premiumsupport/knowledge-center/storage-full-rds-cloudwatch-alarm/

"This overloads the EC2 instances and causes the RDS instance to run out of storage." "overload EC2" Configure the Auto Scaling group to use the average CPU as the scaling metric "run out of RDS storage" Configure storage Auto Scaling on the RDS for Oracle instance

.....to guarantee that the system can grow automatically as traffic increases? C is ruled out as you are just monitoring and alerting (reactive). Solution warrants proactive method.

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html https://aws.amazon.com/premiumsupport/knowledge-center/storage-full-rds-cloudwatch-alarm/ Answer is AC

https://aws.amazon.com/premiumsupport/knowledge-center/storage-full-rds-cloudwatch-alarm/

Definitely A e D https://aws.amazon.com/about-aws/whats-new/2019/06/rds-storage-auto-scaling/?nc1=h_ls https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-cloudwatch-monitoring.html For example, you can configure an alarm to watch over the average CPU utilization of the EC2 instances in your Auto Scaling group.

oracle rds도 확장을 하지 않을까 생각되네요. cpu 평균사용률을 통한 확장가능 https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Integrating.AutoScaling.html

As the question says "The Auto Scaling group lacks scaling metrics and instead specifies the minimal healthy instance count.", I take it that it means ASG only has Scale-in with a minimum capacity and no Scale-out metric. Thus can't trust ASG to scale-out EC2 according to rising workloads. The only way left for us to consider is to scale the DB capacity whereby option C is creating a custom metric with CloudWatch Alarm to trigger RDS Oracle to perform Storage Auto-Scaling.

A&D are correct

For auto-scaling we need native CPU as we lack in metrics For storage related DB issues, we need storage auto-scaling Hence, A & D

A) Configure storage Auto Scaling on the RDS for Oracle instance. = Makes sense. With RDS Storage Auto Scaling, you simply set your desired maximum storage limit, and Auto Scaling takes care of the rest. B) Migrate the database to Amazon Aurora to use Auto Scaling storage. = Scenario specifies application's data layer uses Oracle-specific PL/SQL functions. This rules out migration to Aurora. C) Configure an alarm on the RDS for Oracle instance for low free storage space. = You could do this but what does it fix? Nothing. The CW notification isn't going to trigger anything. D) Configure the Auto Scaling group to use the average CPU as the scaling metric. = Makes sense. The CPU utilization is the precursor to the storage outage. When the ec2 instances are overloaded, the RDS instance storage hits its limits, too.

A and C. With RDS Storage Auto Scaling, you simply set your desired maximum storage limit, and Auto Scaling takes care of the rest. RDS Storage Auto Scaling continuously monitors actual storage consumption, and scales capacity up automatically when actual utilization approaches provisioned storage capacity.

I am not sure between A&D and B&D because in the question we have already: The Auto Scaling group does not have any scaling metrics and defines the minimum healthy instance count only so I am wondering is A still a good option?

what is the difference between C and D? Why cpu not memory?

A and D