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.

• ✓

  The health check grace period on the Auto Scaling group is too short.

  Why this is correct

  The health check grace period on the Auto Scaling group is too short. When a deployment launches new instances, the ASG considers an instance healthy only after the grace period expires; if the period is shorter than the time CodeDeploy needs to install the application and pass its own validation, the ASG will prematurely flag the instance as failing ELB health checks. Auto Scaling then terminates and replaces the instance mid-deployment, which CodeDeploy sees as a failed deployment ("too many individual instances"), and the cycle repeats for each new replacement. The correct fix is to increase the grace period to exceed the typical deployment duration.

• ✗

  The target group deregistration delay is too long.

  Why it's wrong here

  The target group deregistration delay is too long. Deregistration delay controls how long an instance that is being removed from service can continue to handle in-flight requests before it is forcibly closed; it does not affect the health check status of instances during a CodeDeploy deployment. A longer delay would only cause a slight lag before the old instance is detached, but it would not cause new instances to fail their health checks or be considered unhealthy. Therefore, this setting does not contribute to the reported "too many individual instances" failure.

• ✗

  The CodeDeploy agent is not installed on the instances.

  Why it's wrong here

  The CodeDeploy agent is not installed on the instances. If the agent were missing, the very first instance in the deployment would fail immediately because CodeDeploy could not connect to it, usually with an error like "The overall deployment failed because too many individual instances failed deployment" right away. The scenario describes repeated failures over time, which suggests instances are being replaced and each new one briefly fails—this is more consistent with a health check timing issue rather than a missing agent. Additionally, the problem statement implies the deployments are progressing through the initial steps, which would not happen without a working agent.

• ✗

  The deployment group is configured to skip the ELB health check.

  Why it's wrong here

  The deployment group is configured to skip the ELB health check. If the ELB health check is skipped, CodeDeploy would not register instances with the target group or would not monitor their ELB health during deployment, so it would not fail deployments based on health check status. That would eliminate the very problem described (instances being marked unhealthy and replaced), meaning the deployment would likely succeed rather than repeatedly fail. Thus, skipping the ELB health check is not a plausible cause for this error; it would actually prevent the symptom from occurring.

Go deeper

Related to this question