DevOps / Intermediate: controlled delivery systems / Lesson 8
Infrastructure as code, plans, and state
Understand declarative intent, provider behavior, state sensitivity, and review boundaries without provisioning infrastructure.
On this page
Lesson goals
- Distinguish desired configuration, state, and remote reality.
- Review targets and destructive plan consequences.
- Protect coordination, sensitive state, and recovery evidence.
Declarative intent still causes effects
Infrastructure as code records desired resources in reviewable files and uses tools and provider APIs to reconcile them. It does not make changes harmless or automatically reversible. A small text edit can replace storage, alter access, or delete a network boundary. This lesson uses OpenTofu concepts; Terraform has related concepts but versions, providers, licensing, and state compatibility require their own review. No plan, apply, import, or state mutation is executed here. Treat the configuration, provider versions, target account, and state backend as one explicit change boundary before authorizing a real operation.
Distinguish configuration, state, and reality
Configuration expresses intent; state maps managed resource addresses to provider objects and records information needed for reconciliation; the provider’s actual system is another source of evidence. State is not the same as a backup of the application’s data. It can contain sensitive values even when output is marked sensitive. The first teaching diagram separates these three views and highlights drift when reality changes outside the workflow. Do not edit or delete state to silence an unexpected plan. Preserve a protected copy and follow the tool’s documented recovery process with the resource owner.
configuration -> declared resource intent
state -> managed identity and reconciliation data
provider API -> actual remote objects
drift -> observed reality differs from reviewed intent
The views have different roles. State can be sensitive and is neither the desired configuration nor an application backup. This diagram invokes no tool.
Review the target and the proposed effect
A plan compares declared intent with observed managed state and proposes actions. It is time-sensitive evidence, not a permanent guarantee. Changes in configuration, provider behavior, credentials, or the target after review can invalidate assumptions. Identify the account, region, workspace, backend, and provider versions before interpreting a diff. Separate creation, in-place update, replacement, and destruction. The second example is a synthetic plan-review record with a destructive change explicitly blocked. It is not actual plan output and cannot be applied. A reviewer needs business impact, not merely a count of changed resources.
target: lab-account-only
provider_lock: reviewed
proposed:
create: 1
update: 2
replace_storage: 1
decision: blocked-pending-data-recovery-review
One storage replacement dominates the risk despite a small resource count. The record is editorial data, not OpenTofu plan output or an executable approval.
Protect coordination and credentials
Use an access-controlled backend with appropriate locking, encryption, retention, and recovery for the selected tool and backend. Lock support varies and must be verified; a local file shared by convention does not coordinate independent automation safely. Give jobs only the provider permissions they require and separate environments intentionally. A force unlock is not a routine response to waiting because another writer may still be active. Prefer reusable modules with narrow inputs, validate assumptions, and review provider upgrades. A module that hides resource replacement behind an innocent variable can make review harder rather than safer.
Design recovery before authorization
Determine what can be recreated, what data must be preserved, and which operations need maintenance windows or human approval. Test modules and policy logic in harmless local simulations where possible, then use an authorized disposable environment for provider integration. Preserve plan evidence without exposing secrets. Reverting configuration does not restore deleted data, remove every external effect, or guarantee the previous topology. Include application and database dependencies in the change review. Infrastructure automation becomes dependable through controlled scope, observable effects, and tested recovery rather than through a promise that every declarative change is reversible.
Common errors and fixes
The plan targets the wrong environment
- Why it happens
- Workspace, credentials, or backend selection was assumed.
- How to fix it
- Stop and verify the complete target identity before change.
- Prevent it next time
- Make target context explicit in review evidence.
Sensitive output hides secrets only on screen
- Why it happens
- Display redaction was mistaken for protected state storage.
- How to fix it
- Protect state and plan artifacts as sensitive material.
- Prevent it next time
- Restrict backend access and test secret-handling policy.
Reverting files does not restore data
- Why it happens
- Resource recreation was confused with data recovery.
- How to fix it
- Use verified backups and a reviewed recovery sequence.
- Prevent it next time
- Assess destructive actions before approval.
Check your understanding
1. A plan says one resource will be replaced. Why is the count insufficient for approval?
Show worked solution
The resource may contain persistent data or enforce a security boundary. Identify its purpose, data consequences, dependencies, outage window, and recovery evidence. Approve the understood effect on the correct target rather than treating one as a small numerical risk.
2. A teammate changed a resource manually. Should state be deleted to remove drift?
Show worked solution
No. Preserve evidence, identify whether the change was authorized, compare desired and actual state, and follow a reviewed reconciliation or import procedure. Deleting mappings can create unmanaged resources or duplicate creation attempts and does not repair the underlying ownership question.
Key takeaways
- Infrastructure as code records desired resources in reviewable files and uses tools and provider APIs to reconcile them.
- A plan compares declared intent with observed managed state and proposes actions.
- Determine what can be recreated, what data must be preserved, and which operations need maintenance windows or human approval.