How does cross-account access work with IAM roles and AWS STS?
The target account creates a role with a trust policy naming the other account, and permissions for what the role can do. A user or service in the other account calls STS AssumeRole and receives temporary credentials for that role.
Explain it simply
It is like a guest pass at another company. Company B prepares a visitor role with limited access and tells security "employees of Company A may take this pass". An employee from A shows ID, collects a time-limited badge, and works within what the badge allows.
Example
Account B (111111111111) owns the data
Role: ReadReports
Trust policy: Principal = arn:aws:iam::222222222222:root (Account A)
Permissions: s3:GetObject on arn:aws:s3:::b-reports/*
Account A (222222222222) user or role
Needs permission: sts:AssumeRole on arn:aws:iam::111111111111:role/ReadReportsaws sts assume-role --role-arn arn:aws:iam::111111111111:role/ReadReports --role-session-name audit-job
# returns AccessKeyId, SecretAccessKey, SessionToken, ExpirationBoth sides must agree: the trust policy in B allows A, and an identity policy in A allows the AssumeRole call. The credentials expire, by default after one hour, and every use is traceable in CloudTrail.
For third parties, add an external ID condition to prevent the confused-deputy problem. This is also how AWS Organizations, CI/CD tools and SSO tooling gain access to accounts.
What to say in the interview
"The owning account creates a role with a trust policy for the other account. The caller then uses STS AssumeRole to get short-lived credentials, and both the trust policy and the caller's own permissions must allow it. For third parties I add an external ID."
Common mistakes
- Setting only the trust policy and forgetting the AssumeRole permission on the caller side.