AWS Builder Center

Builder Center

5 AWS IAM Mistakes Every Beginner Makes (and How to Fix Them Today)

A practical, no-jargon guide to least privilege, safer credentials, and fewer 2 a.m. surprises.

Sakshi Sharma

student

Why IAM deserves your attention first

When people start with AWS, they usually jump straight to the exciting services: Lambda, S3, EC2, Bedrock. But every one of those services is protected (or exposed) by a single thing: IAM, AWS Identity and Access Management.
Most real-world cloud security incidents don't come from some exotic attack. They come from ordinary IAM mistakes: a key pushed to GitHub, a role that can do everything, an account with no MFA. The good news is that these mistakes are easy to avoid once you know them.
Here are the five I see most often, with the fix for each.

Mistake 1: Using the root account for everyday work

The root user is the email and password you signed up with. It has unrestricted access to everything in the account, and it can't be limited by normal IAM policies.
Why it hurts: if root credentials leak, an attacker owns your entire account, including billing.
The fix
  1. Turn on MFA for the root user right now.
  2. Create a separate admin identity for daily work. For most people the cleanest option is AWS IAM Identity Center; a regular IAM user with MFA also works for learning.
  3. Don't create access keys for root, and keep the root login for the few tasks that truly need it (closing the account, changing the support plan, and similar).

Mistake 2: Handing out AdministratorAccess (or "*" on "*") "just to make it work"

When something throws AccessDenied, it's tempting to attach a full-admin policy and move on. This is the single most common shortcut, and it means one bug or one leaked key can touch everything.
This is what an "allow everything" statement looks like. Treat it as a warning sign:
json
1
2
3
4
5
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
The fix: least privilege. Grant only the actions needed, on only the resources needed. For example, a Lambda function that reads and writes one DynamoDB table and reads files under one S3 prefix needs just this:
json
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:Query"],
"Resource": "arn:aws:dynamodb:ap-south-1:111122223333:table/orders"
},
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-app-uploads/reports/*"
}
]
}
Not sure which permissions you need? Start with a broader policy while you build, run your app, then use IAM Access Analyzer to generate a policy based on the activity recorded in CloudTrail. You then replace the broad policy with the tighter one. It takes minutes and gives you a policy built from real usage.

Mistake 3: Long-lived access keys in code, config files or GitHub

Access keys (AKIA...) don't expire on their own. If one ends up in a public repository, automated scanners can find it very quickly.
The fix
  • Inside AWS (Lambda, EC2, ECS), never use keys. Attach an IAM role and the service receives short-lived credentials automatically.
  • On your laptop, prefer IAM Identity Center with aws sso login over permanent keys.
  • Keep secrets (database passwords, third-party API keys) in AWS Secrets Manager or SSM Parameter Store, not in source code.
  • Add a .gitignore entry for credential files and consider a pre-commit scanner such as git-secrets.
  • If a key does leak: deactivate it immediately, create a replacement, and check CloudTrail for anything you didn't do. Don't just delete the commit and hope; assume the key is compromised.

Mistake 4: Not understanding how AWS decides "allowed or denied"

Beginners often add an Allow and are baffled when access is still denied. It helps to know the rules of evaluation:
  1. Everything is denied by default.
  2. An explicit Allow can grant access.
  3. An explicit Deny always wins, even over an Allow.
  4. Several layers can limit access at once: identity policies, resource policies (like an S3 bucket policy), permission boundaries, session policies, and Service Control Policies in AWS Organizations. All the relevant layers must permit the action.
The fix: when you hit AccessDenied, work through it in order:
  • Is the policy attached to the right user or role? (A very common slip is that a service is using a different role than you expected.)
  • Does the ARN match exactly, including region, account ID and resource name? One wrong character in an ARN makes a policy silently useless.
  • Is there a resource policy or SCP with a Deny?
  • Use the IAM Policy Simulator to test an action against a policy without trial and error.

Mistake 5: One giant shared role for everything

Creating a single role and attaching it to every Lambda function, EC2 instance and container is convenient. It also means that a compromise in your least important function gives an attacker the permissions of your most important one.
The fix
  • Give each workload its own role with only what it needs. A function that only reads from S3 shouldn't be able to delete from DynamoDB.
  • Use conditions to narrow access further, for example restricting by tag, by source IP, or by requiring MFA for sensitive actions.
  • Review roles regularly. IAM shows last-accessed information, so permissions that haven't been used in months are strong candidates for removal.

Your 10-minute IAM checklist

  • MFA enabled on the root user
  • No access keys on the root user
  • Daily work done through Identity Center or an IAM identity with MFA
  • No "Action": "*", "Resource": "*" policies on workloads
  • No access keys hardcoded in code or committed to Git
  • Each Lambda/EC2/service has its own role
  • Unused users, keys and roles removed
  • CloudTrail turned on so you can see who did what

Final thoughts

IAM can feel dry compared to building something flashy, but it's the foundation everything else stands on. Getting these five habits right early will make you a more trustworthy builder, and it's a skill that's genuinely valued in cloud and DevOps roles.
Which of these did you run into first? Share your own IAM horror story or tip in the comments, and if this helped, a like lets other builders find it. 🙌
# iam
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article