DOP-C02 SDLC 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 deployment group is associated with an Auto Scaling group that launched new instances during the deployment.

  Why it's wrong here

  New instances launched by an Auto Scaling group during an active CodeDeploy deployment are integrated through lifecycle hooks and receive the same deployment if they become part of the deployment group while it is running. They would not be left on the previous version independently of the existing fleet, so this scenario does not explain a split between old and new versions. The inconsistency described in the question requires a deployment that fails before all targets are transitioned, which ASG scaling alone does not produce.

• ✓

  The deployment group was configured with the 'AllAtOnce' deployment configuration, and the deployment failed partway through.

  Why this is correct

  With the AllAtOnce deployment configuration, CodeDeploy targets every instance in the deployment group simultaneously, but if a failure occurs partway through, the deployment stops without rolling back unless you explicitly enabled automatic rollback. Instances that already received and ran the new revision keep it, while instances that were not yet updated remain on the old revision, yielding a mixed state across the fleet. This is exactly the situation that would leave some instances running the previous version and others running the new version.

• ✗

  A lifecycle hook is configured to pause the deployment until manual approval.

  Why it's wrong here

  A lifecycle hook that pauses the deployment for manual approval stops the entire deployment at a predetermined lifecycle event (such as BeforeInstall) before any instance proceeds to install the new revision, so all instances stay at the exact same stage. It does not let some instances update while others wait, because the pause applies to the whole deployment group. The result is a uniformly stale fleet, not a mixture of old and new versions.

• ✗

  The deployment was configured to use a blue/green strategy, but the target group is misconfigured.

  Why it's wrong here

  A blue/green deployment does not incrementally update individual instances; it launches a separate green fleet, runs health checks, and then shifts traffic from the blue fleet to green as a cohort. If the target group is misconfigured, the deployment would fail health checks or traffic shift, causing CodeDeploy to stop or roll back before the new fleet is fully in service. This would leave the old fleet entirely in service rather than a partial mix, so it cannot account for some instances being on the old version while others are on the new version.

Go deeper

Related to this question