IaC Mental Models

Infrastructure starts as a few clicks: create a resource group, add a DNS record, give an app a secret, open a firewall rule. That works until you need to repeat it, review it, or explain why production differs from staging.

Infrastructure as Code puts those decisions in files. The files become the durable description of the system. The tool reads the files, compares them with what exists, and proposes the next change.

• If a setting matters, write it down in code.
• If a change could break production, review the plan before applying it.
• If an environment cannot be rebuilt, you do not yet have a complete description.

Learn four terms first: configuration, provider, state, and real infrastructure. Configuration is the file you write. The provider is the plugin that talks to the cloud API. State is the tool's record of what it manages. Real infrastructure is what is actually running.

Keep these separate in your head. A file can say one thing while the cloud has another. State can be wrong. The cloud console can show what exists, but not whether it is supposed to exist.

• Configuration: what you want.
• Provider: how the tool calls the platform.
• State: what the tool remembers.
• Reality: what is actually deployed.

An IaC tool reads your files, asks the provider what exists, compares that with state, builds a dependency graph, and prints a plan. The plan is the important part. It tells you what the tool intends to create, update, replace, or delete.

Read plans slowly at first. A create means a new object. An update means an in-place change. A replacement usually means destroy and create. A delete means something will be removed.

• Plan before apply, even locally.
• Learn to identify replacement operations before you learn advanced modules.
• Keep plan output in CI so review happens before mutation.

IaC does not make infrastructure safe by itself. It makes changes visible. You still need naming rules, state ownership, secret handling, review, and a way to recover when something goes wrong.

Do not start by modeling an entire platform. Start with one harmless resource, one provider, one state file, and one plan you can explain.

• Bad IaC is just automated manual work.
• One giant state file turns small changes into large-risk events.
• Secrets in code are still secrets leaked in code.

Use a small loop: write a change, format it, validate it, plan it, read the plan, apply only if the plan matches your intent, then inspect the result.

Use consoles and CLIs to inspect and debug. Put lasting decisions back into the repo.

• Small roots beat heroic mega-roots.
• Review plans, not just code diffs.
• Document every manual exception as debt or an emergency action.