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.

• ✗

  Use AWS CodeDeploy to perform a blue/green deployment on the existing instances.

  Why it's wrong here

  AWS CodeDeploy blue/green deployments are not natively integrated with AWS OpsWorks Stacks; the CodeDeploy agent and its deployment flow bypass OpsWorks' Chef-run lifecycle and can conflict with the stack's managed state. For blue/green you would need to provision a parallel fleet outside OpsWorks and shift traffic at the load balancer, which does not update the existing OpsWorks-managed instances in a rolling fashion. The OpsWorks Deploy command is the native mechanism for pushing application/config updates with built-in batch control.

• ✗

  Create a new Auto Scaling group with the updated AMI and terminate old instances.

  Why it's wrong here

  Creating a new Auto Scaling group from a freshly baked AMI triggers a full parallel replacement rather than an incremental rolling update; the old fleet remains until the new one is ready, then instances are terminated, so this is fundamentally different from the batched in-place updates the OpsWorks Deploy command performs. OpsWorks Stacks does not manage instances through arbitrary Auto Scaling groups, so the replaced EC2 instances would lose their layer assignments, Chef recipes, and stack lifecycle hooks unless they are manually recreated inside the same stack. This approach also breaks the legacy architecture's dependency on OpsWorks-managed configuration state and may introduce downtime during traffic cutover.

• ✗

  Manually update each instance by adding a new layer and reassigning instances.

  Why it's wrong here

  Manually adding a new OpsWorks layer and reassigning existing instances neither deploys new application code nor invokes the stack's deploy lifecycle recipes; it only changes how instances are categorized in the OpsWorks console. This manual procedure is error-prone because each instance must be re-registered and reassigned, and you would still need to run a separate deploy command afterward to actually update the application. It provides none of the automatic batching, pause intervals, or rollback behavior that you get from using the OpsWorks Deploy command to orchestrate a rolling update.

• ✓

  Use the OpsWorks Deploy command to trigger a rolling update across the stack.

  Why this is correct

  The OpsWorks Deploy command triggers the deploy lifecycle stage on the stack, running the deployment recipes that update application code and configuration on each registered instance. Because OpsWorks Stacks lets you configure the batch size and pause time, instances are updated one batch at a time while the remaining instances continue serving traffic, which minimizes downtime during the update. This is the native rolling-update mechanism for an OpsWorks-managed stack and directly addresses the requirement to update the existing fleet with minimal service interruption.

Go deeper

Related to this question