TerraformVII · Resources, Data Sources, and count/for_eachProduction Terraform
Resource Replacement and In-Place Updates
What you'll learn
- Distinguish replacement from update
- Identify immutable attributes
- Predict replacement triggers
Prerequisites
None — start here.
Verified against Terraform CLI 1.9.x · OpenTofu 1.7.x · HCL 2.0 · bpg/proxmox provider 0.66+ · hashicorp/local provider 2.5+ · hashicorp/null provider 3.2+ · hashicorp/random provider 3.6+ · hashicorp/http provider 3.4+ · Ubuntu 24.04 LTS · Debian 12 (Bookworm)
Objective
Distinguish replacement from update
What this lesson covers
- Identify immutable attributes
- Predict replacement triggers
Why this matters in production
Production Terraform operations have blast radius. Resource Replacement and In-Place Updates is one of the operational controls that determines whether a change is safe to apply. Skip this lesson at the cost of not understanding a production control.
How it works
Provide an overview of the topic. This lesson covers the resource replacement and in-place updates concept, the underlying mechanism, and the production implications.
Key concepts.
- The terminology used in the topic.
- The mechanism that determines the operational behaviour.
- The production control that mitigates the operational risk.
Operational implications.
The resource replacement and in-place updates concept affects the production change-management workflow. A change in this area has blast radius across the entire estate.
How to configure it
Apply the configuration pattern:
- Set up the configuration block.
- Validate the configuration.
- Run the plan.
- Verify the operations.
- Document the change.
How to inspect it
Inspection pattern:
- Use the relevant CLI command to inspect the state.
- Verify the configuration matches the expectation.
- Confirm the plan is empty.
Validation
The validation pattern:
- Confirm the configuration is valid.
- Verify the plan is empty.
- Confirm the operations are correct.
Production failure modes
The following failure modes are the most common in production:
- Misconfiguration of the relevant parameter.
- Drift between the configuration and the real world.
- Provider failure during the apply.
- State corruption or loss.
How to recover
The recovery procedure:
- Investigate the failure.
- Identify the cause.
- Apply the remediation.
- Verify the state.
- Document the incident.
Related runbooks
The following runbooks in this course apply to this lesson:
- terraform-runbook-investigate-state-lock
- terraform-runbook-recover-partial-apply
- terraform-runbook-investigate-provider-failure
What comes next
The next lesson in VII-Resources continues the exploration of Resource Replacement and In-Place Updates. Follow the order to maintain the production-first narrative.
Knowledge check · 7 questions
Q1. What is a resource address?
Q2. When does a resource trigger replacement vs in-place update?
Q3. `count` provides stable resource identity.
Q4. When is for_each preferred over count?
Q5. Which of the following are data sources used for? (Select all that apply.)
Q6. What is the role of `lifecycle.ignore_changes`?
Q7. A resource shows a +20 to change in the plan for an attribute that should be stable. What is the most likely cause?
Passing score: 75%. Answers are checked in this browser.