Infrastructure as code

Terraform state records the correspondence between declared resource instances and remote objects, along with information needed for operations. Configuration alone does not always identify which existing object belongs to which declaration. Treat state as an operational artifact with controlled access, backup, and ownership. If several operators can modify the same infrastructure, choose a backend and workflow with appropriate locking support rather than assuming every state location serializes writers.

Assign one authoritative owner for each remote object's intended fields. Two independent state files managing the same object's lifecycle can produce contradictory plans. Separate environments and teams where their failure boundaries justify separation, while making shared dependencies explicit. A reusable module does not automatically create a state boundary or an independent release process. Name those boundaries so an on-call engineer knows which operation can affect which production services.

A plan describes proposed operations against the information available during planning. Review replacements, deletions, identity changes, and dependencies, not just the count of added resources. A saved plan supports an approval workflow, but it does not freeze remote services or guarantee that every later API call succeeds. Sensitive values may appear in plan or state artifacts, so their storage and sharing need the same deliberate access policy as other operational secrets.

An apply across several providers is not one atomic database transaction. If creating a network succeeds and creating a database fails, recovery must reconcile that partial outcome. Preserve diagnostic state and inspect the next plan before retrying. Hand-editing remote resources during an incident may be necessary, but record the intervention and reconcile it afterward. A break-glass workflow that permanently leaves code and reality disagreeing creates uncertainty for the next apparently harmless deployment.

Combine resources that must evolve together, and separate unrelated high-impact systems when the coordination cost is acceptable. A single global apply is convenient until a provider failure blocks changes to every team. Extremely fragmented states can create their own brittle dependency network. Evaluate the duration of locks, frequency of cross-boundary changes, and restoration complexity. The objective is a manageable unit of ownership and recovery, not the maximum possible number of repositories or state files.

A simple probability calculation can illustrate why a larger batch creates more opportunities for trouble, but real failures are often correlated. Provider outages and a shared template bug can affect all resources at once. Use review gates, policy checks, a test environment, and small production steps to test actual mechanisms. Keep a rehearsed recovery path for state loss and accidental deletion; storing the declaration is not a substitute for protecting the data held by the declared service.