Fifty application instances are declared with count, and each image change makes Terraform replace them, which takes the service down. Cloud quotas do not allow doubling capacity, and the team wants replacement in health-checked batches. Which change best meets these goals?
Select an answer to reveal the explanation.
Short Explanation
Terraform is great at saying what the fleet should look like, but it's not a traffic cop watching health checks. So you hand the 'one batch at a time' job to the platform's instance group, which was built for it. Terraform just updates the template and lets the group roll.
Full Explanation
Terraform replaces resources by walking its dependency graph; it has no notion of application health between replacements, so individually declared instances are replaced as fast as the graph and parallelism allow. Cloud platforms provide managed instance groups or autoscaling groups with rolling update or instance refresh policies that replace instances in controlled batches, wait for health checks, and respect minimum healthy capacity. Moving the fleet into such a group lets Terraform manage the group and its instance template, while the platform performs the batched, health-gated rollout when the template changes. create_before_destroy would create all fifty replacements before deleting the originals, which needs double capacity that the quota forbids, and it still does not wait for application health. -parallelism caps how many operations run at once, but it neither orders replacements into batches nor checks health. Using -target for routine releases is explicitly discouraged; it is meant for exceptional recovery and leaves configuration and state out of step between rounds. Exam caveat: rolling update settings are provider-specific arguments, so verify their names in the provider documentation. Operational check: change the template in a test environment and watch the group replace instances batch by batch while health checks stay green.