SOA-C02 Deployment, Provisioning, and Automation Practice Question

A company uses AWS OpsWorks to manage a stack of EC2 instances running a web application. They recently migrated to AWS Elastic Beanstalk for easier deployments. However, after the migration, some users report that the application is responding slowly during peak hours. The Elastic Beanstalk environment is configured with a load balancer and auto scaling based on average CPU utilization. What should the SysOps Administrator do to troubleshoot the performance issue?

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

✓

Review the CloudWatch metrics and logs for the Elastic Beanstalk environment.

Reviewing CloudWatch metrics and logs from the Elastic Beanstalk environment can identify if the auto scaling policy is not aggressive enough or if there are other bottlenecks. Option A is wrong because manually scaling the environment is a reactive measure that does not help identify the root cause of the performance issue. Option B is wrong because reverting to the OpsWorks stack would be a step backward and does not address the current environment's performance problem. Option D is wrong because increasing instance size without analysis may be inefficient and not resolve the underlying issue.

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 scale the environment to add more instances.
Why it's wrong here
Manual scaling is a reactive stopgap that adds capacity without investigating the underlying metric or log anomaly. Elastic Beanstalk already supports automatic scaling policies based on CloudWatch alarms, so manually adding instances ignores the configured architecture and may introduce inconsistencies. Without first reviewing metrics, the true cause could be a code defect, database saturation, or a failing deployment that manual scaling will not remedy.
✗
Revert to the OpsWorks stack configuration.
Why it's wrong here
Reverting to your previous OpsWorks stack configuration would abandon the Elastic Beanstalk migration and restore an entirely different management paradigm, not fix the application performance issue. Since OpsWorks and Elastic Beanstalk use different deployment, monitoring, and scaling models, the original stack may not even reproduce the same environment. The immediate need is to inspect the current environment's telemetry, not to discard the migration work and take infrastructure backward.
✓
Review the CloudWatch metrics and logs for the Elastic Beanstalk environment.
Why this is correct
CloudWatch metrics track CPU, memory, network, and request latency, while Elastic Beanstalk aggregates application and web server logs that can expose 5xx errors, stack traces, or slow queries. Reviewing these data sources together reveals whether the performance issue is due to a bottleneck, a recent deployment, or a resource limitation, allowing you to make a data-driven adjustment. This is the correct first step before any scaling action to ensure the actual root cause is addressed.
✗
Increase the instance size in the environment configuration.
Why it's wrong here
Resizing to a larger instance type provides more vCPU and memory, but it is a blunt, costly change that may not fix a concurrency problem, a poorly written query, or a memory leak in the application. It also ignores the possibility that the environment is not properly configured for auto scaling, which could handle load variations more efficiently. Without analyzing CloudWatch metrics, you are guessing that compute capacity is the limiting factor, and you may still hit the same issue on a larger instance.

Visual reference

Go deeper

SOA-C02 Deployment, Provisioning, and Automation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question