Understanding Replacement

Scenario: Changing an immutable certificate attribute turns a harmless-looking edit into destroy-and-create downtime.

Providers mark some attributes as requiring replacement. Plan symbols show ordering: destroy-then-create can cause downtime, while create-before-destroy requires coexistence and unique naming. Trace replacement reasons in the plan instead of counting changed lines. Dependent resources may also update or replace when an ID changes.

Analogy: Replacing infrastructure is moving house. Building the new house first avoids homelessness, but only if you can own both addresses temporarily.

A worked configuration

resource "fakecloud_certificate" "edge" {
  common_name = "api.example.test"
  lifecycle { create_before_destroy = true }
}

Verify quotas, uniqueness constraints, traffic cutover, health checks, rollback, and cleanup. create_before_destroy is not automatically zero downtime; consumers still need a controlled transition.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

Goal: Reinforce this lesson in the tf-certificate-renewal Terraform lab. Open /labs/terraform and choose slug tf-certificate-renewal; the lab runs real Terraform against the offline FakeCloud provider.