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.

• ✗

  Canary deployment

  Why it's wrong here

  A canary deployment (often conflated with blue/green) directs a small percentage of production traffic to a new version running alongside the old fleet. However, the question specifies automatic rollback based on health checks, which is not inherent to canary: canaries are typically used for manual observation or metrics-driven promotion, and they do not automatically shift all traffic back if the health check fails. Without a mechanism to programmatically abort and revert, a canary leaves the majority of users on the old version and only the test cohort affected, so it is not the best fit for a fully automated, health-check-driven rollback deployment.

• ✓

  Blue/green deployment using a new Auto Scaling group and an Application Load Balancer

  Why this is correct

  Blue/green with a new Auto Scaling group and an Application Load Balancer is the correct answer because it creates a fully independent second environment (green) with its own ASG, then shifts traffic at the ALB listener level from the old (blue) to the new (green) target group. If health checks on the green target group fail or any deployment validation fails, the ALB can instantly route traffic back to the blue target group, making rollback a trivial DNS/rebinding change. This pattern avoids in-place modifications, eliminates downtime, and is explicitly designed for automated health-check-based cutover and rollback.

• ✗

  Rolling update via an Auto Scaling group

  Why it's wrong here

  A rolling update via an Auto Scaling group replaces instances in-place, typically by updating the launch template or using a rolling update strategy such as CloudFormation's UpdatePolicy or ASG's instance refresh. During the process, the ASG may temporarily have a mix of old and new instances, and if the new instances fail their health checks, the ASG keeps replacing them in batches, which can cause repeated failed launches and partial capacity loss. Rolling updates cannot instantly roll back to a known-good fleet because the old instances are gradually terminated; you would have to re-roll back by changing the launch template and refreshing again, which is slower and less deterministic than switching target groups.

• ✗

  In-place deployment

  Why it's wrong here

  An in-place deployment updates the existing instances directly—for example, by running a user data script, reconfiguring the operating system, or replacing the AMI on the running machines. This approach is risky because there is no isolation between environments: a failed deployment can leave the fleet in a broken, half-updated state, and rollback usually requires either re-running the automation or restoring snapshots, which can be slow and disruptive. AWS best practices favor immutable infrastructure where new instances are provisioned for a deployment, rather than mutating existing servers, because in-place changes make it difficult to roll back quickly and reliably based purely on health checks.

Go deeper

Related to this question