SOA-C02 Deployment, Provisioning, and Automation Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Review the deployment configuration to ensure it allows enough time for deployment.

  Why it's wrong here

  A CodeDeploy deployment configuration includes a 'minimum healthy instances' threshold and can specify a timeout (e.g., 60 minutes). However, the error about 'insufficient healthy instances' indicates that instances are being marked unhealthy or failing readiness checks, not that the deployment exceeded its allotted time. If the deployment simply timed out, the error would explicitly state 'Deployment timed out' or 'Was not completed within the specified time limit.' Therefore, adjusting the deployment configuration's timeout window would not address the underlying health-check failure that triggers this specific error.

• ✗

  Verify that the AppSpec file includes the correct hooks.

  Why it's wrong here

  AppSpec hooks like BeforeInstall, AfterInstall, and ApplicationStart run scripts to prepare and start the application. Missing hooks might prevent the application from launching, causing instance health checks to fail — but that would typically manifest as errors on the individual instance deployment events, not as a fleet-wide 'insufficient healthy instances' message. This error instead points to how the Auto Scaling group evaluates instance liveness at the fleet level, which is independent of whether the hooks executed correctly. Even if the AppSpec hooks are perfect, an incorrectly configured health check type can still cause CodeDeploy to report too few healthy instances, making this answer incorrect.

• ✓

  Check the Auto Scaling group's health check type and ensure it is set to ELB.

  Why this is correct

  When CodeDeploy deploys to an Auto Scaling group, it relies on the group's health check type to determine whether each instance is healthy and to maintain the minimum healthy instance count. If the health check type is left as EC2 (the default), an instance is considered healthy solely because it is in the 'running' state — even if the deployed web application is not responding on the Elastic Load Balancer. Setting the health check to ELB forces the Auto Scaling group to use the load balancer's target health checks, which validate the actual application response. This directly affects the 'insufficient healthy instances' error, so checking and correcting this setting is the correct first step.

• ✗

  Check the IAM role for CodeDeploy to ensure it has sufficient permissions.

  Why it's wrong here

  An incorrectly configured IAM role for CodeDeploy would typically surface as an authorization failure, such as 'The IAM role does not allow access to the Amazon S3 bucket' or a permission error when attempting to deploy. Those permission-related errors occur before the deployment reaches the health-check phase, because the deployment cannot even proceed to launch instances. In contrast, the error about insufficient healthy instances arises after instances have been deployed and started, meaning the deployment is already past credential and permission checks. Thus, reviewing the IAM role would not resolve this health-count failure, which is a post-deployment liveness issue.

Go deeper

Related to this question