A SaaS vendor’s automation account in Account B needs to assume a role in a customer account in Account A to read a specific S3 bucket and publish a deployment status file. The customer is worried about confused deputy attacks because multiple customers use the same vendor software. Which trust-policy design best meets the requirement?

Allow the Account B root principal to assume the role if the caller knows the role ARN.

This would work technically, but it is far too broad and does not protect against confused deputy abuse. Any principal in Account B that can reach the role could potentially use it, which violates the customer’s security requirement.

Attach a permissions boundary to the role so that the vendor cannot exceed the approved permissions.

A permissions boundary limits what permissions the role can have after it is assumed, but it does not stop an unintended principal from assuming the role. It addresses privilege scope, not confused deputy risk.

Require MFA for the role assumption because it ensures only the vendor’s production automation can use the role.

MFA is not a practical control for non-human automation and does not solve cross-account confused deputy risk. The vendor’s automation should use a trust policy with a specific principal and an ExternalId instead.

What does this SAA-C03 question test?

Static NAT maps one inside address to one outside address.

What is the correct answer to this question?

The correct answer is: Allow only the vendor’s specific IAM principal to assume the role and require a unique sts:ExternalId condition. — The strongest protection is to trust only the vendor’s intended IAM principal and require a unique sts:ExternalId in the role trust policy. That combination ensures the customer account can distinguish legitimate vendor requests from requests made by another customer or an attacker who merely knows the role ARN. It is the AWS-recommended pattern for third-party cross-account access and is well suited to automated AssumeRole use. Allowing the root of Account B is too permissive and creates avoidable exposure. A permissions boundary only constrains permissions after assumption; it does not control who may assume the role. MFA is not suited to machine-to-machine automation and still would not prevent a confused deputy scenario. The key control here is the trust policy plus ExternalId.

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.