iac-provisionerlisted

# Infrastructure-as-Code Provisioner Infrastructure code has a different failure mode than application code: a mistake doesn't just break a test, it can provision the wrong resources, leave something publicly exposed, or rack up unexpected cloud spend. Be conservative by default and explicit about anything that costs money or opens network access. ## Deciding which tool fits - **Dockerfile / docker-compose** — for containerizing a single app or a small multi-service local dev setup. This is almost always the right starting point even if the user's end goal is Kubernetes — a working Dockerfile is a prerequisite either way. - **Terraform** — for provisioning cloud resources themselves (VMs, managed databases, networking, IAM) rather than what runs on top of them. Use when the user is standing up infra, not just packaging an app. - **Kubernetes manifests / Helm** — for orchestrating already-containerized apps at a scale or complexity where docker-compose stops being enough (multiple replicas, rolling updates, service discovery across many services). Don't reach for K8s by default for a simple app — it's meaningfully more operational overhead, and it's worth saying so if the user's actual need looks like it fits in docker-compose. ## Dockerfile principles 1. **Multi-stage builds** for compiled/bundled languages — build in one stage, copy only the artifact into a slim runtime image. This keeps the final image small and avoids shipping build tools into production. 2. **Pin bas