AssumeRole and the Session Lifetime

The AssumeRole operation lets a principal temporarily exchange its own identity for a role's permissions. The result is a time-bounded session. Controlling how long that session lasts, and how its permissions are scoped, is a frequent SCS-C02 topic because session lifetime directly affects security exposure.

After AssumeRole succeeds, the caller operates as an assumed-role session, identified by an ARN like arn:aws:sts::ACCOUNT:assumed-role/RoleName/SessionName. For the duration, the caller has the role's permissions and not their original ones. The session name you pass is preserved for auditing.

The DurationSeconds parameter sets how long the session lasts, from 900 seconds (15 minutes) up to a maximum defined by the role. Shorter sessions reduce the window during which leaked credentials are valid, so least-privilege thinking favors the shortest practical duration.

Each role has a MaximumSessionDuration setting (1 to 12 hours). A request for DurationSeconds longer than this is rejected. Setting a sensible maximum on sensitive roles caps how long any single assumption can last, a control you can tune for high-risk roles.

When one assumed role assumes another role, that is role chaining. AWS limits chained sessions to a maximum of one hour, regardless of the role's configured maximum. Recognizing this cap explains why some long-duration requests fail when roles are chained, a subtle exam detail.

Because sessions expire, applications must re-assume the role to keep working. SDKs handle this transparently for instance profiles and configured role profiles, fetching new credentials before the old ones expire. There is no way to extend an existing session; you simply obtain a fresh one.

Beyond duration, AssumeRole accepts Policy or PolicyArns (session policies to narrow permissions), Tags (session tags for ABAC), and SerialNumber plus TokenCode for MFA. These let you scope and protect each assumption precisely at the moment it happens.

A role's trust policy can require MFA, in which case AssumeRole must include the MFA device ARN and a current token code. This ensures a privileged role cannot be assumed by a stolen credential alone. Pairing short sessions with MFA is a strong, exam-endorsed control for sensitive roles.

You cannot delete an individual temporary credential, but you can revoke all active sessions for a role by attaching an inline policy that denies actions for tokens issued before a chosen time, using the aws:TokenIssueTime condition. The console "Revoke active sessions" button does exactly this, a key incident-response tool.

Short session lifetimes mean that even if temporary credentials leak, they soon become useless. Combined with revocation, MFA, and least-privilege session policies, they shrink the attack window dramatically. The exam favors answers that minimize how long any credential remains valid.

AssumeRole creates a time-bounded session governed by DurationSeconds within the role's MaximumSessionDuration, with chained roles capped at one hour. Scope each session with policies, tags, and MFA, and use the TokenIssueTime revocation trick to kill compromised sessions instantly. Short, scoped sessions are the secure default.

Test session-lifetime knowledge.

AssumeRole creates an assumed-role session lasting from 15 minutes up to the role's MaximumSessionDuration (max 12 hours), with role chaining capped at one hour. Scope sessions with session policies, tags, and MFA. Revoke compromised sessions using the aws:TokenIssueTime deny trick. Prefer short, scoped sessions.