Amazon Web Services services
7 / 24
Amazon Web Services

Identity & Access — IAM

Grant least-privilege permissions to users, services, and workloads via policies and roles.

IAM decides who may do what. Every API call is authenticated, then authorised against the policies that apply.

A building access-card system. Each person or robot (principal) carries a card (role) encoding exactly which doors (actions) it may open and when (conditions). Temporary visitor passes (assumed roles) expire automatically, so nobody walks around with a permanent master key.

Key Concepts

1
Evaluation order is a standard question.
    1. an explicit DENY anywhere          -> denied, always
    2. otherwise an explicit ALLOW        -> allowed
    3. otherwise                          -> denied (implicit)
2
So the default is deny, and a deny cannot be overridden by any allow.
3
A policy is JSON.
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::reports-bucket/2026/*",
      "Condition": { "IpAddress": { "aws:SourceIp": "10.0.0.0/16" } }
    }
4
Note the resource is a prefix, not the whole bucket, and the condition narrows it further. That is what least privilege looks like in practice.
5
Roles are the most important concept. A role is a set of permissions that is assumed temporarily, and STS issues short-lived credentials for it.
6
    EC2 instance  -> instance profile -> rotating credentials
    Lambda        -> execution role
    ECS task      -> task role
    another account / OIDC / SSO -> assume role
7
Which is why access keys in code are the wrong answer. A role gives credentials that rotate automatically and expire, so there is nothing to leak and nothing to rotate manually.
8
The identity types.
    user     a person or legacy application, with long-lived creds
    group    a bundle of policies applied to users
    role     assumed by a service, a user, or another account
9
Prefer federation over users. SSO or OIDC means no IAM users for humans at all, and access follows the identity provider.
10
Permissions boundaries and SCPs set ceilings. A boundary limits what a principal can be granted; an SCP limits the whole account. Neither grants anything on its own.
11
Start from the policy simulator and Access Analyzer, which show what a policy actually permits — usually more than the author intended.
12
What the interviewer is probing.1. "How is an IAM request evaluated?" Probing: the order. Stalls: "It checks the policy." Moves up: explicit deny wins over everything; otherwise an explicit allow; otherwise the implicit deny — so the default is denied.
13
2. "Why are access keys in code the wrong answer?" Probing: roles. Stalls: "They work if you rotate them." Moves up: a role gives short-lived credentials issued by STS and rotated automatically, so there is nothing to leak or rotate by hand.
14
3. "How do you grant access to one S3 prefix only?" Probing: whether least privilege is concrete. Stalls: "Give S3 read access." Moves up: a resource ARN scoped to the prefix, arn:aws:s3:::bucket/reports/*, with conditions to narrow further.
15
4. "What is the difference between a role and a user?" Probing: the identity model. Stalls: "A role is for services." Moves up: a user has long-lived credentials; a role is assumed temporarily by anyone permitted — a service, a person, or another account.
Use cases:iamrolesleast-privilegepolicies