In a deployment where a race condition caused a user's data script to fail, what is the least disruptive fix?

• A. Run terraform taint against the virtual machine resource name, then terraform apply
• B. Restart the virtual machine from the cloud portal
• C. Run terraform apply again
• D. Run terraform destroy then terraform apply

Answer: (A)

The key idea is to force Terraform to recreate the problematic resource so the provisioning runs again on a fresh instance. Tainting the virtual machine marks it as needing replacement. When you apply after tainting, Terraform will destroy the old VM and create a new one, letting the user-data script (the provisioning) run anew. This targets only the faulty resource, minimizes downtime, and avoids touching other infrastructure or state.

Restarting the VM through the cloud portal doesn’t update Terraform’s state or trigger a new provisioning run in the same controlled way, so the next apply may not redo the user-data script or reflect the intended changes in state. Simply running apply again without a change usually results in no action, so it won’t guarantee the race condition is resolved. Destroying everything and reapplying is overly disruptive and risks more downtime and unintended consequences, especially if other resources are tied to the same environment.

So, taint-and-apply selectively recreates the affected VM, ensuring the provisioning runs cleanly on startup with the least disruption.