SAA-C03 Design Secure Architectures Practice Question
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?
⚠ Common exam trap
Candidates often think MFA or bucket policies are sufficient for cross-account security, but the confused-deputy attack is specifically mitigated by the `sts:ExternalId` condition, not by authentication factors or resource-based policies alone.
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
✓
Add an sts:ExternalId condition to the role trust policy that must match the unique external ID you provide to the vendor.
The `sts:ExternalId` condition in the trust policy forces the vendor to include a unique external ID in their `AssumeRole` API call. This prevents a confused-deputy attack by ensuring that the role can only be assumed when the caller provides the exact external ID you have pre-shared, thereby verifying the intended purpose of the cross-account access.
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 sts:ExternalId condition to the role trust policy that must match the unique external ID you provide to the vendor.
Why this is correct
The sts:ExternalId condition is a common protection against confused-deputy scenarios in cross-account role assumption. It ensures that only principals who know the unique external ID can successfully assume the role. This mitigates a third party tricking the vendor’s identity into assuming your role, even if they can call AssumeRole.
- ✗
Require the vendor to use the same MFA device serial number as your internal administrators in the trust policy.
Why it's wrong here
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.
When this WOULD be correct
If the question were about ensuring that only authenticated users with a specific MFA device (e.g., a hardware token assigned to a known partner) can assume a role, and the vendor is able to use that device, then requiring the same MFA serial number in the trust policy would be correct.
- ✗
Remove the role’s permissions policy and rely only on the S3 bucket policy to validate the caller.
Why it's wrong here
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.
Why it's wrong here
Allowing sts:AssumeRole from the vendor account root principal grants any IAM principal in the vendor account—including unauthorized users or roles—the ability to assume your role, vastly expanding the attack surface. This does nothing to prevent a confused-deputy attack because the root principal has no inherent identity constraint; an attacker who compromises any identity in the vendor account can call AssumeRole as that identity. The trust policy should be scoped to the specific IAM role the vendor will use, and should include an sts:ExternalId condition so that only a caller presenting the unique external ID can succeed, even if that caller is in the vendor account.
When this WOULD be correct
In a scenario where the vendor account is fully trusted and the goal is to simplify access without needing to specify a particular role, allowing the root principal might be acceptable if the vendor account is controlled by the same organization or has strict internal controls.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.
✓Add an sts:ExternalId condition to the role trust policy that must match the unique external ID you provide to the vendor.Correct answer▾
Why this is correct
The sts:ExternalId condition is a common protection against confused-deputy scenarios in cross-account role assumption. It ensures that only principals who know the unique external ID can successfully assume the role. This mitigates a third party tricking the vendor’s identity into assuming your role, even if they can call AssumeRole.
✗Require the vendor to use the same MFA device serial number as your internal administrators in the trust policy.Wrong answer — click to see why▾
Why this is wrong here
Requiring the vendor to use the same MFA device serial number as your internal administrators is impractical and does not prevent confused-deputy attacks; the vendor cannot use your administrators' MFA device, and this condition does not tie the request to a specific external entity.
★ When this WOULD be the correct answer
If the question were about ensuring that only authenticated users with a specific MFA device (e.g., a hardware token assigned to a known partner) can assume a role, and the vendor is able to use that device, then requiring the same MFA serial number in the trust policy would be correct.
Why candidates choose this
Candidates may think that MFA adds a strong layer of authentication and assume it can prevent confused-deputy attacks, but they overlook that MFA does not provide a unique identifier for the external party's intent.
✗Allow sts:AssumeRole from the vendor account root principal without restricting to the vendor’s specific IAM role.Wrong answer — click to see why▾
Why this is wrong here
Allowing sts:AssumeRole from the vendor account root principal without restricting to the vendor’s specific IAM role does not mitigate confused-deputy attacks because any role or user in the vendor account can assume the role, increasing the risk of misuse.
★ When this WOULD be the correct answer
In a scenario where the vendor account is fully trusted and the goal is to simplify access without needing to specify a particular role, allowing the root principal might be acceptable if the vendor account is controlled by the same organization or has strict internal controls.
Why candidates choose this
Candidates may think that allowing the root principal is simpler and still secure because the vendor account is trusted, overlooking the need for granularity to prevent confused-deputy attacks.
Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
This SAA-C03 question is part of Courseiva's 935-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.