Security is Job Zero

IAM controls WHO can do WHAT in your AWS account. Most hacks happen because of bad IAM policies.

1. Users, Groups, and Roles

Users: Humans (Developer, Admin).
Groups: Collection of users (e.g., 'DevTeam').
Roles: Intended for MACHINE identities. **Crucial:** Never put AWS Access Keys in your appsettings.json. Instead, assign an **IAM Role** to your EC2 or Lambda, and the .NET AWS SDK will automatically 'assume' that role to get temporary credentials.

2. Least Privilege

Don't give your API 'AdministratorAccess'. Give it ONLY exactly what it needs (e.g., s3:PutObject only for a specific bucket, dynamodb:GetItem only for a specific table).

3. Architect Insight

Q: "What is an IAM Policy?"

Architect Answer: "A JSON document that defines permissions. It consists of an **Effect** (Allow/Deny), an **Action** (e.g., s3:ListBucket), and a **Resource** (the ARN of the bucket). If there is even a single 'Deny' anywhere, it overrides all 'Allows'. Master the 'Explicit Deny' for sensitive data."