exam questions

Exam AWS Certified Security - Specialty All Questions

View all questions & answers for the AWS Certified Security - Specialty exam

Exam AWS Certified Security - Specialty topic 1 question 149 discussion

Exam question from Amazon's AWS Certified Security - Specialty
Question #: 149
Topic #: 1
[All AWS Certified Security - Specialty Questions]

A Security Engineer signed in to the AWS Management Console as an IAM user and switched to the security role IAM role. To perform a maintenance operation, the Security Engineer needs to switch to the maintainer role IAM role, which lists the security role as a trusted entity. The Security Engineer attempts to switch to the maintainer role, but it fails.
What is the likely cause of the failure?

  • A. The security role and the maintainer role are not assigned to the IAM user that the Security Engineer used to sign in to the account.
  • B. The Security Engineer should have logged in as the AWS account root user, which is allowed to assume any role directly.
  • C. The maintainer role does not include the IAM user as a trusted entity.
  • D. The security role does not include a statement in its policy to allow an sts:AssumeRole action.
Show Suggested Answer Hide Answer
Suggested Answer: C 🗳️

Comments

Chosen Answer:
This is a voting comment (?). It is better to Upvote an existing comment if you don't have anything to add.
Switch to a voting comment New
nainakaexam
Highly Voted 3 years, 6 months ago
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.
upvoted 33 times
addy_prepare
1 year, 8 months ago
one more point to overthink your decision - "... which lists the security role as a trusted entity". But your explanation sounds very good
upvoted 1 times
...
addy_prepare
1 year, 8 months ago
From what reason maintainer role must include trust relationship within the same account's security role?
upvoted 1 times
...
...
PeppaPig
Highly Voted 3 years, 8 months ago
I think D is the answer. You need sts::assumerole in the security role's policies
upvoted 27 times
landsamboni
2 years, 5 months ago
If the sts::assumerole is not present in the security role, then how was the user able to assume that role in the first place?
upvoted 3 times
Mimikabs
2 years, 5 months ago
Because he will need/have it on his IAM user policy in order to switch to the security role.
upvoted 2 times
...
...
...
Arad
Most Recent 11 months, 3 weeks ago
Selected Answer: D
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".
upvoted 1 times
...
Raphaello
1 year, 2 months ago
Selected Answer: C
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.
upvoted 1 times
...
anhtu133
1 year, 5 months ago
Selected Answer: D
I think the ans is D
upvoted 1 times
...
RosenYordanov
1 year, 6 months ago
Selected Answer: C
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.
upvoted 1 times
...
Salah21
1 year, 7 months ago
Selected Answer: C
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!
upvoted 1 times
...
samCarson
1 year, 11 months ago
Selected Answer: C
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.
upvoted 3 times
...
Tofu13
1 year, 11 months ago
Selected Answer: C
Read explanation provided by nainakaexam
upvoted 1 times
...
michele_scar
1 year, 12 months ago
Selected Answer: C
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.
upvoted 1 times
...
matrpro
2 years ago
Selected Answer: D
https://aws.plainenglish.io/aws-iam-role-chaining-df41b1101068
upvoted 2 times
...
ITGURU51
2 years ago
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
upvoted 1 times
...
Nikhil0222
2 years, 1 month ago
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.
upvoted 1 times
...
huyrk102
2 years, 2 months ago
Selected Answer: C
C. The maintainer role does not include the IAM user as a trusted entity. Agreed with @Sowmyarajaram
upvoted 1 times
...
VijiTu
2 years, 7 months ago
I am not sure why role chaining is brought in here as no where in the question its mentioned the role is switched via AWS console. It just says role is switch. just taking AWS docs page as reference, Lets assume we have two Accounts A and B. Account A has a role B which can be assumed to access the services in Account B. We need to attach a policy in Role A of account A with sts:AssumeRole mentioning the Principal Arn of Role B in Account B. This means Role A can assume the mentioned Role in account B. Similarly the Account B should also should have a trust relationship built with Role A from account A. Hence I go in for Option D
upvoted 1 times
VijiTu
2 years, 7 months ago
https://aws.plainenglish.io/aws-iam-role-chaining-df41b1101068
upvoted 1 times
...
...
sapien45
2 years, 8 months ago
Selected Answer: C
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html
upvoted 2 times
...
Sowmyarajaram
3 years ago
It is C. We are using console, so the only authorization that is checked is the actual IAM user’s authorization. “When you switch roles in the AWS Management Console, the console always uses your original credentials to authorize the switch. This applies whether you sign in as an IAM user, as a SAML-federated role, or as a web-identity federated role. For example, 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.” https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html So it doesnt matter whether security role has sts assumerole or not. IAM user must have the authorization to assume this role.
upvoted 7 times
huyrk102
2 years, 2 months ago
Thank you for clear explain
upvoted 1 times
...
...
Community vote distribution
A (35%)
C (25%)
B (20%)
Other
Most Voted
A voting comment increases the vote count for the chosen answer by one.

Upvoting a comment with a selected answer will also increase the vote count towards that answer by one. So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.

SaveCancel
Loading ...
exam
Someone Bought Contributor Access for:
SY0-701
London, 1 minute ago