SAA-C03 Design Secure Architectures Practice Question
Exhibit
{
"role_arn": "arn:aws:iam::111122223333:role/InboundExportRole",
"trust_policy": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::222233334444:root"},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {"sts:ExternalId": "acctB-export-91"}
}
}
]
},
"cloudtrail_event": {
"eventName": "AssumeRole",
"userIdentity": "arn:aws:iam::222233334444:role/BatchRunner",
"errorCode": "AccessDenied",
"errorMessage": "Not authorized to perform sts:AssumeRole on resource arn:aws:iam::111122223333:role/InboundExportRole"
}
}Based on the exhibit, a batch platform in Account B must assume a role in Account A. Only the specific role arn:aws:iam::222233334444:role/BatchRunner should be allowed to assume it, and the design must prevent any other role in Account B from reusing the same external ID. Which change best meets the requirement?
⚠ Common exam trap
Test-takers frequently think an identity-based policy on the assuming role (Option A) is sufficient, but the trust policy on the target role must explicitly restrict the principal to the specific role ARN, not just the account root.
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
✓
Change the trust policy principal from account root to arn:aws:iam::222233334444:role/BatchRunner and keep the ExternalId condition.
The trust policy on the target role in Account A must restrict the principal to the exact BatchRunner role ARN (arn:aws:iam::222233334444:role/BatchRunner) rather than the entire Account B root. This ensures that only that specific role can assume the target role. Keeping the ExternalId condition adds an additional layer of security by requiring a unique identifier that only BatchRunner knows, preventing any other role in Account B from reusing the same external ID.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add an identity-based policy to the BatchRunner role that allows sts:AssumeRole on the target role.
Why it's wrong here
Adding an identity-based policy to BatchRunner that allows sts:AssumeRole over the target role is insufficient because resource-based policies, such as the target role's trust policy, must explicitly authorize the principal in Account B. Without that trust relationship, the target role rejects the request even if BatchRunner has its own policy allowing the action; the identity policy alone cannot grant access to a cross-account role.
- ✓
Change the trust policy principal from account root to arn:aws:iam::222233334444:role/BatchRunner and keep the ExternalId condition.
Why this is correct
Restricting the trust policy principal from the entire 222233334444 account root to the exact ARN arn:aws:iam::222233334444:role/BatchRunner is the correct fix because it follows least privilege by allowing only that specific role to assume the target role. Keeping the ExternalId condition preserves protection against the confused deputy problem, requiring the caller to present the correct ExternalId in the sts:AssumeRole request before the trust policy authorizes the assumption.
- ✗
Replace the ExternalId condition with a role session name condition so only BatchRunner sessions are accepted.
Why it's wrong here
Replacing the ExternalId condition with a role session name condition is flawed because the RoleSessionName parameter is entirely user-controlled and can be set to any arbitrary string by the caller. Unlike ExternalId, which must match a shared secret known to both parties, a session name is not a verifiable identity and provides no meaningful security boundary; it cannot enforce that only BatchRunner sessions are accepted.
- ✗
Attach an SCP to Account B that denies sts:AssumeRole unless the request comes from BatchRunner.
Why it's wrong here
Attaching an SCP to Account B that denies sts:AssumeRole unless the request comes from BatchRunner will not fix the authorization gap because the target role sits in Account A and its trust policy governs the assumption. SCPs only restrict actions for principals in Account B; they cannot grant or override permissions in another account, and an SCP cannot condition on the source role in a way that compensates for a missing trust policy in Account A.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SAA-C03 question from scratch — 935 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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.