TL;DR: Providers mark specific attributes as forcing replacement; touching one schedules a destroy-then-create by default, which is downtime plus collateral damage to attached resources. Steer outcomes with lifecycle: create_before_destroy for stateless capacity, prevent_destroy for data-bearing resources, ignore_changes for fields other systems own, moved blocks for renames that must not touch the object.
How to approach it
Explain the mechanism first (schema-driven, visible in the plan's forces-replacement reason) before the levers, then close with the operational consequences that make the answer stick: collision windows and quota headroom.
A strong answer
Replacement is declared in provider schema, not inferred. Attributes marked as requiring replacement cannot mutate in place, so a plan that changes one renders the resource as -/+ with a "forces replacement" reason naming the triggering attribute. Change an EC2 instance's subnet or AMI and the instance itself is replaced; change its monitoring setting and it updates in place. Dependent resources then see a new ID and update their references, which is how one replacement ripples outward.
Default sequencing is destroy, then create, chosen because names and addresses must free up first. The cost is an outage window plus the worst failure mode in IaC: creation fails after destruction succeeded, leaving a hole where the resource was. The lifecycle block hands you the levers:
| Lever | Behaviour | Reach for it when |
|---|---|---|
| create_before_destroy | Orders successor creation before predecessor deletion; application cutover needs its own readiness checks | Stateless tiers, certificates |
| prevent_destroy | Rejects destroy/replacement while the rule remains in configuration | Databases, buckets holding data |
| ignore_changes | Attribute excluded from diffs | Autoscaler-owned fields, externally managed tags |
| moved block | Rewrites address, object untouched | Renames and restructures |
This partial target-group example omits protocol, port and VPC inputs:
resource "aws_lb_target_group" "api" {
name_prefix = "api-"
lifecycle {
create_before_destroy = true
}
}
create_before_destroy buys availability and spends headroom. Both objects coexist briefly, so names must differ (prefixes plus random suffixes beat counters), ports and addresses must not collide, and quotas must absorb double capacity during the window.
That last constraint is the one that fails at apply time rather than at review time, and it is arithmetic. A fleet of 40 instances against a regional quota of 60 has 60 − 40 = 20 spare, so a create-before-destroy replacement of all 40 needs 80 and stops at 60, twenty resources into the roll. The apply fails partway with a mixture of old and new, which is recoverable but is exactly the surprise nobody scheduled. Replacing in batches of 20 fits, and so does raising the quota first, but both are decisions to make before the change window rather than during it. The check is one subtraction: does the largest batch you will have in flight fit inside the headroom, counting every resource type the replacement touches, since addresses, target groups and security group rules each have their own ceiling. Get that right and replacements roll like deployments; get it wrong and the apply fails halfway with the old resource still alive, annoying but recoverable, unlike the reverse order's hole.
Data-bearing resources get prevent_destroy plus engine-native change paths. Recreating a database means restore-from-backup as a career activity: schema travels through migration tooling, sizing through engine operations, and Terraform plans should show near-zero diffs on the instance itself. Pair prevent_destroy with platform-level deletion protection, since the lifecycle block only guards the Terraform path while present; removing the resource block removes this protection.
The immutable mindset ties it together: instances as replaceable cattle roll through ASGs without ceremony, while the few pet resources carry protection and backups. Neither posture is wrong; applying the wrong one to the wrong resource is.
What interviewers probe next
"Rename a resource without recreating it?" A moved block (or terraform state mv) rewires the address and leaves the object alone; commit the move together with the rename so reviewers see both halves.
"create_before_destroy hit a name collision. Fix?" Use provider-generated name prefixes or a suffix that changes for the replacement. A random_id without changing keepers remains stable and can collide with the old resource.
"Does ignore_changes hide real drift?" It mutes the signal permanently, so audit ignored attributes through the owning system or a separate API check; another normal plan still ignores them, and pick one owner per attribute, Terraform or the other system, never both.
Common mistakes
Blanketing create_before_destroy across every resource, then debugging port conflicts and quota failures mid-cutover.
Assuming replacement is safe because state lives elsewhere, while the ephemeral local volume, elastic IP, or DNS record pointing at the old node dies unnoticed.
Reaching for terraform apply -replace to "fix" a flaky resource without checking what depends on its current ID, converting one unhealthy instance into an hour of reference cleanup.
Sources: Lifecycle rules.