AWS IAM Security: — Least Privilege, Roles and the 10 Rules That Save Your Account

① IAM building blocks — users, groups, roles, policies

Meet Sneha, a fresh L1 cloud engineer at Flipkart. On day two she opens the IAM console and sees four words she has to get straight: users, groups, roles, policies. Get these four right and the rest of AWS security clicks; get them muddled and you will hand out a master key by accident. So let us build them up one at a time, like the pass-register at a society gate.

A user is a long-lived identity — one human (Sneha) or one application. It can have a console password and a pair of long-lived access keys (an ID starting AKIA plus a secret). A group is just a labelled bucket of users — attach a policy to the group (say, Developers) and every member inherits it, so you manage permissions once instead of per person.

A role is the one that trips people up. A role has permissions but no permanent password or key. Instead a trusted principal — an EC2 instance, a Lambda function, a user in another account, or a human signing in through SSO — assumes the role and receives temporary credentials from STS that expire (often in an hour). Think hotel: a user with an access key is owning the building and carrying a key that never changes; a role is the front desk handing you a keycard that stops working at checkout.

A policy is the JSON document that says what is allowed. There are two flavours you must never confuse. An identity-based policy is attached to a user/group/role and says what that identity may do. A resource-based policy is attached to the resource (an S3 bucket, a KMS key) and says who may touch this thing. The dead giveaway: a resource-based policy has a "Principal" field; an identity-based one does not.

Now the flow. Every API call is a request with three parts: the principal (who is asking), the action (e.g. s3:GetObject), and the resource (which bucket). AWS gathers every policy attached to that identity and that resource and checks them. The default answer is no — if nothing explicitly allows the action, it is implicitly denied. You spend your IAM life carving narrow Allow holes out of that default deny.

Why do roles beat long-lived access keys? Because a leaked AKIA key is valid until a human notices and revokes it — that could be months, and meanwhile it is in someone's clipboard, a Git commit, a Slack message. A role's STS credentials (ASIA…) expire on their own, usually within an hour, so a leak self-heals. That is why AWS now tells you to use roles and federation for humans and instance/task roles for apps, and to treat access keys as a last resort.

And the root user? It is the account owner — unlimited power, and it cannot be reined in by any IAM policy or SCP. So you use it for almost nothing: only the handful of tasks that genuinely require it (changing account settings, restoring a locked-out admin, certain billing/tax actions, S3 MFA-delete). Lock it with hardware MFA, delete its access keys, and do daily work as a far less powerful role.

The four building blocks, one tap each

Tap each card. These four are the vocabulary every AWS interview and the SCS-C02 exam assumes you own cold.

② How policies are evaluated — explicit Deny wins

Here is the single most important rule in all of IAM, and it is on the exam in three different costumes: an explicit Deny overrides any Allow. When a request arrives, AWS gathers every policy type that could apply — the SCP, the identity-based policy, any resource-based policy, the permission boundary, and any session policy — and looks for a Deny first.

The order, straight from the IAM evaluation logic: (1) is the request explicitly Denied by any policy? If yes, stop — denied. (2) If not, is it explicitly Allowed, and do all the guardrails permit it? (3) If nothing allows it, the implicit (default) Deny applies. Allow is the exception; Deny — explicit or default — is the resting state.

How the layers combine matters. Identity-based and resource-based policies in the same account are a union — an Allow in either is enough. But a permission boundary, an SCP and the identity policy are an intersection — the action must be allowed by all three. AWS states it plainly: with a boundary and an SCP present, "the boundary, the SCP, and the identity-based policy must all allow the action." That is why a developer can have AdministratorAccess attached and still be unable to touch a region an SCP blocks.

Now read a policy. Every statement has four things: Effect (Allow or Deny), Action (the API calls), Resource (the ARNs it applies to), and an optional Condition (extra tests like MFA or source IP). The danger you must learn to spot in code review is "Action":"*" with "Resource":"*" — that is admin on everything, a single master key. The exam loves to hide a wildcard in a plausible-looking policy.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ReadReportsPrefixOnly",
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": [
      "arn:aws:s3:::flipkart-reports",
      "arn:aws:s3:::flipkart-reports/finance/*"
    ],
    "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
  }]
}

$ aws s3 ls s3://flipkart-reports/finance/ --profile sneha
2026-06-10 09:14:22   18211  q4-summary.csv
$ aws s3 rm s3://flipkart-reports/finance/q4-summary.csv --profile sneha
delete failed: ... An error occurred (AccessDenied) when calling the
DeleteObject operation: User is not authorized to perform: s3:DeleteObject

③ Least privilege in practice — start minimal and grow

"Least privilege" sounds like a poster on the wall until you have to ship it. The workable method is: start from nothing and grow. Give the identity the smallest policy you think it needs, let the workload run, then use real usage data to add only what was actually used and remove what was not. AWS gives you two tools for exactly this: last-accessed information and IAM Access Analyzer.

