# Exercise 1: From ClickOps to IaC — Inventory and Plan a Migration

## Scenario

`PetPal` runs entirely on AWS resources that were created by hand over three years:

- 1 VPC with 4 subnets (2 "public", 2 "private" — nobody is sure which route tables are attached)
- 6 EC2 instances (2 web, 2 API, 1 "temporary" worker from 2023, 1 bastion with port 22 open to the world)
- 1 RDS PostgreSQL instance (single-AZ, automated backups 1 day)
- 3 S3 buckets (one is public; nobody knows why)
- An ALB, a Route 53 hosted zone with 40 records, an ACM certificate
- IAM: 14 users with access keys (some unused for a year), 3 roles, policies attached directly to users
- A staging environment that "is similar" to production, created by copying settings manually

The CTO wants everything in Terraform within one quarter without downtime.

## Deliverables

1. **Inventory method**: how you discover everything that exists (consoles aren't enough) — which AWS tools/APIs and which Terraform features help (`terraform import`, `import` blocks with `-generate-config-out`, AWS Config / Resource Explorer, tag audits).
2. **Split into units** (root modules / state files): propose 4–6 units (e.g. `network`, `data`, `dns`, `iam`, `app-prod`, `app-staging`) with what goes in each, and justify by **blast radius** and **change frequency**.
3. **Migration order**: which unit first and why; how you avoid downtime while importing (import ≠ recreate); how you verify "no changes" after import.
4. **Findings to fix during migration** — list the risky things in the inventory and what the IaC version will do instead (at least 6).
5. **Drift policy**: what happens after the migration when someone changes something in the console?
6. **Environment strategy**: how staging stops being "similar" and becomes "the same code with different variables".

## Requirements Checklist

- [ ] Discovery uses APIs/tools (AWS Config, Resource Explorer, CLI listings, Cost Explorer by service) rather than memory, and Terraform `import` blocks / `terraform plan -generate-config-out` to bootstrap code.
- [ ] Units separate slow-changing, high-risk resources (network, data, IAM, DNS) from frequently changing app resources.
- [ ] The first unit is low risk (e.g. DNS or IAM read-only analysis) or foundational (network), with explicit reasoning; success = `terraform plan` shows **no changes** after import.
- [ ] Findings include: public S3 bucket, port 22 open to the world, IAM users with long-lived keys, single-AZ RDS with 1-day backups, unknown "temporary" instance, policies attached to users, unclear public/private subnets.
- [ ] Drift policy: console access becomes read-only in prod; scheduled `terraform plan` detects drift; changes go through PRs.
- [ ] Staging and prod use the same modules with per-environment variables (`06-workspaces_and_environments/`).