Essential session storage is required to sign in. Optional analytics remain off unless you allow them.
Refactor infrastructure into a reusable MODULE (its own directory with variables.tf, main.tf, outputs.tf) and call it from a root config — ideally instantiated more than once (e.g. per environment) using for_each or multiple module blocks. Configure a REMOTE BACKEND with state LOCKING (e.g. S3 + DynamoDB, or Terraform Cloud) instead of local state. Add at least one variable validation rule. Pin the module and provider versions. Demonstrate that two people (or two applies) cannot corrupt state thanks to locking.
A clean child module (variables/outputs as its interface) reused from the root; for_each or multiple instances; versions pinned.
A remote backend configured with state locking; can explain why local state fails for teams; no secrets in state in the repo.
At least one variable validation rule; plan/apply clean; outputs surface useful values.
Clear directory layout; fmt/validate pass; DRY (no copy-pasted resource blocks).
Use this README structure to make the work reviewable.
DevPath fetches a read-only, size-capped snapshot. Submitted code is never executed.
# A reusable Terraform module with remote state ## Goal Refactor infrastructure into a reusable MODULE (its own directory with variables.tf, main.tf, outputs.tf) and call it from a root config — ideally instantiated more than once (e.g. per environment) using for_each or multiple module blocks. Configure a REMOTE BACKEND with state LOCKING (e.g. S3 + DynamoDB, or Terraform Cloud) instead of local state. Add at least one variable validation rule. Pin the module and provider versions. Demonstrate that two people (or two applies) cannot corrupt state thanks to locking. ## Acceptance criteria - [ ] Module design: A clean child module (variables/outputs as its interface) reused from the root; for_each or multiple instances; versions pinned. - [ ] Remote state & locking: A remote backend configured with state locking; can explain why local state fails for teams; no secrets in state in the repo. - [ ] Correctness: At least one variable validation rule; plan/apply clean; outputs surface useful values. - [ ] Structure: Clear directory layout; fmt/validate pass; DRY (no copy-pasted resource blocks). ## Verification - [ ] Document installation and run commands. - [ ] Record automated checks and their exact commands. - [ ] Add representative output, screenshots, or a short demo where useful. - [ ] Confirm failure paths and known constraints. ## Decision log ### Decision title - Context: - Choice: - Alternatives considered: - Tradeoffs: ## Evidence - Link each rubric criterion to the file, test, or artifact that demonstrates it. ## Known limitations - List what is intentionally out of scope and what should be improved next.