IAM

IAM controls who can do what on which AWS resources. Identity types include users (humans), roles (assumed by services or federated identities), and groups. Policies are JSON documents evaluated as allow/deny with explicit deny winning.

For Node.js on AWS, prefer roles over access keys: EC2 instance profiles, ECS task roles, Lambda execution roles, and IRSA on EKS grant temporary credentials via STS. Scope policies with resource ARNs, conditions (source IP, MFA), and permission boundaries for third parties.

| Primitive | Typical use | |-----------|-------------| | Role | Runtime credentials for apps and automation | | Policy | Attached to identity or resource | | Service control policy | Organization guardrails |

On interviews: least privilege, role chaining, cross-account access, resource-based policies (S3 bucket policy versus IAM policy), and why long-lived `AKIA` keys in `.env` are a red flag.

Common pitfalls: `*` actions on `*` resources; sharing one powerful role across all microservices; embedding keys in frontend bundles; no break-glass audit for admin roles.

The trade-off is fine-grained security versus policy sprawl and slower developer onboarding without good defaults and IaC.

Checklist:

• No static keys in application code or CI logs.
• One role per service with minimal actions.
• Use IAM Access Analyzer and periodic policy reviews.
• Enforce MFA and SSO for human access.