# Infrastructure As Code > Infrastructure as Code - Skill: `handsomeboy990/infrastructure-as-code` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add handsomeboy990/infrastructure-as-code` - Raw SKILL.md: https://api.skillmd.com/api/skills/handsomeboy990/infrastructure-as-code/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: Handsomeboy990 (https://skillmd.com/u/handsomeboy990) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/handsomeboy990/infrastructure-as-code --- # Infrastructure as Code Infrastructure defined in code is reviewable, reproducible and reversible. Infrastructure created in a console is a machine nobody can rebuild and a change nobody can review. The discipline is not the tool. It is that the code is the truth, and that nothing is changed outside it. ## 1. Whether it is warranted ``` yes more than one environment must match yes the infrastructure will be rebuilt, moved or duplicated yes several people change it yes an auditor will ask who changed what, and when yes recovery requires recreating resources no a single managed platform where the entire configuration is a handful of settings in a repository file the platform already reads no a prototype that will be deleted in a fortnight ``` For a small project on a managed platform, the platform's own configuration file is infrastructure as code. Adding a provisioning tool on top is cost with no return, and refusing it is an engineering decision worth recording. ## 2. State The most dangerous object in this discipline. ``` stored remotely, never on a laptop, never in the repository locking enabled, so two applies cannot run at once versioned, so a corrupted state can be recovered encrypted, because it contains resource attributes and sometimes secrets one state per environment, never one for all access to state is access to production: treat it as a credential never edit state by hand except as a documented recovery, with a backup taken first ``` A lost or corrupted state file turns managed infrastructure back into unmanaged infrastructure, with the resources still running. ## 3. Environment separation ``` the same definitions, different variables, never copied directories that drift within a month separate state, separate credentials, separate blast radius production credentials are not available to the pipeline that plans a development change an environment's differences are explicit variables, not conditionals scattered through the code naming carries the environment, so a resource is never ambiguous ``` ## 4. Modules and boundaries ``` a module is a unit that is reused or independently changeable group by lifecycle, not by resource type: things created and destroyed together belong together the network, the data stores and the compute usually have different lifecycles and different blast radii keep the destructive surface small: a change to a compute module must not be able to delete a database version modules, and pin them, so an upstream change does not arrive during an unrelated apply ``` ## 5. Plan and apply ``` every change produces a plan, and the plan is read before it is applied the plan is reviewed by a second person for anything in production the plan is attached to the change record apply from the pipeline, not from a laptop, once the pipeline exists apply is serialised: one at a time, enforced by locking a plan that shows an unexpected replacement or deletion stops the change ``` Reading the plan is the entire safety mechanism. Applying without reading it is the console with extra steps. ## 6. Destructive changes ``` identify replacements and deletions in the plan before approving know which attribute changes force a replacement, per resource type protect stateful resources with deletion prevention where the tool offers it take a backup before any change touching a data store, and verify it exists a rename in code is usually a delete and create: move the resource in state deliberately instead a change to a network or a security boundary is reviewed by someone else, always ``` ## 7. Secrets ``` never in the code, never in variable files committed to the repository injected at apply time from the secret store outputs that would expose a secret are marked sensitive, and the state is still treated as secret because sensitive marking is not encryption generated credentials go into the secret store as part of the apply, not into a log or a console output rotation is a documented procedure, not an apply nobody dares run ``` `secrets-management` owns the lifecycle; this skill owns keeping them out of the definitions and out of the state visible to anyone. ## 8. Drift ``` detect it on a schedule, not only when something breaks report drift as a finding: someone changed production outside the code the fix is to bring the change into the code, or to revert it, decided each time and recorded emergency console changes during an incident are legitimate, and they are reconciled within days, with the incident referenced a resource that drifts repeatedly is either managed by another system or managed by a person who does not know it is in code ``` ## 9. Importing what exists Adopting existing infrastructure: ``` inventory what runs, before writing anything import resource by resource, verifying an empty plan after each an empty plan is the proof: the code now describes reality exactly start with the stable, low risk resources, and leave the data stores last never write definitions that would recreate an existing resource: that is how a production database is replaced by an apply ``` ## 10. Prohibitions - Never store state locally or in the repository. - Never apply without reading the plan. - Never share one state across environments. - Never commit a secret to a variable file. - Never apply a plan showing an unexplained replacement or deletion. - Never change production in the console outside an incident. - Never leave incident time console changes unreconciled. - Never let one module hold both a stateless service and its database when the destructive surfaces differ. ## 11. Protocol 1. Decide whether a provisioning tool is warranted, and record the decision. 2. Set up remote state with locking, versioning and encryption, per environment. 3. Lay out modules by lifecycle and blast radius. 4. Express environment differences as variables. 5. Keep secrets out of definitions and inject them at apply time. 6. Run plans in the pipeline, review them, and attach them to the change. 7. Apply from the pipeline, serialised, with approval for production. 8. Protect stateful resources and verify backups before touching them. 9. Detect drift on a schedule and reconcile it deliberately. 10. When adopting existing infrastructure, import until the plan is empty. ## 12. Auto-critique Score from 0 to 5: warrant decided rather than assumed, state remote, locked and separated, module boundaries by lifecycle, environment differences as variables, secrets absent from code and outputs, plans reviewed before apply, destructive changes identified and protected, drift detection scheduled, import verified by an empty plan. Threshold: no axis below 3, average at least 4. A shared state across environments, or an apply performed without reading the plan, fails regardless of how tidy the code is. ## 13. Interfaces - Upstream: `devops-core` for the environment ladder and blast radius, `architecture-design` for what the infrastructure must support, `technology-selection` for the platform. - Lateral: `environment-management` for configuration, `secrets-management` for credentials, `containerization` for what runs, `ci-cd-pipelines` for where plans and applies execute. - Downstream: `deployment-engineering`, `production-verification`, `backup-recovery`, `incident-response` when a change causes one, `decision-records` for the platform choice.