Cross-account access (trust policies, resource policies, external IDs): SCS-C03 study notes and practice questions
What to know about Cross-account access (trust policies, resource policies, external IDs) for the SCS-C03 exam, from the Identity and Access Management domain (20% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.
These questions describe a principal in one account that needs something in another: a role, a bucket, a KMS key or a queue. They usually give a policy that looks correct and ask why access fails, or ask for the smallest safe way to share access. Check both policy sides before choosing an answer.
The facts that decide answers
Role access across accounts needs two policies. The target role’s trust policy names the caller’s account or role as a principal, and the caller’s identity policy allows sts:AssumeRole on that role’s ARN.
Resource-based policies on S3 buckets, SQS queues, SNS topics, Lambda functions and KMS keys can name a principal in another account. For most services, the caller’s account must also allow the action in an identity policy.
KMS works differently. The key policy must allow the account or the principal. An IAM policy alone does not grant access to a key unless the key policy delegates to IAM.
External ID is a condition (sts:ExternalId) in the trust policy of a role that a third party assumes. It stops one vendor customer from tricking the vendor into using your role for another customer, which is the confused-deputy problem.
Service principals can act for other accounts too. Use aws:SourceAccount, aws:SourceArn or aws:SourceOrgID conditions in the resource policy so only your resources are acted on.
Organization-wide sharing uses an aws:PrincipalOrgID condition in the resource policy, which covers every account in the organization without listing them.
How to choose
Scenario wording
Pick
Engineer in account A needs a role in account B
Trust policy in B, plus sts:AssumeRole allowed in A
Share an S3 bucket with another account
Bucket policy, plus an identity policy in the other account
Share a KMS key with another account
Key policy allowing that account, plus an identity policy there
A third-party SaaS vendor needs a role in your account
Role trusting the vendor account with an sts:ExternalId condition
Share a resource with every account in the organization
aws:PrincipalOrgID condition in the resource policy
An AWS service acts on a resource for another account
Service principal condition with aws:SourceArn or aws:SourceAccount
Common traps
Writing only the trust policy and expecting access without the caller’s identity policy.
Adding a principal from another account to a resource policy and forgetting that the caller’s account still has to allow the action.
Using an IAM policy in your account to reach a KMS key in another account without a key policy allowing it.
Omitting the external ID for a third-party role.
Principal "*" without conditions in a resource policy. That is effectively public access, not sharing with one account.
Calling a shared resource private because it has a policy. Use Access Analyzer to see who outside your zone of trust can reach it.
A retail company uses a third-party cost-monitoring vendor. The vendor needs read-only access to billing and resource data in the company's production account, and it runs its service from its own AWS account.
Security wants the vendor integration to reach only this company account, even if another customer of the vendor tries to use the same setup against the company. The company does not want to share any long-term credentials with the vendor.
Which solution meets these requirements?
Choose one answer.
AA. Create a read-only IAM role for the vendor. Its trust policy names the vendor integration role as the principal, and requires an sts:ExternalId condition with a random value that the company gave the vendor.
BB. Create a read-only IAM role whose trust policy names the vendor AWS account root as the principal, with no conditions. Ask the vendor to restrict its own staff to the company account through its internal access controls.
CC. Create an IAM user in the production account for the vendor, with a read-only policy and access keys. Restrict the keys to the vendor's public IP addresses with a policy condition.
DD. Create a read-only role that trusts the vendor account, and attach a permissions boundary that limits the role to billing actions. The vendor cannot reach anything outside billing, even if it misuses the role.
B. Wrong: Trusting the whole vendor account lets any integration in that account request the role. The company then depends on the vendor's internal controls rather than a condition it controls itself.
C. Wrong: The vendor would hold long-term access keys that it must store and protect. Source address limits also break when the vendor service runs on changing addresses, and they do not stop misuse by another customer.
D. Wrong: A permissions boundary limits what the role can do, but it does not control who can assume the role. Another customer's integration in the same vendor account could still assume it and read billing data.
Explanation
The external ID condition lets the company role trust only the vendor integration for this company. That blocks the confused deputy problem, where another customer tricks the vendor service into using the role. Trusting the whole vendor account, sharing long-term keys, and using permission boundaries each leave a path open.
Want more on Cross-account access (trust policies, resource policies, external IDs)? The 5 full-length practice sets have 6 more Cross-account access (trust policies, resource policies, external IDs) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Cross-account access (trust policies, resource policies, external IDs)