Identity and Access Management A free question from our original SCS-C03 practice exam. Try it, then open the answer to see why each option is right or wrong.
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 →