Learn
AWS
Security, identity & compliance
IAM

AWSGCP laterAzure later

IAMAWS Identity and Access Management

Security, identity & complianceCore service · full depthChecked against AWS docs · 15 Sept 2026

Who can do what to which AWS resource, and under what conditions. Every request to AWS is checked against it.

In the examsSolutions Architect – AssociateHIGHSolutions Architect – ProfessionalHIGHDeveloper – AssociateHIGHSysOps Administrator – AssociateHIGHSecurity – SpecialtyHIGHData Engineer – AssociateMEDMachine Learning Engineer – AssociateLOWAI PractitionerLOW

Where IAM takes you5 steps, all open

I know the problem it solves
I can picture it
I know when to choose it
I can use it in a design
I can answer an exam question

What & why

The question behind every AWS request

Every call to AWS is a request: someone wants to do something to something. It can come from the console, the CLI, an SDK, or another AWS service acting for you. IAM decides whether it is allowed.

Nothing is allowed until a policy allows it, and an explicit deny in any policy that applies overrides every allow. Most IAM questions in the exam are one of those two rules in disguise.

IAM itself is offered at no additional charge.

Reach for it when

an application on EC2 or Lambda needs to call AWS: give it a role
people in your organisation need access: federate them, ideally through IAM Identity Center
another account needs something in yours: a role it can assume
developers may create roles, but only up to a limit: a permissions boundary

It is the wrong tool when

your app's own customers need to sign up and sign in: that is Amazon Cognito
you need to store a database password or an API key: that is Secrets Manager
you need to encrypt data: that is KMS, whose key policies decide who may use a key

Mental model

Access badges in an office building

Nobody gets through a door by default. A badge opens only the doors written on it. Visitors pick up a badge at reception that stops working at the end of the day, which is far safer than handing out keys. A sign saying no entry beats any badge. The building's owners set rules no tenant can change, and a team lead can hand out badges only up to their own limit.

The badge holderwho is askingUser or role

What the badge opensa permissions policyIdentity-based policy

A visitor badgea role, assumed for a whilests:AssumeRole

It stops working tonighttemporary credentialsRole session

No entry, whoever you arean explicit denyEffect: Deny

The building's ruleslimits on whole accountsSCP

A team lead's limitthe most a role or user can be grantedPermissions boundary

How it works

What happens to one request

AuthenticateAWS works out who is asking: a user, a role session or a federated user. A few services, such as S3, also accept some anonymous requests.
Gather the contextThe action, the resource, the principal, and conditions such as whether the caller signed in with MFA.
Evaluate the policiesIdentity-based and resource-based policies, permissions boundaries, SCPs and RCPs, and session policies all have a say.
DecideAn explicit deny anywhere ends it. Otherwise something must allow it, and every guardrail that applies must allow it too. With no allow, it is denied.

Any explicit deny?
An explicit Deny in any policy that applies ends it here. Nothing overrides it.
Do the organisation's SCPs allow it?
If the account is in an organisation, the SCPs above it must allow the action. They grant nothing themselves.
Does the permissions boundary allow it?
If the user or role has a permissions boundary, the action must fall inside it.
Does a policy grant it?
Something has to allow it. Within one account, a resource-based policy such as a bucket policy can grant it too.

Pick a case to follow the request through each check.

Default decision: Denyuntil a policy allows
Explicit deny: Always winsover any allow
Role session: 1 hdefault · up to 12 h, set per role
Roles per EC2 instance: 1at a time, through an instance profile
IAM Access Analyzer: 100+ checksto validate a policy

Identity-based policy

attached to a user, a group or a role
says what that identity may do, on which resources, under which conditions
managed, and reusable, or inline, for one identity only

Resource-based policy

attached to a resource, such as an S3 bucket or a role's trust policy
names the principals it lets in, which can be in other accounts
across accounts, the caller's own account must allow it too; in the same account the resource policy alone can grant access

Architecture

A photo app with no keys on any server

Every call into AWS is signed with a role's temporary credentials. Nothing on either compute resource stores a key.

The instances get a role through an instance profile, and the app picks up temporary credentials from the instance metadata. They are updated automatically before they expire, so there is nothing to rotate. The Lambda function has a role of its own. Each role allows only what its code does: one bucket, one table.

