🛠️ Lab 6 — Provisioning Your Capstone Infrastructure with Terraform (50 pts)

Goal: Write Terraform (HCL) configuration that provisions cloud-style infrastructure for your capstone's containerized service — targeting LocalStack so the entire exercise runs in a free, local Docker container with zero cloud cost — and prove that a full terraform apply succeeds with no manual console changes.

Steps

1. Install the tools. Confirm Docker is running (from earlier weeks), then install the Terraform CLI following HashiCorp's official install tutorial. Also install tflocal, the free wrapper from LocalStack that points Terraform's AWS provider at a local endpoint instead of real AWS.
2. Start LocalStack. Run LocalStack as a Docker container (per LocalStack's Terraform integration docs). This gives you a local emulation of AWS services — S3, Lambda, EC2, etc. — with no billing and no real credentials needed.
3. Decide what your capstone needs. Pick ONE resource type that maps to your own capstone project's architecture:
• An S3 bucket if your project stores model artifacts, datasets, or logs.
• A Lambda function if part of your project is event-driven (e.g., a lightweight inference trigger).
• An EC2 t2.micro instance if your project needs a small always-on host (e.g., to run your containerized inference service from earlier weeks).
4. Write your Terraform configuration. Create a project folder with a main.tf declaring: the aws provider (pointed at LocalStack via tflocal), and your chosen resource with sensible names/tags tied to your capstone. Add at least one variable (e.g., bucket name or instance type) in a variables.tf so the config is reusable, not hardcoded.
5. Set credentials as environment variables. Export dummy/local credentials as env vars (LocalStack does not validate real AWS keys) so the AWS provider's credential chain resolves cleanly — do not hardcode any keys in your .tf files.
6. Run the workflow in order. Execute tflocal init, then tflocal plan and actually read the plan output — note what it says it will create — then tflocal apply to provision the resource(s).
7. Verify it exists. Use the AWS CLI (pointed at LocalStack) or LocalStack's dashboard to confirm your resource was actually created — e.g., aws --endpoint-url=http://localhost:4566 s3 ls.
8. Prove idempotency. Run tflocal apply a second time with no changes to your .tf files and capture the output showing "0 to add, 0 to change, 0 to destroy" — this is your evidence that Terraform is idempotent.
9. Make one change and re-plan. Edit a tag or a variable value, run tflocal plan again, and screenshot the diff it shows before you apply it — this demonstrates the plan-before-apply safety habit.
10. Clean up. Run tflocal destroy to tear down the resources and confirm your lab doesn't leave anything running.
11. (Optional stretch goal) If you want to also touch real AWS, follow HashiCorp's official "AWS Get Started" tutorial and re-run the same HCL (swapping tflocal for real terraform and real credentials) against a Free-Tier-eligible t2.micro instance. Set a billing alert first, and run terraform destroy the moment you're done. This step is optional and not required for full credit.
12. Write up. In a short README (or the text-entry box), explain what resource you provisioned, why it maps to your capstone, and paste your plan/apply/destroy output.

Deliverables:

• Your Terraform project folder (main.tf, variables.tf, and any other .tf files) committed to your capstone repo.
• Terminal output/screenshots showing: initial apply succeeding, the idempotent second apply showing zero changes, and a plan diff after a variable change.
• A short written explanation (150+ words) connecting the provisioned resource to your capstone architecture and confirming terraform destroy was run to avoid ongoing costs.