SAA-C03 Design Secure Architectures Practice Question
Company A must allow workloads in Company B to assume an IAM role in Company A (RoleInA). To mitigate confused-deputy attacks, a Security requirement is to use an External ID. Company A should restrict who can assume RoleInA. Which trust-policy configuration is the best choice?
⚠ Common exam trap
Many candidates confuse `iam:PassRole` with `sts:AssumeRole` or think that a permissions policy can restrict who assumes a role, but only the trust policy defines the trusted principals and conditions for role assumption.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
In Company A role trust policy, allow sts:AssumeRole only for principal "arn:aws:iam::<company-b-account-id>:role/<specific-role-in-b>" and require a condition where sts:ExternalId equals the expected External ID value.
It restricts the trust policy to a specific IAM role in Company B (using the principal ARN) and requires the `sts:ExternalId` condition to match a predefined value. This ensures only the intended role in Company B can assume RoleInA, and the External ID prevents a confused-deputy attack by requiring the third party to provide a unique identifier that only the legitimate service knows.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
In Company A role trust policy, allow sts:AssumeRole for principal "arn:aws:iam::<company-b-account-id>:root" with no sts:ExternalId condition.
Why it's wrong here
This trust policy grants the entire Company B AWS account the ability to assume RoleInA, which is far broader than the least-privilege needed. Any IAM principal in Company B that can delegate the role assumption could potentially do so. More critically, omitting the sts:ExternalId condition fails to protect against the confused deputy problem; if Company B acts as an agent for other parties, one of those parties could misuse this permission. Always scope the principal to the specific role ARN and require an ExternalId when granting third-party access.
- ✓
In Company A role trust policy, allow sts:AssumeRole only for principal "arn:aws:iam::<company-b-account-id>:role/<specific-role-in-b>" and require a condition where sts:ExternalId equals the expected External ID value.
Why this is correct
This is the correct approach because the trust policy limits the takeover to exactly the IAM role ARN in Company B, ensuring no other principal in that account can assume RoleInA. The mandatory sts:ExternalId condition ties the request to your specific business engagement and prevents a confused deputy attack; even if Company B is compromised or acting on behalf of another organization, the request must present the unique ExternalId that you generated and shared only with the intended partner. Low-privilege principal and an external condition together meet AWS's recommended pattern for cross-account third-party access.
- ✗
In the trust policy, allow iam:PassRole for the Company B principal and include an sts:ExternalId condition.
Why it's wrong here
The trust policy for a role must include sts:AssumeRole to allow principals to take on that role, not iam:PassRole. iam:PassRole is designed for granting a principal the right to pass a role to an AWS service such as EC2 or Lambda, not for obtaining temporary security credentials via STS. Including an sts:ExternalId condition does not help because the action is entirely different, so the policy would neither grant nor control role assumption.
- ✗
In Company A, grant Company B access using an IAM permissions policy attached to RoleInA instead of using a trust policy.
Why it's wrong here
A permissions policy attached to RoleInA defines what the role can do after it has been assumed, but it has no effect on who is allowed to assume the role. Cross-account role assumption requires the role's trust policy to explicitly list Company B as a principal with an sts:AssumeRole statement; without that trust policy, no one from Company B can assume RoleInA regardless of how permissive the permissions policy is. Additionally, Company B's IAM principal must also have permissions to call sts:AssumeRole on its own side, but the decisive authorization lies in the trust policy.
Go deeper
Related to this question
About these practice questions
One of 935 original SAA-C03 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.