Access Analyzer does three jobs you'll lean on. It finds external/cross-account exposure — a bucket or role shared outside your account or organization (provable security, not guesswork). It surfaces unused access — roles with no activity, unused access keys and passwords, and service- or action-level permissions a role was granted but never used. And it can generate a policy from your CloudTrail history, so you get a least-privilege starting point instead of a blank page. In 2025 AWS extended these unused-access and custom-policy-check findings to more regions (including GovCloud), a sign of how central this has become.

Two structures stop least privilege from quietly eroding as your account grows. A permission boundary caps what an identity can ever do — vital when you let a team lead create roles, because the boundary guarantees they can't mint a role more powerful than themselves (the effective permission is the intersection of the role's policy and the boundary). An SCP does the same one level up, at the AWS Organizations level, as a guardrail across whole accounts — e.g. "no one, not even an account admin, may disable CloudTrail or leave ap-south-1."

Conditions are how you make a broad-looking Allow safe. Three you'll use constantly: require MFA with aws:MultiFactorAuthPresent; restrict to office/VPN ranges with aws:SourceIp; and gate on tags so a policy only touches resources tagged for that team (attribute-based access control). Conditions turn "can read any prod bucket" into "can read prod buckets tagged team=payments, from the office IP, with MFA on."

Now the model that powers almost everything cross-account: the role + trust policy. A role has two policies. Its permission policy says what the role can do once assumed. Its trust policy says who is allowed to assume it — that's the resource-based policy with the Principal field. To let an auditor in the security account read your prod account, you create a role in prod whose trust policy names the security account's principal, and grant that principal sts:AssumeRole on their side. Both sides must agree.

aws accessanalyzer start-policy-generation \
  --policy-generation-details '{"principalArn":"arn:aws:iam::123456789012:role/etl-job"}' \
  --cloud-trail-details file://trail-window.json

# then, once it finishes:
aws accessanalyzer get-generated-policy \
  --job-id 4d2f9b1a-7c33-4f2e-9a01-6b5e8c0a1122

{
  "jobDetails": { "status": "SUCCEEDED" },
  "generatedPolicyResult": {
    "generatedPolicies": [{ "policy": "{\"Version\":\"2012-10-17\",
      \"Statement\":[{\"Effect\":\"Allow\",
      \"Action\":[\"s3:GetObject\",\"dynamodb:PutItem\"],
      \"Resource\":[\"arn:aws:s3:::etl-src/*\", ...]}]}" }]
  }
}

④ The hardening checklist — 10 rules + the PassRole trap

Time to turn everything into a checklist you can run on a real account on Monday. None of this is exotic — it's the boring discipline that keeps your account out of a breach write-up. We'll walk the high-value rules, hit the one privilege-escalation trap that catches even seniors, recreate the Create role screen, then leave you a cheat-sheet.

Identities & credentials. Lock the root user with hardware MFA and delete its access keys — use it only for the genuine root-only tasks (account settings, restoring a locked-out admin, certain billing/tax actions, S3 MFA-delete). Turn on MFA for every human. Rotate or eliminate access keys — better still, replace them with roles/SSO so there's nothing long-lived to rotate. And no inline admin: don't paste AdministratorAccess or "*" inline onto users; grant through groups/roles with scoped policies.

Visibility & guardrails. Keep IAM Access Analyzer on to catch public or cross-account exposure and unused access. Keep CloudTrail on — an organization trail records every AssumeRole and API call, which is both your forensic record and the feed for alarms (e.g. alert on root sign-in). Add SCPs for org-wide non-negotiables and permission boundaries wherever you delegate role creation.

Now the trap. iam:PassRole is how you attach a role to a service (give an EC2 instance or a Lambda its role). The escalation: a low-privileged user who has iam:PassRole plus a launch permission like ec2:RunInstances or lambda:CreateFunction can pass an admin role to a new instance/function and then read its credentials — becoming admin without ever editing their own policy. Security researchers list this among the most common AWS privilege-escalation paths.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "PassOnlyAppRoleToEc2",
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": "arn:aws:iam::123456789012:role/app-runtime-role",
    "Condition": {
      "StringEquals": { "iam:PassedToService": "ec2.amazonaws.com" }
    }
  }]
}

# user tries to pass a DIFFERENT, more powerful role:
$ aws ec2 run-instances --iam-instance-profile Name=admin-profile ...
An error occurred (AccessDenied) when calling the RunInstances operation:
User: arn:aws:iam::123456789012:user/dev is not authorized to perform:
iam:PassRole on resource: arn:aws:iam::123456789012:role/AdminRole

For the cert: this lesson maps onto Domain 4 — Identity and Access Management (16% of the SCS-C02 exam), and IAM concepts bleed into the Infrastructure Security and Data Protection domains too. The exam tests exactly what you just learned — policy evaluation order, roles vs long-lived credentials, permission boundaries vs SCPs, and reading a policy JSON to spot the over-permissive line. Get these solid and a big slice of the exam (and your first cloud-security job) is in reach.