TERRAFORM / ILLUSTRATIVE SCENARIO
Terraform plan passed. Is your production deployment safe?
Your team reviews a Terraform plan. The changes look reasonable. The apply finishes successfully. A few minutes later, customers cannot reach the application.
That sequence is possible because infrastructure convergence and application health are different checks. Terraform can report that a provider accepted a resource change without proving that a customer’s complete request still works.
Start with the customer request
Consider an illustrative service: a load balancer routes traffic to application containers, which connect to a database. A network rule changes. The rule itself is valid and the update succeeds, but the application loses a connection it needs. The infrastructure operation is complete; the service is unhealthy.
Read the plan as a change proposal
A plan helps you review intended resource changes, including updates, replacements and deletions. It is not a complete application integration test. Review the affected traffic paths, identity permissions and dependencies alongside the resource diff.
Make the change smaller
Separate unrelated changes. Confirm the target account, environment and state before applying. Use reviewed code and a controlled deployment workflow so the approved change is the one that reaches production. Test in a representative staging environment where possible; staging reduces uncertainty but cannot guarantee production behavior.
Verify beyond the infrastructure layer
After applying, check more than whether resources exist. Exercise a representative customer request, inspect error rates and latency, and check application dependencies. Define the observation window and stop conditions before beginning, based on the service’s traffic and risk.
Plan recovery before approval
Reverting configuration is not always a safe rollback. Deleted data, database changes and resource replacement can require a different recovery path. Protect state, verify backups where relevant, and write down who can stop the change and how the service will recover.
A practical pre-change checklist
- Are the account, environment and state correct?
- Which resources will be replaced or deleted?
- Which customer traffic paths and dependencies may change?
- How will we verify service health after the apply?
- What signal makes us stop, and who owns the decision?
- Is the recovery procedure appropriate for this specific change?
The principle: treat an infrastructure apply as a step in a release, then verify the outcome at the service boundary.
This is a general engineering guide, not a description of an employer’s systems or a claimed client engagement.