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.

• ✗

  Switch from rolling to immutable updates.

  Why it's wrong here

  Immutable updates launch a fully new Auto Scaling group with the new version and only shift traffic after all instances pass health checks. While this strategy can improve overall deployment safety, it does not address the root cause of the problem: the application needs more time to stabilize before its first health check. The same aggressive health check interval applies to the new immutable instances, so a slow-starting application will still be marked unhealthy and replaced. Therefore, changing the deployment strategy is an unrelated and heavier-handed change than simply tuning the health check timing.

• ✓

  Increase the health check interval to allow more time for the application to stabilize.

  Why this is correct

  Elastic Beanstalk uses Elastic Load Balancing health checks to assess instance readiness during a deployment. If an application takes longer to initialize than the configured health check interval, it can be prematurely marked OutOfService, triggering unnecessary instance replacement and deployment failure. Increasing the health check interval directly gives each instance more time to respond successfully before a health check is performed, preventing false negatives during the startup window. This is the most targeted fix for an application that is healthy but simply needs more time to stabilize.

• ✗

  Increase the batch size to 75%.

  Why it's wrong here

  Raising the batch size to 75% means that a larger fraction of your environment's instances are updated and taken out of service at the same time. This simultaneously reduces the capacity available to serve production traffic and magnifies the impact of any single instance failing a health check during the deployment. With more instances churning at once, the ELB is more likely to see enough failures to trigger scaling actions or reject traffic, making the deployment less stable, not more. The existing configuration was likely already causing too many instances to fail at once; increasing the batch size worsens that problem.

• ✗

  Decrease the deployment cooldown time.

  Why it's wrong here

  The deployment cooldown is a deliberate pause between batches that gives instances time to complete startup, pass health checks, and begin serving traffic before the next batch is touched. Decreasing this cooldown means the next batch starts before the current instances have fully stabilized, compounding startup latency and health-check failures across overlapping batches. This premature progression can cause multiple instances to fail health checks concurrently, leading to a cascading failure. Shortening cooldown is therefore the opposite of what is needed; you would want more time, not less, for instances to recover.

• ✓

  Decrease the batch size to 25%.

  Why this is correct

  Reducing the batch size to 25% limits the number of instances updated simultaneously, so fewer instances are out of service at any given moment and the impact of a slow-starting application is contained to a small subset. Each instance gets more time to stabilize and pass health checks before the next batch begins, without changing the health check interval itself. This smaller blast radius makes it less likely that the ELB sees a critical mass of unhealthy instances and triggers replacement or deployment rollback. It is a valid alternative mitigation, but it does not address the underlying health check timing as directly as increasing the interval.

Go deeper

Related to this question