SOA-C02 Deployment, Provisioning, and Automation Practice Question
A company is using AWS Elastic Beanstalk to deploy a web application. The application experiences high traffic during peak hours. The SysOps administrator wants to automatically scale the environment based on CPU utilization. Which configuration change is required?
⚠ Common exam trap
Watch out — candidates often confuse vertical scaling (changing instance size) with horizontal scaling (adding/removing instances), or they assume manual actions like adding instances or load balancers are valid automation strategies for Elastic Beanstalk environments.
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 a scaling trigger based on a CloudWatch alarm for CPU utilization.
AWS Elastic Beanstalk integrates with Amazon CloudWatch and Auto Scaling to allow you to define a scaling trigger based on a CloudWatch alarm for CPU utilization. When the alarm threshold is breached, the Auto Scaling group automatically adds or removes EC2 instances, enabling the environment to handle high traffic during peak hours without manual intervention.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Manually add EC2 instances to the Auto Scaling group.
Why it's wrong here
Manually adding EC2 instances to the Auto Scaling group via the EC2 console or CLI is an ad hoc, operational action rather than a scaling policy. Elastic Beanstalk manages the Auto Scaling group's desired capacity, and any manual changes are often overridden during configuration updates, deployments, or environment rebuilds, so the fleet size ultimately reverts to the Elastic Beanstalk configured value. Because there is no CloudWatch alarm integrated into this process, it cannot react automatically to changes in CPU utilization or request load—which is why it does not satisfy the requirement to automate scaling.
- ✓
Configure a scaling trigger based on a CloudWatch alarm for CPU utilization.
Why this is correct
This is the correct approach because Elastic Beanstalk's Auto Scaling group uses CloudWatch alarms to drive scaling actions based on the average CPU utilization of the EC2 instances in the environment. You can define a scaling trigger—either a simple/step scaling policy tied to a CloudWatch alarm or a target tracking policy that continuously adjusts capacity to keep CPU near a target value. When the alarm enters an ALARM state (e.g., CPU exceeds 70% for 5 minutes), the policy proactively launches additional instances, and when it returns to OK, it terminates excess instances, providing dynamic, workload-aware scaling.
- ✗
Modify the instance type to a larger size.
Why it's wrong here
Changing the instance type in the Elastic Beanstalk environment modifies the instance family/size specified in the launch configuration or launch template, but it does not alter the number of running instances or the Auto Scaling group's min/max/desired values. This is vertical scaling, which can only make each individual server more powerful; it cannot respond to sudden spikes in traffic because the fleet size remains static. Moreover, updating the instance type typically triggers a rolling replacement of all instances, causing downtime and requiring manual intervention, so it fails to meet the need for automatic scaling based on demand.
- ✗
Increase the number of load balancers.
Why it's wrong here
Increasing the number of load balancers in front of the application does not affect the Auto Scaling group's capacity, because load balancers only distribute traffic across the existing pool of instances. In a standard Elastic Beanstalk environment, there is exactly one managed load balancer (usually an Application Load Balancer) attached to the environment; adding extra load balancers is not a supported configuration for a single environment and would not cause the Auto Scaling group to launch or terminate instances. Since the ASG's minimum, maximum, and desired capacity remain unchanged, the number of EC2 instances stays fixed regardless of how many load balancers are placed upstream.
Go deeper
Related to this question
About these practice questions
One of 1,169 original SOA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SOA-C02 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 SOA-C02 exam.