Changing the domain on a TLS certificate resource forces replacement. A load balancer listener references the certificate, and in the last change Terraform destroyed the old certificate before creating the new one, which broke HTTPS for several minutes. What should the team set so the next replacement avoids that gap?
Select an answer to reveal the explanation.
Short Explanation
Think of moving house: you don't hand back the old keys until the new place is ready. By default Terraform does the opposite for replacements, destroying first and creating second. Flip that order and the listener always has something to point at.
Full Explanation
When an argument cannot be updated in place, Terraform's default is to destroy the existing object and then create its replacement. For an object that something else depends on at runtime, such as a certificate attached to a listener, that order leaves a window with nothing to serve. Setting create_before_destroy = true in the resource's lifecycle block reverses the order: Terraform creates the new certificate, updates dependents such as the listener to reference it, and only then destroys the old one. It is opt-in because many remote objects have unique name constraints, so the configuration may need a name prefix or generated name to let both objects exist briefly. prevent_destroy does not reorder anything; it makes Terraform reject any plan that would destroy the object, so the domain change could not be applied at all. ignore_changes on the domain would stop Terraform from ever applying the new domain. depends_on adds an ordering edge for creation and does not change destroy-then-create replacement behaviour. Exam caveat: create_before_destroy propagates to dependencies and can introduce cycles if misused. Operational check: the plan should show the certificate as create then destroy replacement rather than destroy then create.