A SaaS vendor needs temporary access to an S3 bucket in your AWS account to read customer exports. The vendor will assume an IAM role you created. During integration testing, the vendor reports that their AssumeRole requests succeed, but your security team is concerned about the possibility of confused-deputy attacks. Which trust policy approach most directly mitigates this risk?

Require the vendor to use the same MFA device serial number as your internal administrators in the trust policy.

Trust policies can check conditions related to MFA in some contexts, but matching your internal MFA device serial to an external vendor is impractical and not the primary confused-deputy mitigation. External ID was designed specifically for this cross-account vendor role assumption pattern.

Remove the role’s permissions policy and rely only on the S3 bucket policy to validate the caller.

Relying solely on the bucket policy does not address the confused-deputy risk in role assumption. Also, a missing permissions policy may break legitimate access. External ID is the relevant trust policy mitigation for limiting which assumers can obtain credentials.

Allow sts:AssumeRole from the vendor account root principal without restricting to the vendor’s specific IAM role.

Allowing root principal broadly increases risk and does not mitigate confused-deputy attacks. The trust policy should be as specific as possible, and External ID provides a targeted protection against attackers misusing the vendor’s access.

What does this SAA-C03 question test?

Read the scenario before looking for a memorised answer.

What is the correct answer to this question?

The correct answer is: Add an sts:ExternalId condition to the role trust policy that must match the unique external ID you provide to the vendor. — In cross-account vendor integrations, the confused-deputy problem can occur when a third party tricks a vendor into assuming your role without having the right context. AWS recommends using sts:ExternalId in the IAM role trust policy as a shared secret-like value. By requiring the vendor to supply the correct ExternalId, only the intended vendor integration can successfully assume the role. This improves security even if other principals can call AssumeRole to the same role endpoint. Why others are wrong: B is impractical and not the standard mitigation for confused-deputy in role trust. C shifts responsibility to bucket policy and ignores the trust-time risk. D increases exposure by trusting the vendor account broadly; it also does not prevent confused-deputy. External ID directly targets the trust-policy acceptance condition that prevents unintended role assumption.

What should I do if I get this SAA-C03 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.