Exam AWS Certified Security - Specialty topic 1 question 149 discussion

C. The maintainer role does not include the IAM user as a trusted entity. Because as per doc https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html if you switch to RoleA, IAM uses your original user or federated role credentials to determine whether you are allowed to assume RoleA. If you then switch to RoleB while you are using RoleA, AWS still uses your original user or federated role credentials to authorize the switch, not the credentials for RoleA. So by this logic the maintainer role can only be assumed if the IAM user itself is added as a trusted identity for the role.

I think D is the answer. You need sts::assumerole in the security role's policies

It is so called role chaining. The question is about swtich from role A to role B. C may work but not the best practice. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html

✅ RoleB’s trust policy → trusts RoleA → already correct. ✅ Permissions → original IAM user has sts:AssumeRole to RoleA (okay) 🚫 But RoleA doesn’t have sts:AssumeRole to RoleB → that’s the failure.

✅ RoleB’s trust policy → trusts RoleA → already correct. ✅ Permissions → original IAM user has sts:AssumeRole to RoleA (okay) 🚫 But RoleA doesn’t have sts:AssumeRole to RoleB → that’s the failure.

Answer is D, though the trust policy of maintainer role allows the security role to assume it, the security role itself must have a policy allowing it to call sts:AssumeRole on the maintainer role. C is incorrect because the maintainer role trusts the security role, not the IAM user.

I think the answer is D. C is not correct because the question already mentioned that "maintainer role lists security role as a trust entity".

Option C is correct. Second role must have the original IAM user in trusted policy to be able to switch to it, even from First role.

I think the ans is D

The likely cause of the failure is option C, "The maintainer role does not include the IAM user as a trusted entity." When you assume an IAM role in AWS, the role must explicitly specify the trusted entities (in this case, the trusted IAM user or users) that are allowed to assume the role. This is done through a trust policy attached to the role. If the IAM user trying to assume the maintainer role is not listed in the trust policy of the maintainer role as a trusted entity, the operation will fail. Options A and D are not the likely causes of the failure. Option B, which mentions logging in as the AWS account root user, is generally not recommended for day-to-day activities, and using roles with proper permissions is the best practice for access control and security in AWS.

C is the correct answer. True that without sts:AssumeRole we can't assume the second role but the element that makes C the correct answer is that the question states "... the maintainer IAM role, which lists the security role as a trusted entity..." and this is key! This statement makes an incorrect assumption that to assume role B (maintainer) from role A, it's role A's credentials (permissions, trust etc.) that are used and that's incorrect because it's the original user's credentials that are used (check do link in nainakaexam comment : https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). So if in role B's trust policy we specify role A, it's not going to work, we'll have to specify the IAM user or root. And since nothing was said about the IAM user's permissions we'll asssume he has the right to assume both roles. And yes, we have to have a trust relationship for roles even if we're assuming them from the same account!

When switching roles in AWS, the target role (maintainer role in this case) must have a trust policy that specifies which entities are allowed to assume the role. This trust policy defines the trusted entities, such as IAM users, roles, or AWS services, that are permitted to assume the role. In the given scenario, the Security Engineer has successfully switched to the security role, which indicates that the security role's trust policy includes the IAM user as a trusted entity. However, when attempting to switch to the maintainer role, the operation fails. This suggests that the maintainer role's trust policy does not list the IAM user as a trusted entity, thus preventing the Security Engineer from assuming the maintainer role.

Read explanation provided by nainakaexam

It's C, because when you switch role (also if you are assuming other role), the permissions are evaluated starting from IAM User that is logged in. So, the problem is splitted in: 1- Maintainer role doens't has a Trust policy with IAM User as Principal 2- IAM User doesn't has the sts:AssumeRole with Maintainer role as Resource In the Answer list is present the (1) problem.

https://aws.plainenglish.io/aws-iam-role-chaining-df41b1101068

When you switch roles your original permissions determine what can be assumed, Therefore it is obvious that user was not specified as a trusted entity. C

D When a user switches roles in AWS, they need to have permission to assume the role they are switching to. This permission is granted by including a statement in the policy of the role being assumed (in this case, the security role) that allows the sts:AssumeRole action for the maintainer role. Therefore, if the Security Engineer is unable to switch to the maintainer role, it is likely that the security role's policy does not include such a statement, and therefore the Security Engineer cannot assume the maintainer role.