In brief
A Terraform plan is a proposed change set based on specific configuration, variables, providers, state, credentials, and remote data at one moment. Review those inputs before reviewing the resource diff.
Key takeaways
- Review the plan generated by the same workflow that will apply it.
- Investigate every replacement and deletion before approval.
- Check identity, networking, data retention, and lifecycle effects—not only cost.
- Apply a saved reviewed plan and verify the actual Azure state afterward.
Confirm the plan context
Before reading resource changes, verify the repository revision, root module, workspace, backend, variable files, environment values, Terraform version, provider lock file, and execution identity. A correct-looking plan for the wrong subscription or state is still dangerous.
Refresh and data-source behavior can change the result between runs. Production approval should refer to a saved plan artifact generated in the controlled delivery workflow. Applying a new, unreviewed plan after approval breaks the relationship between review and execution.
Review create, update, replace, and delete actions
Read the summary first, then examine every destructive or replacement action. A replacement can create downtime, change an IP address, rotate an identity, recreate a private endpoint, or remove data depending on the resource. Determine why Terraform proposes replacement and whether the lifecycle matches the service's recovery requirements.
For updates, inspect sensitive operational properties such as network access, TLS, identity, zones, SKU, storage, retention, backup, diagnostic settings, and tags. Computed values marked as unknown deserve attention when they influence downstream resources or access policies.
- Confirm deletions are intentional and covered by retention or backup requirements.
- Review create-before-destroy behavior, name uniqueness, quotas, and temporary capacity.
- Check moved or imported resources so addresses match the real ownership model.
- Investigate drift instead of automatically accepting it into configuration.
Evaluate Azure-specific blast radius
Trace dependencies beyond the individual resource. Network changes can affect private DNS and hybrid routing. Identity changes can remove data-plane access. App Service changes can restart workers. Key Vault and storage controls can block applications that appear unrelated in the plan output.
Check Azure Policy, management locks, role permissions, regional quotas, maintenance windows, and downstream automation. Verify that credentials used by the apply have only the required scope and that secrets are not stored in ordinary variable files or exposed in plan artifacts.
Apply and verify the reviewed change
Apply the saved plan from the controlled workflow. Monitor Terraform output and Azure Activity Log, but remember that a successful apply confirms resource operations, not application health. Run service-level checks that match the user path and intended result.
Confirm monitoring, diagnostics, backup, security settings, and ownership after deployment. If the actual outcome differs from the reviewed intent, stop follow-on changes and determine whether configuration, provider behavior, policy, or runtime state explains the difference.