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.

• ✓

  Initiate a rollback from the CodeDeploy console to redeploy the previous working revision.

  Why this is correct

  CodeDeploy's rollback feature automatically redeploys the last known successful revision to every instance in the deployment group, using the same AppSpec and lifecycle hooks to ensure a clean, consistent transition. The rollback is initiated from the console and runs as a new deployment, honoring deployment configuration settings such as minimum healthy hosts, so it performs a proper rolling update rather than a crude file copy. This restores the working state and provides audit logs for what was rolled back and when, making it the correct and safe recovery method.

• ✗

  Stop the deployment immediately; the instances that have already been updated will revert automatically.

  Why it's wrong here

  Stopping a deployment in the CodeDeploy console only aborts the remaining deployment steps; it does not issue any commands to instances that have already received and executed the new revision. Instances that completed the deployment continue running the new, likely flawed application code with no automatic rollback to the prior version. Stopping is useful for halting further propagation, but you must then initiate a rollback or redeploy a known-good revision to repair the affected instances.

• ✗

  Edit the deployment group settings to pause deployments after a failure, then manually fix the instances.

  Why it's wrong here

  Adjusting deployment group settings to pause or abort on future failures changes the orchestration behavior, but it does not touch the current running application on instances that already updated. No automatic remediation is triggered by these settings; they only prevent subsequent deployments from proceeding under specified conditions. Manually fixing each affected instance is impractical, inconsistent, and can cause configuration drift, whereas CodeDeploy's rollback automates the redeployment of the previous revision across the entire group with full lifecycle event execution.

• ✗

  Redeploy the same failing revision but with a different deployment configuration.

  Why it's wrong here

  A deployment configuration controls parameters like traffic shifting speed and minimum healthy host count, not the actual application artifact or script contents. Redeploying the same failing revision with a different configuration merely changes the rollout pattern; it will still execute the same broken code, resulting in the same failure. To recover, the revision must change (or be reverted to the last successful one), so this option does not address the root cause.

Go deeper

Related to this question