A SaaS vendor will access your AWS resources by assuming an IAM role in your account. You want to prevent confused-deputy attacks and ensure the vendor can only assume the role using an agreed external identifier.
Your role trust policy currently allows sts:AssumeRole from the vendor’s principal, but it does not include any external ID protection. Which change is the best next step?
Answer choices
Good practice is not just finding the correct option. The wrong answers often show the exact trap the exam wants you to fall into.
Add a condition to the trust policy: Condition = {"StringEquals": {"sts:ExternalId": "vendor-agreed-id"}}.
Using sts:ExternalId in the trust policy ensures only assume-role requests presenting the correct external identifier are allowed. This directly mitigates confused-deputy attacks by binding authorization to a value the vendor must know. It also keeps the permissions model clean, because the check is enforced during the STS AssumeRole request.
Add a condition to the trust policy: Condition = {"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}}.
Source IP restrictions are brittle for vendors using dynamic egress addresses and do not directly address confused-deputy risk. The problem described is an authorization design gap around external identity. IP conditions can also block legitimate vendor traffic and complicate operations.
Remove sts:AssumeRole and replace it with sts:AssumeRoleWithWebIdentity to use the vendor’s browser-based tokens.
AssumeRoleWithWebIdentity is not relevant to a service-to-service SaaS access pattern described. It also introduces additional complexity and reliance on OIDC tokens and providers. The key requirement here is external ID protection in AssumeRole trust, not switching STS APIs.
Add a condition to the role permissions policy (not the trust policy) requiring aws:PrincipalTag/ExternalId to equal the external identifier.
Role permissions policies do not govern who can assume the role; the trust policy does. Also, PrincipalTag-based checks would require the tag to be supplied and mapped reliably. The most appropriate place for confused-deputy protection is the AssumeRole trust policy with sts:ExternalId.
Common exam trap
Logging in proves the user can authenticate. It does not automatically mean the user is allowed to enter privileged or configuration mode. Watch for AAA authorization, privilege level and command authorization details.
Technical deep dive
This kind of question is testing the difference between identity and permission. A user may successfully log in to a router because authentication is working, but still fail to enter configuration mode because authorization is missing, misconfigured or mapped to a lower privilege level.
Related practice questions
Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.
Practise SAA-C03 questions linked to SAA-C03 VPC.
Practise SAA-C03 questions linked to SAA-C03 S3 lifecycle policy questions.
Practise SAA-C03 questions linked to SAA-C03 RDS Multi-AZ questions.
Practise SAA-C03 questions linked to SAA-C03 IAM policy.
Practise SAA-C03 questions linked to SAA-C03 Route 53 failover questions.
Practise SAA-C03 questions linked to SAA-C03 CloudFront.
Practise SAA-C03 questions linked to SAA-C03 NAT gateway questions.
Practise SAA-C03 questions linked to SAA-C03 VPC endpoint questions.
Practise SAA-C03 questions linked to SAA-C03 Auto Scaling.
Practise SAA-C03 questions linked to SAA-C03 disaster recovery questions.
Practise SAA-C03 questions linked to SAA-C03 high availability questions.
Practise SAA-C03 questions linked to SAA-C03 cost optimization questions.
Keep practising from the same exam bank, or move into a focused topic page if this question exposed a weak area.
Question 1
Question 2
Question 3
Question 4
Question 5
Question 6
FAQ
Authentication checks who the user is.
The correct answer is: Add a condition to the trust policy: Condition = {"StringEquals": {"sts:ExternalId": "vendor-agreed-id"}}. — Confused-deputy mitigation for cross-account AssumeRole is typically implemented by requiring sts:ExternalId in the role trust policy. When a vendor calls AssumeRole, they must provide the same external ID you configured, so an attacker who tricks your account cannot obtain credentials without knowing that shared value. Option A adds exactly that trust-policy condition. This is enforced at STS authorization time and does not depend on downstream permissions behavior. Why others are wrong: Option B focuses on IP allowlisting, which is not the specified threat model and is often unreliable for SaaS providers. Option C swaps to AssumeRoleWithWebIdentity, which doesn’t match the stated AssumeRole pattern and doesn’t address external identity checks. Option D places the control in the wrong policy type (permissions vs trust) and relies on principal tags that are not the standard confused-deputy control for sts:ExternalId.
Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.
Sign in to join the discussion.