What an IAM Role Really Is

An IAM role is an identity you can assume to receive a set of permissions, but unlike a user it has no permanent credentials. Instead, when an entity assumes a role, AWS issues temporary security credentials that expire after a set time. Roles are the secure, modern way to grant access on AWS and appear throughout the SCS-C02 exam.

Every role has two policy parts:

• A trust policy (also called the assume-role policy) that says who is allowed to assume the role.
• One or more permission policies that say what the role can do once assumed.

This separation is the heart of how roles enable secure delegation: you decide who may borrow the identity and, separately, what that identity may do.

When a role is assumed, the Security Token Service (STS) issues a credential set containing an access key ID, secret key, and a session token, all valid for a limited window (15 minutes up to 12 hours). Because they expire automatically, leaked temporary credentials become useless quickly, which dramatically reduces risk compared to long-lived access keys.

The trust policy lists principals that may assume the role. These can be:

• An AWS service (like EC2 or Lambda) to give a workload an identity.
• An IAM user or role in the same or another account for cross-account access.
• A federated identity from a SAML or OIDC provider.

If a principal is not named in the trust policy, it can never assume the role, no matter what permission policies allow.

The most common use is letting an AWS service act on your behalf. For example, an EC2 instance with an attached role can call S3 without any embedded keys; AWS rotates the credentials automatically behind the scenes. The exam expects you to recognize that service roles eliminate static secrets from your applications.

Below is a trust policy snippet allowing the EC2 service to assume a role. The Principal identifies who may assume it, and the action is always sts:AssumeRole.

Roles shine for cross-account access. Account A creates a role trusting Account B; a principal in B assumes it and receives temporary credentials to act in A. No keys are shared, access is scoped by the permission policy, and either side can revoke the trust at any time. This is the recommended alternative to handing out long-term keys between accounts.

External identities, such as corporate users authenticated through SAML or app users through web identity federation, also assume roles. The identity provider verifies the user, then AWS issues temporary credentials tied to a role. This means humans never need IAM users at all, only a verified identity that maps to a role.

The biggest security benefit of roles is there are no standing credentials to steal, rotate, or accidentally commit to a code repository. Permissions exist only as a temporary session. This aligns with the principle of least privilege over time: access is granted just when needed and expires on its own.

A subtle point: being allowed to assume a role grants you only the role's permissions, not your own combined with the role's. When you assume a role you take on a new identity. Your original permissions are set aside for that session, so role design must include everything the task needs.

Reach for a role whenever a workload needs AWS access, when one account must act in another, or when humans authenticate through an external provider. Roles are the answer to almost every "how do I grant access without long-term keys" question on the exam. They combine a trust policy (who) with permission policies (what) to deliver secure, temporary, auditable access.

Confirm your understanding of roles.

An IAM role is a credential-less identity assumed to obtain temporary permissions from STS. It pairs a trust policy (who may assume it) with permission policies (what it can do). Roles power service access, cross-account delegation, and federation, eliminating long-term secrets. Assuming a role replaces your identity with the role's for the session.