SOA-C02 Deployment, Provisioning, and Automation Practice Question
A company uses AWS Elastic Beanstalk for a Java application. The environment uses a custom platform. The SysOps administrator wants to update the environment's configuration to use a larger instance type to handle increased load. What is the correct way to perform this change with minimal downtime?
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
✓
Use the Elastic Beanstalk console to update the instance type and choose a rolling update strategy.
Elastic Beanstalk allows you to update the environment's configuration, such as instance type, via the console or CLI. To minimize downtime, you can choose a rolling update strategy, which updates instances in batches, ensuring that the environment remains available throughout the process. Option B is incorrect because manually SSHing into instances is not a scalable or persistent solution; Elastic Beanstalk manages the instances and changes may not survive environment updates. Option C is incorrect because terminating all instances causes complete downtime until the new instances are launched. Option D is incorrect because while creating a new environment and swapping URLs (blue/green deployment) can achieve zero downtime, it is more complex and resource-intensive than necessary for a simple instance type change, and the question asks for minimal downtime with correct method.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use the Elastic Beanstalk console to update the instance type and choose a rolling update strategy.
Why this is correct
The Elastic Beanstalk console provides a supported, declarative way to change the environment's instance type. When updated, Elastic Beanstalk modifies the Auto Scaling launch configuration and then applies a rolling update strategy, progressively replacing instances so that at least the minimum capacity stays available. This preserves all environment-level settings and can be done with minimal or zero downtime, making it the correct approach.
- ✗
SSH into each instance and modify the instance type manually.
Why it's wrong here
SSHing into each EC2 instance cannot alter the instance type because that attribute is fixed at launch and determined by the Auto Scaling launch template or configuration, not by any runtime command. Even if you manually stopped and resized the underlying instance, Auto Scaling would immediately replace or revert it based on the original launch configuration, which still references the old instance type. This approach also lacks centralized management, does not scale beyond the current instances, and leaves no audit trail, so it is not a reliable or persistent solution.
- ✗
Terminate all instances and launch new ones with the larger instance type.
Why it's wrong here
Terminating all instances and launching new ones yourself drops the environment's capacity to zero, causing complete application downtime. Any instances launched separately would not be attached to the Elastic Beanstalk-managed Auto Scaling group or receive the environment's configuration, so the architecture would break. A controlled rolling or immutable update is designed to replace instances without an outage, which is the intended path for changing capacity while staying within Elastic Beanstalk's management plane.
- ✗
Create a new environment with the larger instance type and swap the environment URLs.
Why it's wrong here
Creating a new environment with a custom platform solely to change the instance type introduces unnecessary complexity and potential delays in replicating the custom platform setup. While URL swapping provides near-instant traffic redirection, the overall time to provision and configure a new environment with the specific custom platform details might be substantial, negating the "minimal downtime" objective compared to an in-place update. This approach is typically used for blue/green deployments when deploying a new application version or a major platform update, where a completely separate, pre-validated environment is desired before switching.
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.