This trace follows the actual state transitions behind the companion Infrastructure Changes Need Reviewable State. It describes a common execution path; implementation details can vary, so keep the contract separate from the mechanism.
Step 1: Declare resource configuration
Infrastructure as code describes resources and their relationships in versioned files. A planning step compares the declared target with provider state and proposes changes. This makes infrastructure reviewable alongside application changes, but the plan is only as trustworthy as its inputs and state handling.
Step 2: Compare configuration with state
A change that adds a database replica can be reviewed for cost, networking, and failover consequences before apply. State records resource identities so the tool can update existing resources rather than create duplicates. Remote state storage and locking help teams coordinate concurrent changes.
Step 3: Review proposed changes
The plan shows intended provider changes against stored resource identity; review replacements, access changes, and secrets before applying.
At this point, record the state that changed and check the invariant before advancing. If the operation repeats, make clear which values persist and which are recomputed.
Step 4: Apply the plan
Drift occurs when real infrastructure changes outside the declared workflow or provider state becomes stale. Applying a broad plan can replace resources or expose secrets if review misses destructive effects. Secrets should not be committed in plain text, and state files often contain sensitive values.
Step 5: Detect and reconcile drift
A plan proposes replacing a production database after a naming change. What should reviewers check before applying it, and how can resource identity be preserved?
The trace is complete when the result satisfies the stated contract. Compare this model with the concrete runtime or system you are studying before making a performance claim.