devops

Three biases decide most calls:

• Applied is not in effect. A tool's success is a claim the tool makes about its own target. Whether the effect exists is measured at the service, the socket, the resolver, the peer, or the guest. A change closes on the measurement and never on the claim.
• A revert is not a rollback. Re-applying the previous declaration restores what a tool can recreate from a declaration and nothing the forward change emitted: deleted data, rotated secrets, withdrawn routes, migrated schemas, destroyed objects.
• The target is decided by the credential and the state the command runs against, not by the code. A reviewed change lands where the kubeconfig, backend, inventory, or token points, and a plan is a projection of one state at one moment. Read both before the first mutation.

Target

• Name the target by identifiers that cannot be confused: account or project ID, cluster API endpoint, host key and address, backend and workspace, node and VMID, zone ID. prod is a label, not a target. GitHub deployed a reviewed network configuration to the wrong environment on 2024-03-11.
• Plan against the state that apply will use, immediately before apply. Never apply a plan older than the last change to the target, and never a plan made with refresh disabled. GitLab applied a three-week-old Terraform plan on 2023-07-07; drift had turned it into a plan that destroyed 617 resources.
• A missing or substituted state file is a stop, not a step. With no state, a plan proposes creating everything; with an old state copied in, a destroy looks like the clean option. An agent destroyed a production VPC, database, and cluster in February 2026 by reasoning exactly that way.
• Read the plan for destroy and replace before anything else. A destroy count above zero on a change that is not a destroy, or # forces replacement on a stateful resource, stops the apply until the reason is written down.
• A blank parameter is a value. Resolved defaults are part of the plan. Google's internal tool turned one blank field into a one-year term and deleted a customer's private cloud a year later, with no notification because the deletion was not customer-initiated.
• Prefer a change that names its objects over a filter that resolves at run time. Cloudflare's 2026-02-20 cleanup called an API with an empty filter; the server returned every prefix and the task deleted them all.
• Before a firewall, sshd, auth, or routing change, hold an independent way back in: a second authenticated session, a console, or an out-of-band path, plus a timed revert that restores the previous ruleset unless the operator cancels it. The SRE workbook's rule for a change that can remove operator control is automatic rollback, or at minimum an automatic stop.
• Capture what the reverse needs before apply: the previous value, the backup taken with the method the data requires, the identifiers, and the consumers of anything renamed. Confirm the credential performing the change cannot delete that backup.
• Use the credential the change needs and no other. A broader credential found in the environment is not permission. An agent with a staging credential mismatch found a token scoped for any operation, guessed that a volume delete would stay in staging, and removed a production database and its co-located backups in one call (April 2026). Deletion protection on the resource itself is the layer that survives a removed resource block; prevent_destroy does not.
• A prose prohibition does not hold against a token that can. A code freeze in the instructions did not stop a Replit agent from deleting a production database in July 2025. Where the only guard on a destructive path is prose, say so and stop; do not proceed under it.