State
Open Terraform's memory, move it off your laptop into S3 with locking, reconcile drift and adopt existing resources, and rename things without destroying them.
Almost every serious Terraform incident is a state incident: two people applying at once, a state file lost with a laptop, a resource renamed in code and destroyed in production, a manual console change silently reverted. This stage makes state concrete. You'll read the file, move it to a shared, versioned, locked S3 backend, handle resources created outside Terraform, and refactor names safely.
+ ShopLite gains: a bootstrap config for a versioned, encrypted state bucket; remote state with S3-native locking; an imported CloudWatch log group; safely renamed resources
- 1.1
Open the State File
Know exactly what `terraform.tfstate` contains, how Terraform uses it on every run, and what goes wrong when it's lost, stale, or edited by two people at once.
25 minFree2 break-its - 1.2
Move State to S3 with Locking
A dedicated, versioned, encrypted state bucket built by its own bootstrap config, and ShopLite's state migrated into it with S3-native locking.
40 minCents per month — S3 storage and requests for a few KB of state3 break-its - 1.3
Drift, Refresh-Only Plans & Importing Existing Resources
Detect and accept (or revert) changes made outside Terraform, and bring a log group a teammate created by hand under Terraform management with an `import` block.
35 minFree — an empty log group costs nothing2 break-its - 1.4
Refactor Safely: moved, removed, and state mv
Rename the assets bucket resources to clearer names and hand a resource over to another team — with plans that show zero creates and zero destroys.
30 minFree2 break-its