Most engineers treat create_before_destroy like a safety toggle.
It is not.
Terraform replaces a resource when an identity-level argument changes. The provider marks that argument as ForceNew. That converts a simple update into a destroy plus create operation.
By default, destroy happens first.
create_before_destroy = true reverses the order. Terraform attempts to create the new object before removing the old one. That sequencing reduces outage risk only if the system can temporarily support both objects.
This is where many teams misunderstand the mechanism.
Some APIs enforce uniqueness constraints. If two objects cannot exist in parallel, the create step fails. The old object remains, but the transition cannot proceed. The flag did not increase safety. It exposed a constraint.
Even when creation succeeds, downtime can still occur if dependents cannot rebind cleanly to the new identity.
The real lesson is structural: replacement is about identity, not configuration.
Understanding that distinction is what prevents outages during refactors.