# Exercise 2: Troubleshoot Four ECS Deployments

For each case, name the cause, how you'd confirm it (which ECS event, log, or metric), and the fix.

1. **Tasks stop immediately** with `STOPPED (CannotPullContainerError: ... i/o timeout)`. The service runs in private subnets with no NAT gateway; it worked last week in a different VPC.
2. **Tasks start, then are replaced every ~2 minutes.** Service events: `(service api) (task 4f1…) failed ELB health checks in (target-group …)`. App logs show "listening on port 3000"; the target group health check uses port 8080, path `/health`.
3. **A deployment hangs for 40 minutes at 50%**, then the old tasks are still running and the new ones keep failing with `exit code 1`. The app crashes because `DATABASE_URL` is undefined.
4. **The app gets `AccessDeniedException` calling `s3:PutObject`** on `petpal-uploads`, although the execution role has `AmazonS3FullAccess`.

## Deliverables

For each: cause → confirmation → fix. Then write a short **deployment checklist** (6 items) for new ECS services.

## Requirements Checklist

- [ ] 1: no route to ECR from private subnets → add VPC interface endpoints (`ecr.api`, `ecr.dkr`, `logs`, `secretsmanager`) + S3 gateway endpoint, or NAT; confirm via stopped reason and route tables.
- [ ] 2: health check port/path mismatch (container listens on 3000, TG checks 8080 `/health`) → align port mapping, target group port and health path; confirm with target health descriptions.
- [ ] 3: missing secret/env in the new task definition revision; no circuit breaker → enable `deploymentCircuitBreaker` with rollback, fix the secret reference; confirm via stopped task logs/exit code.
- [ ] 4: permissions were added to the **execution** role, but the app uses the **task** role → grant `s3:PutObject` on that bucket to the task role (least privilege, not FullAccess).
- [ ] The checklist covers image tag immutability, role separation, secrets via valueFrom, health check alignment, circuit breaker, logs + alarms, and network path to ECR.