Assuming a role swaps your identity for the role's, for a while.

Assuming once

aws sts assume-role --role-arn arn:aws:iam::123456789012:role/auditor --role-session-name audit

{
    "Credentials": {
        "AccessKeyId": "ASIAW3UJQA4DDPMAQHZT",
        "SecretAccessKey": "1dr9xI1N7z71a0VxKE6aHQhJRM2jL9uNGKQiTkK7",
        "SessionToken": "IQoJb3JpZ2luX2Vjkyz26cIR97U2yV8E6sz7…",
        "Expiration": "2026-10-20T03:10:05+00:00"
    },
    "AssumedRoleUser": {
        "Arn": "arn:aws:sts::123456789012:assumed-role/auditor/audit"
    }
}

Three credentials come back: a key id that starts with ASIA (temporary), a secret, and a session token, which long-term keys do not have. They stop working at Expiration. --role-session-name labels the session, so the audit trail shows who did what.

A role profile

Copying three values by hand gets old. A role profile tells the CLI to assume the role itself, for every command that names the profile:

aws configure set role_arn arn:aws:iam::123456789012:role/auditor --profile auditor

aws configure set source_profile default --profile auditor

role_arn is the role to assume; source_profile is the profile whose key asks for it, here admin's. Now:

aws sts get-caller-identity --profile auditor

The ARN starts arn:aws:sts::123456789012:assumed-role/auditor/. Every command with --profile auditor has exactly the role's permissions: reading works, and aws s3 mb is denied.