SOA-C02 Deployment, Provisioning, and Automation Practice Question
A SysOps administrator is troubleshooting a failed AWS Elastic Beanstalk environment update. The update changed the configuration of the EC2 instances in the Auto Scaling group, but the new instances fail to launch. The administrator checks the Auto Scaling group's scaling activities and sees a 'Failed' status with the message: 'Instance failed to reach the desired state.' What should the administrator check next?
⚠ Common exam trap
The trap is jumping to IAM or quota issues — the specific message 'failed to reach desired state' points to instance-level health/configuration problems best diagnosed via logs.
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
✓
Check the CloudWatch logs for the failed instance to identify application or configuration errors.
When Elastic Beanstalk instances fail to launch with 'Instance failed to reach the desired state,' the next step is to examine the instance's logs (via CloudWatch Logs or the EB console's logs bundle) to identify configuration or application errors. This message typically indicates the instance launched but failed health checks or initialization, so logs reveal the root cause.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Check the IAM role attached to the environment's EC2 instances for missing permissions.
Why it's wrong here
The message indicates instances launched but failed health checks or configuration, not that the launch API was denied; missing IAM permissions typically surface as launch failures with explicit authorisation errors. Elastic Beanstalk logs and EC2 console output reveal the actual bootstrap failure. Tempting because IAM is a frequent culprit.
- ✗
Check the account service quotas for EC2 instances.
Why it's wrong here
Service quotas would produce a launch error such as insufficient capacity or instance limit exceeded, and the Auto Scaling group would not report instances reaching a pending state. The message points to instance-level bootstrap or health-check failure, so EB logs and EC2 console output are needed. Quotas are tempting as a capacity check.
- ✓
Check the CloudWatch logs for the failed instance to identify application or configuration errors.
Why this is correct
The Auto Scaling message indicates the instance launched but failed its health checks, so the fault lies in bootstrap or application configuration rather than capacity. CloudWatch logs from the failed instance expose those errors, satisfying the need to find why instances never reached the desired state.
- ✗
Check the termination protection setting on the Auto Scaling group.
Why it's wrong here
Termination protection only blocks instance termination; it cannot cause a launch to fail to reach the desired state. It is tempting because it is an Auto Scaling group setting that affects instance lifecycle, and it would be relevant if instances were being terminated unexpectedly.
Go deeper
Related to this question
About these practice questions
This SOA-C02 question is part of Courseiva's 1,169-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 →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
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.