writing-infrastructure-code

Configure an S3 backend with a DynamoDB table for state locking. Create the bucket with versioning and KMS encryption first, then reference it in a backend.tf block with the bucket, key, region, encrypt, and dynamodb_table parameters.

Choose Terraform for multi-cloud deployments with operations-focused teams who prefer declarative HCL and a large provider ecosystem. Choose Pulumi when developers need programming constructs like loops and conditionals in TypeScript, Python, or Go with native unit testing.

Run terraform plan with the -detailed-exitcode flag, which returns exit code 2 when drift is detected. Schedule this check via cron or CI, and remediate by running terraform apply or updating code to match reality with -refresh-only.

Use directory separation for most teams since it provides complete state isolation with no risk of cross-environment operations. Workspaces share one backend and codebase, which risks accidental operations on the wrong environment.

Create a module when a resource group is reused three or more times, has clear input and output boundaries, and the team can maintain it. Keep code monolithic for one-off infrastructure, rapid prototyping, or tightly coupled resources.

Mark sensitive outputs with sensitive = true, enable KMS encryption on the state backend, and reference secrets from a secrets manager instead of hardcoding values. Never commit state files to Git since they can contain plaintext sensitive data.