When you first create an AWS account, a root user is automatically created. This account has the ability to do absolutely everything — delete the entire company's data, close the account, change billing information. Using it for everyday work is extremely dangerous.
IAM (Identity and Access Management) is the service that manages who can access what and how. It is the first line of defense in AWS security.
---
Think of It Like a Company Badge System
Imagine a large office building. If every single employee used the same all-access badge, an intern could accidentally walk into the server room, or a former employee could still access the vault after they left.
IAM is a system that gives each person exactly the level of access they need and nothing more. Interns get office access only, developers get their development servers, and administrators get the full system.
---
The 4 Core IAM Components
!The 4 core IAM components: Users, Groups, Roles, Policies
Users
Individual people or applications that access AWS. Each user has their own unique login credentials (password or access keys).
Important: The root user and a regular IAM user are different. The root user is the ultimate administrator account that can do everything. Never use it for daily tasks.
---
Groups
A way to bundle multiple users with the same role and manage their permissions all at once.
For example, create a "Dev Team" group and assign EC2 access to it. All 10 developers in that group automatically get the same permissions. When a new developer joins, you just add them to the group — no need to set up permissions from scratch.
---
Roles
A way to lend permissions temporarily. Roles can be assigned not just to people but to AWS services themselves.
For example, suppose an EC2 server needs to upload files to S3. The server itself is not a person, so you cannot give it a password. Instead, you assign it a role.
Think of roles like "visitor badges" at an office. You give a guest a one-day pass — it works when needed and expires automatically when the visit is over.
---
Policies
Rules that define what is allowed and what is not. They are written in JSON format.
You attach policies to users, groups, or roles to grant permissions. You can be very specific — for example, "allow reading from S3 buckets but deny deleting them."
---
3 Security Habits You Must Follow
Lock down the root user: Never use the root user for daily work. Right after creating your AWS account, enable MFA on the root user and lock it away.
Principle of Least Privilege: Give each user only the minimum permissions needed for their job. There is no reason to give a developer permission to delete the production database.
Enable MFA (Multi-Factor Authentication): A password alone is not enough. Adding a second factor like a smartphone OTP app makes your account dramatically more secure. Even if a password gets stolen, the account stays protected.
---
Related Services to Know
| Service | What It Does | |---------|-------------| | IAM Identity Center (SSO) | Single sign-on across multiple AWS accounts | | AWS STS | Issues temporary security credentials on demand | | Amazon Cognito | Manages user login for mobile apps and websites | | AWS Secrets Manager | Securely stores sensitive info like passwords and API keys |
---
Exam Key Points
"Never use root user for daily tasks" -- the most important security principle
"Grant only the minimum permissions needed" -- Principle of Least Privilege
"Manage same permissions for multiple users easily" -- use Groups
"AWS service accessing another AWS service" -- use Roles
"Issue temporary credentials" -- AWS STS or Roles
"Password plus additional verification" -- MFA
"Single login across multiple accounts" -- IAM Identity Center (SSO)
Policies are written in JSON format
Roles can be assigned to AWS services, users from other accounts, and external identity providers