Infrastructure as Code with Terraform

Understand the declarative workflow

Terraform configuration names providers, resources, data sources, input variables, local expressions, modules, and outputs. Resource blocks describe intended arguments and relationships. Providers translate those declarations into service API operations. Terraform then stores bindings between resource addresses and remote objects so later runs can compare desired and observed state.

The normal loop is write, format, initialize, validate, plan, review, and apply. A plan may include creation, in-place update, replacement, or deletion. Unknown values can remain until apply when they depend on resources not yet created. Read the full action and attribute changes rather than treating a zero exit code as architectural approval.

Organize readable configuration

Group files by responsibility, not because Terraform requires one resource per file. Use descriptive resource names that express purpose. Inputs should represent legitimate deployment variation, while local values can remove repeated expressions. Outputs expose selected values to operators or other configurations, but sensitive marking reduces display and does not remove values from state.

Modules are useful for repeated, governed patterns such as a standard service network or application role. Keep their interface narrow and document assumptions, ownership, version, and upgrade path. Avoid a universal module with dozens of switches. Direct resource configuration is often clearer for one-off infrastructure with no stable reusable contract.

Review lifecycle and dependencies

Terraform infers dependencies when one resource references another. Use explicit dependencies only for real ordering that data references cannot express. Understand replacement behavior for names, immutable attributes, and lifecycle settings. A create-before-destroy approach needs spare quota and may be impossible when names are globally unique.

Deletion protection and lifecycle guards can prevent accidents, but they also need a documented exception path. Never add a blanket ignore rule to silence unexplained drift. Before a destructive plan, determine whether the resource holds data, which backups exist, what depends on it, and who has authority to approve the action.

Run Terraform as a team process

Keep configuration in version control, require review, and run checks in automation. Use temporary or narrowly scoped credentials and a remote backend suitable for shared state. Produce the plan from the reviewed commit and apply that same plan in the intended environment. Prevent simultaneous writers through backend locking where supported.

Separate environments with clear state boundaries rather than relying on variable changes against one ambiguous state. Restrict apply permissions more tightly than plan permissions. Record run identity, commit, plan, approvals, and result. After apply, verify the intended service behavior because successful API calls do not prove the architecture works for users.

Create a reviewed storage resource

A team wants a private application bucket with versioning and controlled access, managed for the first time in Terraform.

1. Write resource configuration with explicit ownership, encryption, public-access controls, versioning, tags, and narrow access policy.
2. Format and validate locally, then create a plan using read-only planning credentials in the correct non-production environment.
3. Review creation actions, policy principals, names, Region, retention assumptions, cost, and the absence of unexpected replacements or deletions.
4. Apply the saved plan through automation and verify allowed application access plus denied anonymous access without uploading sensitive test data.

Terraform change review card

Attach this information to each infrastructure change proposal.

• Configuration path, module version, environment, backend, provider versions, and change owner.
• Plan summary with creates, updates, replacements, deletions, unknowns, and sensitive resources.
• Security, network, data, availability, quota, cost, dependency, and naming review.
• Apply identity, approved commit, saved plan, state lock, maintenance window, and rollback or recovery path.
• Post-apply checks, user-facing verification, monitoring, documentation, and drift follow-up.

Common mistakes

• Approving a plan from its action counts without reading which resource is being replaced or deleted.
• Creating configuration for an existing resource and assuming Terraform will automatically adopt it.
• Applying locally with broad personal credentials while teammates can write the same state concurrently.

Try one

Sources

• Terraform documentationOfficial HashiCorp entry point for current Terraform concepts, configuration, state, CLI, and workflow documentation.
• AWS CloudFormation documentationOfficial AWS overview of declarative infrastructure templates and managed resource stacks.
• AWS CloudFormation change setsOfficial AWS guidance for previewing infrastructure changes before execution.