A security analyst needs to let an external vendor (AWS account 555566667777) read data from a set of internal resources in your AWS account. You created an IAM role called VendorReadRole with a policy that allows the required API calls. However, when the vendor tries to access, CloudTrail shows the call fails at AssumeRole with: "Not authorized to perform: sts:AssumeRole".
What is the most appropriate fix?
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 an allow statement for the vendor in the role’s trust policy to permit sts:AssumeRole from the vendor account (and include any required ExternalId condition).
AssumeRole is blocked unless the role trust policy allows the vendor principal. The role’s permissions policy alone cannot permit assumption.
Attach the same allow policy to the vendor account’s existing IAM user so the user can call sts:AssumeRole directly into your role.
Even if the vendor user can call sts:AssumeRole, your role still must trust that principal. Without trust, the AssumeRole request is denied.
Replace the AssumeRole call with GetCallerIdentity so the vendor can infer permissions without assuming the role.
GetCallerIdentity does not grant access to the internal resources. The vendor still needs a trusted identity and proper permissions.
Enable MFA on the vendor’s IAM user and require MFA for your role using condition keys in the permissions policy.
MFA requirements affect the authorization flow but do not solve the root cause. The trust policy must first allow the vendor to assume the role.
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 an allow statement for the vendor in the role’s trust policy to permit sts:AssumeRole from the vendor account (and include any required ExternalId condition). — The error occurs at sts:AssumeRole, which is controlled by the role’s trust relationship (assume role policy), not by the permissions attached to the role. Even a perfectly scoped permissions policy cannot help if the role does not trust the vendor principal. Updating the trust policy to allow the vendor account (and optionally enforce sts:ExternalId) is the correct least-privilege fix. After that, the existing permissions policy can be evaluated for the specific API actions. Why others are wrong: Option B focuses on the vendor-side identity policy, but AssumeRole still requires the target role to trust the vendor principal in your account. Option C misunderstands sts: APIs: GetCallerIdentity does not bypass authorization and cannot access protected resources. Option D addresses an additional security control (MFA) but does not resolve the immediate denial because the trust policy is missing the allow for the vendor to assume the role.
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.