Security

Guarding the thing that guards everything

People: federate, and use MFA. AWS recommends that people sign in through an identity provider, ideally IAM Identity Center, and work with temporary credentials. Where an IAM user or the root user cannot be avoided, require MFA, preferably phishing-resistant passkeys or security keys.

The root user has complete access to everything in the account. Use it only for the few tasks that need it, such as closing a standalone account or changing its root email address or password, and never for everyday work.

Least privilege, checked by tools. IAM Access Analyzer runs over 100 checks on a policy, can generate a policy from what a role actually did according to CloudTrail, and flags resources shared publicly or with other accounts. Last accessed information shows permissions nobody uses.

iam:PassRole is a permission too. Launching an instance with a role needs permission to pass that role. Limit which roles each person may pass, or they could run code with more access than they have themselves.

Cost

What it charges, and what getting it wrong costs

IAM is offered at no additional charge: users, groups, roles and policies cost nothing to create or use.

The real cost is getting it wrong. A leaked access key can do anything its policy allows until someone notices, which is the practical case for roles and temporary credentials.

Prices change, so none are printed here. Check the IAM FAQs on aws.amazon.com.

Comparison

The identities a question will offer you

Identity	Credentials	Meant for	Choose it when
IAM role	Temporary, from AWS STS	Workloads, other accounts, federated people	An application runs on AWS, or access crosses accounts
IAM user	Long-term: a password and access keys	Cases that cannot use a role	A third-party tool only accepts access keys
IAM Identity Center	Temporary, through federation	Your workforce, across accounts	Staff need access to many accounts in an organisation
Cognito user pool	Tokens (JWTs) for your app	Your app's own users	Customers sign up and sign in to a web or mobile app
Cognito identity pool	Temporary AWS credentials	App users who must reach AWS directly	A mobile app uploads straight to S3

SAA traps

The phrase in the question, and what it means

an application on EC2 needs to read from S3An IAM role, through an instance profile

Temporary credentials that update themselves. Never access keys stored on the instance.

grant users in another AWS account accessA role they assume, whose trust policy names their account

Their own account must also allow them to call sts:AssumeRole on it.

developers may create roles, but never beyond a set limitA permissions boundary

It sets the most an identity-based policy can grant, and grants nothing itself.

no account in the organisation may use a particular serviceA service control policy

SCPs cap every user and role in member accounts, the root user included. They do not affect the management account.

one policy allows the action and another denies itDenied

An explicit deny in any policy overrides any allow.

the SCP allows S3, but the user still cannot read the bucketSCPs grant nothing

The user still needs an identity-based or resource-based policy that allows the read.

find the permissions a role has never usedIAM Access Analyzer, or last accessed information

Both show what is used, so you can remove the rest.

secure the account's root userMFA, no everyday use, no access keys

Use it only for the tasks that need it, and do those as rarely as possible.

Scenario

Exam style, marked when you answer

A company runs an application on EC2 instances that writes objects to one S3 bucket. A security review finds an access key and secret key in the application's configuration file on every instance. The team wants no long-term credentials on the instances and the least operational effort. What should a solutions architect do?

Practice

Fill the gap, the way the challenges work

A photo app on EC2 instances must write to one S3 bucket. The security team will not allow long-term access keys anywhere on the instances. What goes in the gap?

EC2· Photo appPick a service belowS3· Photos

Quick revision

The night before the exam

Default: Everything is denied until a policy allows it.
Explicit deny: Wins over any allow, in any policy.
Roles, not keys: Workloads and people get temporary credentials; access keys are the exception.
Permissions boundary: The most an identity-based policy can grant a user or role. Grants nothing.
SCP: The most any user or role in a member account can do, root included. Grants nothing; not the management account.
Root user: MFA on, used rarely, only for the tasks that need it.
Role session: 1 h by default, up to 12 h, set per role.

Next: EC2Virtual machines you choose, size and run yourself: the most flexible compute on AWS, and the most work.

Open EC2

Checked against

Every fact on this page was checked against AWS’s own documentation on 15 Sept 2026. If AWS has changed something since, its page is the one to trust.