SOA-C02 Deployment, Provisioning, and Automation Practice Question

A company uses AWS Elastic Beanstalk to deploy a web application. The environment is running low on memory, and the administrator needs to change the instance type from t2.micro to t3.small. What is the correct way to perform this change with minimal downtime?

⚠ Common exam trap

Many candidates think manual changes to the Auto Scaling group (Option D) are acceptable, but Elastic Beanstalk treats such manual modifications as configuration drift, which can cause the environment to become out of sync and fail subsequent managed updates.

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

✓

Modify the instance type in the Elastic Beanstalk environment's configuration.

Modifying the instance type in the Elastic Beanstalk environment's configuration triggers a rolling update or immutable update, which replaces instances with the new type while keeping the environment running. This approach minimizes downtime because Elastic Beanstalk manages the instance replacement process automatically, ensuring that traffic continues to be served during the transition.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Modify the instance type in the Elastic Beanstalk environment's configuration.
Why this is correct
Modify the instance type by updating the 'Instances' or 'Capacity' configuration in the Elastic Beanstalk environment's management console, EB CLI, or API. Elastic Beanstalk then performs a rolling update, replacing EC2 instances in batches to keep the application available, and automatically updates the Auto Scaling group's launch configuration. This is the fully supported path for resizing compute resources in a running environment.
✗
Terminate the environment and create a new one with the desired instance type.
Why it's wrong here
Terminating the environment tears down all underlying resources—EC2 instances, Auto Scaling group, load balancer, and environment-specific settings—causing complete application downtime until a new environment is provisioned and passes health checks. Recreating a stack takes many minutes and risks configuration drift, loss of manually attached resources, and unnecessary operational overhead. A simple instance-type change does not warrant such a disruptive approach.
✗
Create a new environment and perform a swap URL.
Why it's wrong here
Creating a new environment and then performing a URL swap is a blue/green deployment pattern used for testing a new platform version, configuration, or code release before shifting production traffic. It does not resize the existing environment; you would still have to configure the new environment's instance type, run both environments in parallel (incurring double costs), and wait for the new environment to be healthy before swapping CNAME URLs. For a straightforward capacity change, this adds unnecessary complexity and delay.
✗
Manually modify the Auto Scaling group's launch configuration.
Why it's wrong here
Manually editing the Auto Scaling group's launch configuration is unsafe because Elastic Beanstalk owns and manages that ASG as part of the environment's lifecycle. Direct changes are not tracked by Elastic Beanstalk and can be overwritten during a configuration update, platform deployment, or health-based replacement. Because launch configurations are immutable, you would need to create a new one anyway, and future scaling events following manual drift could still launch the old instance type if EB resets the environment to its declared configuration.

Go deeper

SOA-C02 Deployment, Provisioning, and Automation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question