"Why isn't my EC2 working?!"
"AccessDenied for s3:GetObject?! I gave full permissions!"

If AWS feels like it's gatekeeping your services, you're not alone. IAM (Identity and Access Management) is one of the most powerful — and confusing — parts of AWS for beginners.

But here’s the good news: You don’t need to be a security engineer to master IAM policies. You just need the right mental model, some good examples, and a few pro tips.

Let’s dive into how IAM policies really work — and how to write and apply them like a cloud-native pro. 🧠💪

🧠 What Are IAM Policies (In Plain English)?

IAM policies are like permission slips for your AWS resources.

Real-world analogy: Imagine you’re organizing a hackathon in a coworking space. You give Dev A access to the main door, Dev B access to the kitchen, and Dev C access to the stage.

IAM policies do the same — they grant (or deny) access to services like S3, EC2, Lambda, etc.

They come in two types:

• Identity-based policies → attached to users, groups, or roles
• Resource-based policies → attached directly to resources (e.g., S3 bucket policies)

🔧 Basic Structure of an IAM Policy

Here’s a typical identity-based policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::mybucket/*"
    }
  ]
}

Let’s Break That Down:

• Version: Always use 2012-10-17
• Effect: Allow or Deny
• Action: What the user can do (e.g., s3:PutObject)
• Resource: The target (like an S3 bucket or specific file)

Pro Tip: AWS evaluates explicit denies first, then allows. So if there's a Deny, it wins every time.

🛠 Common IAM Policy Examples (With Use Cases)

✅ Read-Only Access to S3 Bucket

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:ListBucket"
  ],
  "Resource": [
    "arn:aws:s3:::mybucket",
    "arn:aws:s3:::mybucket/*"
  ]
}

✅ Start and Stop EC2 Instances Only

{
  "Effect": "Allow",
  "Action": [
    "ec2:StartInstances",
    "ec2:StopInstances"
  ],
  "Resource": "*"
}

✅ Full Access to DynamoDB (Dev Only)

{
  "Effect": "Allow",
  "Action": "dynamodb:*",
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyDevTable"
}

Always scope down * when you go to production.

🧠 Pro Tips for Writing and Debugging Policies

✅ Start with AWS Managed Policies
They’re prebuilt and safer for beginners. Example: AmazonS3ReadOnlyAccess

✅ Use the IAM Policy Simulator
Check what your policy actually allows: https://policysim.aws.amazon.com

✅ Avoid Wildcards in Production
Replace * in Action and Resource with specific permissions and ARNs.

✅ Use Conditions to Tighten Access

"Condition": {
  "IpAddress": {"aws:SourceIp": "203.0.113.0/24"}
}

This ensures the action only works from a specific IP range.

✅ Never Attach Policies to Individual Users in Prod
Use Groups or Roles for cleaner and more scalable permissions.

⚠️ IAM Mistakes to Avoid

• ❌ Using AdministratorAccess for everyone
• ❌ Leaving default * resources in policies
• ❌ Ignoring Deny statements
• ❌ Not using MFA with IAM users
• ❌ Pushing access keys to GitHub (use roles and profiles instead!)

📦 Bonus: Create a Custom IAM Policy in AWS Console

1. Go to IAM > Policies > Create Policy
2. Choose JSON tab and paste your policy
3. Review → Name it → Create
4. Attach it to a Group, Role, or User

And that’s it — your permissions are live! 🔥

🧠 TL;DR – IAM Policy Cheatsheet

💬 Let’s Make IAM Simple — Together

AWS IAM doesn’t have to be scary. Once you learn the pattern, you’ll see the power — and the beauty — in how AWS protects your apps.

👇 Have you written a tricky policy lately? Want me to debug it with you?

Drop your JSON in the comments. Hit ❤️ if this helped, and share with someone new to AWS. Let’s empower more devs to build — safely. 🧡