DOP-C02 Configuration Management and IaC 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.

• ✗

  Rolling update

  Why it's wrong here

  A rolling update is an in-place deployment policy where Elastic Beanstalk replaces instances in batches within the same environment, keeping the existing environment URL throughout the process. During the update, both the old and new application versions may be serving traffic simultaneously, which creates a mixed-version state and makes rollback difficult. This is not a blue/green deployment because blue/green requires two completely separate environments with independent URLs, and a DNS-level switch to shift all traffic atomically.

• ✗

  Canary deployment

  Why it's wrong here

  Elastic Beanstalk does not offer a canary deployment as one of its built-in deployment options. A true canary deployment routes a small percentage of traffic to the new version while the majority continues to the old version, and that requires traffic-shaping infrastructure that EB does not natively provide. Although EB has a 'Traffic splitting' feature, that is a separate weighted routing mechanism for testing and not the same as a classic canary deployment, and it still does not use two entirely separate environments with a URL swap. Therefore, 'Canary deployment' is not a valid answer for achieving blue/green in Elastic Beanstalk.

• ✓

  Environment URL swap

  Why this is correct

  Swapping environment URLs is the canonical blue/green deployment mechanism in Elastic Beanstalk. You first provision a second environment (the 'green' one) with your new version, verify it, and then use 'Swap environment URLs' in the console or the SwapEnvironmentCNAMEs API to make the original environment's URL instantly point to the new environment. This switch is atomic at the DNS/CNAME level, providing zero downtime, and you can equally quickly swap back to the old environment to roll back. Unlike other deployment methods, this keeps two distinct environments with separate instance fleets and configurations, which is the essence of blue/green.

• ✗

  Immutable update

  Why it's wrong here

  An immutable update is a deployment method that launches a completely new Auto Scaling group with new instances running the new version alongside the old ones, then performs health checks before terminating the old instances. However, the environment URL remains the same because the new Auto Scaling group is attached to the same Elastic Load Balancer and environment; there is no separate environment with an independent URL. This means traffic is not switched via a URL swap but rather the load balancer gradually shifts to the new instances, so it does not provide the instant rollback or isolation that blue/green requires. Because the environment identity and URL are unchanged, it is not a blue/green deployment.

Go deeper

Related to this question