Terraform: write the resources as code, review the plan, and keep state safe

What Terraform is for, and what it is not

Terraform records the cloud resources you want as configuration and compares it with what exists. Its value is repeatability and review: the same group of resources can be made for staging and production, a change is a diff, and the history is in version control. It is not a way to hide a mess. A configuration that creates resources nobody understands, with state on a laptop and secrets in variables, is a harder problem than clicking in a console. Decide what the code is meant to describe before writing it.

• Describe resources you intend to keep and repeat.
• Put state in a protected remote backend.
• Review every plan before apply.

One module, one resource set, one reviewed plan

The fixed module job writes one defined set of up to eight resource types as a module with documented inputs and outputs, runs a plan in a test account with a credential that cannot create or destroy, and reviews it with you line by line. Acceptance is concrete: the validation and format checks pass, the plan shows only the creates in the inventory, no unexpected change or destroy appears, and after you have applied in the test account a second plan, run by us, shows no changes. You run the apply and the destroy in the test account yourself, each after your written approval, and any production apply with your own credentials. Existing production resources are out of that scope because adopting them is an import task.

• Plan matches the inventory.
• Second plan after apply shows no changes.
• List of values that state would hold.

A monthly check for drift

Drift is the gap between the code and what exists after someone changes a resource by hand. The standing review runs a plan once a month with a read-only credential that cannot change your resources, explains every difference as an intended change, an accident or out-of-date code, and proposes the fix in the direction you choose. It never applies. Plans that would replace or destroy a resource that holds data are raised in that month's report and before anything is applied, under the notification target agreed in writing. The credential is read-only, created and revoked by you, a plan takes a state lock by default so the route also needs lock access to your state, and plan output is handled as sensitive.

• Read-only credential created and revoked by you.
• Every difference classified, none ignored.
• Destroy and replace lines flagged first.

What neither job promises

Neither job promises that infrastructure is secure, cheap or available. They make the code readable and the plan trustworthy. They do not hold your credentials, apply to your production account, review the cloud account's security or reduce its cost; the bill review is a separate fixed job for the last of those. Prices are published test prices, and payment follows the agreed checks and your sign-off.