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.

• ✗

  Use a canary deployment instead of in-place.

  Why it's wrong here

  A canary deployment is a traffic-shifting strategy used in blue/green deployments, not in-place deployments. In an in-place deployment, the same instances are updated sequentially, so there is no separate traffic-shifting step. Configuring a canary deployment would require a blue/green environment with a separate instance set and is not applicable to the in-place deployment model. The correct approach for zero-downtime in-place updates is to manage the load balancer deregistration and re-registration.

• ✗

  Define a BeforeInstall hook to deregister instances.

  Why it's wrong here

  While you can use a BeforeInstall lifecycle hook to manually deregister instances from the load balancer, this is a fragile, anti-pattern approach. CodeDeploy already provides native load balancer integration that handles deregistration, connection draining, and re-registration automatically. Adding a custom hook introduces scripting complexity, potential failure points, and can interfere with CodeDeploy's built-in health checks and lifecycle sequencing. The recommended and more reliable way is to configure the load balancer in the deployment group settings.

• ✗

  Use a linear deployment configuration.

  Why it's wrong here

  A linear deployment configuration controls the number of instances deployed at a time (e.g., increments of 25%) but does not manage traffic shifting or connection draining. Traffic is still routed to an instance until the instance is deregistered from the load balancer; without deregistration, the application stop may cause errors. The deployment configuration only affects the pace of the deployment, not the load balancer's routing behavior. To achieve zero downtime, you must use the load balancer's deregistration delay and re-registration settings, not just a linear configuration.

• ✓

  Configure the load balancer deregistration delay and re-registration in the deployment group.

  Why this is correct

  Configuring the deregistration delay on the load balancer target group and enabling CodeDeploy's load balancer integration ensures that CodeDeploy automatically deregisters each instance, waits for in-flight requests to complete (based on the deregistration delay), performs the deployment, and then re-registers the instance. This built-in integration is the recommended way to avoid downtime during in-place deployments. CodeDeploy also waits for the instance to pass health checks before marking the deployment successful. This configuration is set in the deployment group's load balancer section.

Go deeper

Related to this question