These questions are independently created for study purposes. They are not official AWS exam questions, actual exam questions, leaked questions, or exam dumps.
SAA-032
You need to delegate permission to read resources in your AWS account to an external SaaS monitoring vendor. The vendor calls the APIs from its own AWS account. Which configuration is the most appropriate for delegating access while preventing the confused deputy problem?
Choices
Explanation and answer
Read the explanation and correct answer (spoiler — try answering first)
Correct answer: C. Create an IAM role that trusts the vendor's AWS account and require a unique value issued by the vendor for sts:ExternalId in a Condition element of the trust policy
Explanation
For cross-account access granted to a third party, AWS recommends adding an sts:ExternalId Condition element to the trust policy of the IAM role. A third party that does not know the External ID cannot assume the role even through the vendor's account, which prevents the confused deputy problem.
Per-choice explanations
A. Add a resource-based policy to each target resource that allows read access to the vendor's AWS account
Incorrect. Resource-based policies can grant access only for a subset of services such as S3 buckets and KMS keys, and every additional read target requires another individual entry. This breaks down operationally, and there is no protection via an External ID.
B. Create a dedicated IAM user for the vendor, attach ReadOnlyAccess, share the issued access key with the vendor, and rotate it every 90 days
Incorrect. Handing long-term access keys to an external organization has a large blast radius if they leak, and revocation is manual. Even with rotation, temporary credentials via an IAM role are recommended for cross-account access.
C. Create an IAM role that trusts the vendor's AWS account and require a unique value issued by the vendor for sts:ExternalId in a Condition element of the trust policy
Correct. By requiring the External ID issued by the vendor in a Condition element of the trust policy, you structurally prevent the confused deputy problem.
D. Create an IAM role that trusts only the vendor's AWS account ID and attach ReadOnlyAccess
Incorrect. Using a role is the right direction, but without an External ID you cannot prevent the confused deputy problem, in which the vendor mixes up the permissions it holds for another customer and operates on your resources. It does not meet the requirement.
Practical Use
Delegating permissions across AWS accounts should be done with IAM roles and AWS STS AssumeRole, not by sharing IAM users and access keys. The delegating side (your company) creates the role and writes the other party's account ID or role ARN in the Principal of the trust policy. The other party calls AssumeRole to obtain temporary credentials, and once those credentials expire the permissions disappear automatically. Compared with handing long-term access keys to an outside party, the exposure window after a leak is far shorter, and you can cut off access instantly just by deleting the trust policy. With third-party SaaS, where a single vendor accesses many customer accounts through the same mechanism, the confused deputy problem can arise. If the vendor mistakenly specifies customer A's role ARN (or is tricked into doing so by an attacker), operations that customer A never intended are performed. To prevent this, require sts:ExternalId in a Condition element of the trust policy. The External ID is a unique string that the vendor issues per customer; it is not a secret but functions as an identifier that prevents mix-ups. In addition, the delegated permissions should be a custom policy narrowed to the required APIs rather than a managed policy such as ReadOnlyAccess as-is. On SAA-C03, when keywords such as "external vendor," "another company's account," "confused deputy," or "External ID" appear, an IAM role plus sts:ExternalId is the correct answer. Distractors include sharing IAM user access keys, sharing root user credentials, and a cross-account role with no conditions. It is also worth remembering the distinction that between your own multiple accounts (under AWS Organizations) an External ID is unnecessary, and you use SCPs or the aws:PrincipalOrgID condition instead.