IAM roles, STS, federation and cross-account access
7 min read · about 1 h 15 min with practice3 quick checks≈3% of the testCore: Core: tested on most papers
Reading is free. Sign in to tick off lessons, keep your place and track your mastery.
Most secure-access questions share one answer: use temporary credentials from a role. SAA-C03 tests whether you can pick the right way to get them (instance profile, task role, federation, cross-account role or resource-based policy) and the directory service behind them.
By the end you’ll be able to
Design role-based access with STS AssumeRole, instance profiles, ECS task roles and Lambda execution roles instead of embedded keys
Choose between a cross-account IAM role and a resource-based policy (S3, KMS, SQS, SNS, Lambda) for sharing across accounts, including the need for both sides to allow
Select IAM Identity Center, SAML 2.0 federation or OIDC web identity for workforce and application sign-in
Choose among AWS Managed Microsoft AD, AD Connector and Simple AD to integrate an on-premises directory
Use external IDs and trust-policy conditions to prevent confused-deputy access by third parties
What the exam asks
Replace access keys in code, configuration files and CI/CD pipelines with roles.
Give another AWS account access with a cross-account role or a resource-based policy, and know what each side must allow.
Let a third party into your account safely with an external ID.
Sign employees in to many accounts with their existing corporate identity through IAM Identity Center.
Pick AWS Managed Microsoft AD, AD Connector or Simple AD.
Core ideas
Roles and AWS STS
A role has two policies:
The trust policy names who may assume the role in its Principal element.
The permissions policy says what the session can do.
AWS Security Token Service (STS) issues the temporary credentials, and they expire automatically. Sessions last 1 hour by default. You can raise a role’s maximum session duration to 12 hours, but role chaining is always limited to 1 hour.
STS path
Who uses it
AssumeRole
Cross-account access, switching roles, third parties
AssumeRoleWithSAML
Workforce federation from a SAML 2.0 identity provider (IdP)
AssumeRoleWithWebIdentity
OIDC tokens from CI/CD systems, Kubernetes service accounts and, through Cognito, app users
GetSessionToken
An IAM user adding MFA to CLI sessions
IAM Roles Anywhere
On-premises servers that hold X.509 certificates from a trusted CA
Roles for workloads
Workload
Mechanism
EC2
Instance profile: the role is attached to the instance, and SDKs fetch its credentials from instance metadata
ECS/Fargate
for the application’s API calls. for the ECS agent to pull ECR images, write logs and fetch injected secrets
vii.Check your understanding
3 questions on IAM roles, STS, federation and cross-account access. Every option is explained once you answer.
Sign in to try the quick check
Answers are checked on our side, every option is explained, and your result feeds your mastery for this topic. It’s free.
The first 3 of 11 cards for this topic. Sign in and finish the lesson to review them with spaced repetition.
PromptCard 1 of 3
Role trust policy vs permissions policy
Task role
Task execution role
Lambda
Execution role
EKS
IAM roles for service accounts (IRSA) or EKS Pod Identity
On premises
IAM Roles Anywhere
External CI/CD
IAM OIDC identity provider + a role whose trust policy checks the token claims
Protect instance-profile credentials by requiring IMDSv2. IMDSv2 requires a session token obtained with a PUT request, which blocks most SSRF attempts to read the metadata service. Security groups and network ACLs do not filter metadata traffic.
Copying between buckets in two accounts; sharing one queue or key
Both sides must allow the access:
The caller’s identity policy must allow sts:AssumeRole (or the S3 or SQS action).
The trust policy or resource policy must allow the caller.
The exam often tests two further details:
S3 object ownership. New buckets default to Bucket owner enforced (ACLs disabled), so the bucket owner automatically owns objects that other accounts upload.
KMS. To read SSE-KMS objects, kms:Decrypt must be allowed in the key policy and in the caller’s IAM policy. You cannot edit the key policy of an AWS managed key such as aws/s3, so sharing encrypted data across accounts requires a customer managed key.
Third parties and the confused deputy
A SaaS vendor may serve many customers from one AWS account. Give it a role that trusts the vendor’s account and requires the unique external ID that the vendor assigns to you:
Without the external ID, another of the vendor’s customers could trick the vendor into using your role. This is the confused deputy problem. When a resource policy grants access to an AWS service principal, the equivalent guard is the aws:SourceArn and aws:SourceAccount condition keys.
Workforce federation
IAM Identity Center is the default answer for employee access to multiple accounts. It gives employees one sign-in portal. You define permission sets, and Identity Center deploys them as roles in each assigned account.
The identity source can be one of three:
The built-in Identity Center directory.
Active Directory.
An external SAML 2.0 IdP such as Okta or Microsoft Entra ID, with SCIM automatically provisioning users and groups.
Direct SAML federation to IAM still works for a single account, but you must configure it account by account. Amazon Cognito is for your application’s customers, not for employees who need the AWS console.
AWS Directory Service
Option
What it is
Choose when
AWS Managed Microsoft AD
A real Microsoft AD that AWS runs across two AZs. Supports trusts, Group Policy, LDAP and Kerberos
You have AD-aware workloads in AWS, need a trust with on-premises AD, or need a directory that works in AWS on its own
AD Connector
A proxy that forwards requests to your on-premises AD and stores nothing
You want to use existing AD credentials with AWS services (Identity Center, EC2 domain join) without a directory in AWS. It needs a VPN or Direct Connect connection
Simple AD
A basic, Samba-based directory compatible with AD
You need a small, standalone, low-cost directory. No trusts and no MFA
Worked examples
Exam technique
“Access keys” anywhere in the stem means the answer replaces them with a role. Moving keys into Secrets Manager, Parameter Store or user data does not fix the problem.
“Keep its own permissions” or “copy between accounts” points to a resource-based policy. “Many actions” or “people switching accounts” points to a cross-account role.
“Third party” or “vendor” points to a role with an external ID.
“Many accounts” and “corporate IdP” point to IAM Identity Center with SCIM. “Customers of our app” points to Cognito.
In ECS items, check which role each option changes. Application permissions belong on the task role.
Common mistakes
Quick recap
Roles and STS provide temporary credentials. The trust policy says who can assume the role, and the permissions policy says what the session can do.
Match the mechanism to where the code runs: instance profile, task role, execution role, Roles Anywhere or an OIDC provider.
Require IMDSv2 to protect instance credentials.
Cross-account access needs an allow on both sides. Resource-based policies let the caller keep its own permissions.
Third parties get a role with an external ID.
Use IAM Identity Center (permission sets, an external IdP and SCIM) for workforce access to many accounts.
Use Managed Microsoft AD for trusts and AD-aware workloads, AD Connector as a proxy, and Simple AD for a small standalone directory.