A SysOps Administrator receives reports of an Auto Scaling group failing to scale when the nodes running Amazon Linux in the cluster are constrained by high memory utilization. What should the…

Question

Options

• ACreate a custom script that pipes memory utilization to Amazon S3, then, scale with an AWS
• BInstall the Amazon CloudWatch memory monitoring scripts, and create a custom metric based on
• CIncrease the minimum size of the cluster to meet memory and application load demands
• DDeploy an Application Load Balancer to more evenly distribute traffic among nodes

• A
  15% (5)
• B
  76% (25)
• C
  6% (2)
• D
  3% (1)

Explanation

Option B is correct because Amazon CloudWatch does not collect memory utilization metrics from EC2 instances by default - you must install the CloudWatch agent (formerly "memory monitoring scripts") on each instance to push custom memory metrics to CloudWatch. Once the custom metric exists, you can create a CloudWatch alarm and attach it to a scaling policy, enabling the Auto Scaling group to react to high memory pressure.

Why the distractors are wrong:

• A - Piping metrics to S3 doesn't integrate with CloudWatch alarms or Auto Scaling policies; S3 is object storage, not a metrics/alerting system.
• C - Increasing the minimum cluster size adds static capacity but doesn't enable dynamic scaling; the group still won't scale automatically in response to memory pressure.
• D - An Application Load Balancer distributes traffic more evenly but does nothing to address the root issue: the cluster cannot detect or react to memory utilization as a scaling trigger.

Memory tip: Think "CloudWatch = cloud watch, but it can't see inside your RAM by default." Any metric not natively collected by CloudWatch (memory, disk usage, swap) requires a custom metric via the CloudWatch agent - and custom metrics unlock custom scaling policies.

No community discussion yet for this question.