IAM

Cloud IAM defines who can do what on which resources. FullStack JS teams interact with IAM when CI deploys to AWS/GCP/Azure, when Lambdas or Cloud Run services call S3 or Pub/Sub, and when humans use SSO to reach consoles. Strong designs separate human identities from workload identities and grant least privilege with scoped roles.

| Principle | Practice | |-----------|----------| | Least privilege | Narrow policies per service and environment | | Short-lived creds | OIDC from GitHub Actions, not long-lived keys | | Separation | Dev roles cannot mutate production data | | Audit | CloudTrail / audit logs for policy changes |

Prefer role assumption and managed identities over embedding access keys in `.env` or Docker layers. Rotate secrets and review wildcard `*` permissions in policies attached to runtime services.

On interviews: human vs workload identity, OIDC federation for CI, permission boundaries, breaking glass admin access, and why overly broad S3 or DynamoDB policies are risky.

Common pitfalls: shared admin keys in CI; one mega-role for all microservices; storing IAM user keys in frontend repos; never testing deny scenarios or restore from locked-out state.

The trade-off is deployment friction (many small roles) versus blast radius when credentials leak or a service is compromised.

Checklist:

• Use workload roles per deploy target and service.
• Federate CI with OIDC instead of static keys.
• Review policies on a schedule; remove wildcards.
• Log and alert on privilege escalation events.