Auto Scaling EC2 Instances Based on Memory Utilization
An SAP administrator notices that the SAP application server is experiencing high memory utilization. The system uses a cluster of EC2 instances. What is the most cost-effective solution to automatically add an additional application server when memory exceeds 80%?
Quick Answer
The reason a custom CloudWatch metric is required here is that Amazon CloudWatch does not track memory utilization by default - EC2's built-in metrics cover things like CPU, network, and disk, but not RAM usage inside the guest operating system. To scale on memory, you have to publish that data yourself (typically via the CloudWatch agent) as a custom metric, then point an Auto Scaling group's scaling policy at that metric so a new application server launches automatically once utilization crosses the 80% threshold. That combination is what makes the solution both automatic and cost-effective: capacity is added only when the trigger condition is actually met, rather than running oversized instances around the clock or waiting on a person to notice. The other choices fall short for different reasons - sending an email still requires someone to manually launch and configure a new server, which defeats the purpose of automation, and scaling based on CPU utilization would completely miss a memory-driven bottleneck since the two resources can behave independently. Elastic Beanstalk, meanwhile, is a platform-as-a-service layer that abstracts away this kind of fine-grained scaling control and isn't built for SAP application server clusters. Whenever a question asks you to scale automatically on a metric that isn't one of EC2's native CloudWatch metrics, expect the answer to involve a custom CloudWatch metric feeding an Auto Scaling policy.
⚠ Common exam trap
A common pitfall is assuming that CPU utilization is the only metric available for Auto Scaling. Memory utilization requires a custom CloudWatch metric, which must be published from the instances using the CloudWatch agent.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure an Auto Scaling group with a scaling policy based on a custom CloudWatch metric for memory utilization.
Auto Scaling groups can use custom CloudWatch metrics (e.g., memory utilization) via the CloudWatch Agent to trigger scaling actions. This automates adding instances when memory exceeds 80% without manual intervention. Option B is incorrect because it only sends an email for manual action, which is not automatic nor cost-effective. Option C is incorrect because it scales based on CPU, not memory, so it does not address the memory issue. Option D is incorrect because Elastic Beanstalk is a PaaS service that abstracts infrastructure, but it does not provide a simple way to scale based on memory utilization, and it is not specifically designed for SAP application server clusters.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Configure an Auto Scaling group with a scaling policy based on a custom CloudWatch metric for memory utilization.
Why this is correct
Correct. An Auto Scaling group with a scaling policy based on a custom CloudWatch metric for memory utilization will automatically launch a new instance when memory exceeds 80%.
- ✗
Create a CloudWatch alarm that sends an email to the administrator to manually launch a new instance.
Why it's wrong here
Incorrect. A CloudWatch alarm that sends an email only notifies the administrator; it does not automatically add instances, requiring manual intervention.
- ✗
Use an Auto Scaling group with a scaling policy based on CPU utilization.
Why it's wrong here
Incorrect. Auto Scaling based on CPU utilization does not directly address high memory usage; memory issues may not be resolved by scaling on CPU.
- ✗
Use AWS Elastic Beanstalk to deploy the application server.
Why it's wrong here
Incorrect. AWS Elastic Beanstalk is for deploying web applications, not a solution for adding application servers based on memory utilization in a custom SAP cluster.
Go deeper
Related to this question
About these practice questions
This PAS-C01 question is part of Courseiva's 1,616-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on PAS-C01
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. An SAP system is experiencing high CPU utilization on the application server. The administrator wants to automatically scale the EC2 instance based on CPU usage. Which AWS service should be used?
medium- A.Elastic Load Balancing
- ✓ B.AWS Auto Scaling
- C.AWS Lambda
- D.Amazon CloudWatch
Why B: Auto Scaling with scaling policies based on CloudWatch alarms can automatically adjust the number of instances. Option B is correct. Option A is wrong because Elastic Load Balancing distributes traffic, not scaling. Option C is wrong because Lambda can be used but is not the primary service for EC2 scaling. Option D is wrong because CloudWatch monitors but does not scale.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PAS-C01 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PAS-C01 exam.