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 123 discussion

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

A company uses identity federation to authenticate users into an identity account (987654321987) where the users assume an IAM role named IdentityRole. The users then assume an IAM role named JobFunctionRole in the target AWS account (123456789123) to perform their job functions.
A user is unable to assume the IAM role in the target account. The policy attached to the role in the identity account is:

What should be done to enable the user to assume the appropriate role in the target account?

  • A. Update the IAM policy attached to the role in the identity account to be:
  • B. Update the trust policy on the role in the target account to be:
  • C. Update the trust policy on the role in the identity account to be:
  • D. Update the IAM policy attached to the role in the target account to be:
Show Suggested Answer Hide Answer
Suggested Answer: B 🗳️

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
sapien45
Highly Voted 2 years, 10 months ago
Selected Answer: B
Identity role is not a trusted identity in the target account, Principal stateemnt refering to the source role must be specified https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html
upvoted 7 times
StepFunckyTown
2 years, 9 months ago
Agree with you. Answer A is nothing different to the default policy. what needs to be done is to setup principal allowed in target account. So as B
upvoted 1 times
...
HieuTT
2 years, 8 months ago
you wrong, issue is trust policy :)) , this is main point
upvoted 1 times
...
ITGURU51
2 years, 1 month ago
A common use case is when you need to provide access to a role in account A to assume a role in Account B. To facilitate this, you add an entry in the role in account B’s trust policy that allows authenticated principals from account A to assume the role through the sts:AssumeRole API call.
upvoted 1 times
...
...
Raphaello
Most Recent 1 year, 4 months ago
Selected Answer: B
Correct answer is B. To assume a role in a "destination" account, that same role needs to trust (principals in) "source" account to assume it. There has to be a MUTUAL agreement. source permission to assume roles (if not precisely "destination" role) destination permission to be ASSUMED by source principal (through trust policy). I hope that explained it.
upvoted 1 times
...
captainpike
1 year, 12 months ago
Selected Answer: C
I've been using root for quite some time, and I believe C is the correct answer. I tried to make B with no sucess. Can somebody please confirm by testing and not guessing and comment on my answer. Thank you.
upvoted 1 times
captainpike
1 year, 12 months ago
Ignore it. Instead of using role/<rolename> I used role:<rolename>. It did work fine. Answer is B
upvoted 2 times
...
...
BillD_1235
2 years ago
Selected Answer: B
The user is allowed to access the JobFunctionRole in ANY account due to the “*” in the original policy. Answer A actually restricts the user to being able to only do this in that one account. If the user can’t access this role in a specific account, it’s because that account doesn’t have a trust policy allowing THAT user to do so. Both A and B are properly configured, but only B gives the user in the original policy access to the JobFunctionRole IN account B.
upvoted 1 times
...
ITGURU51
2 years, 1 month ago
The role trust policy specifies who can assume the role and the permissions policy decides what can be done with the role. B
upvoted 2 times
...
michele_scar
2 years, 1 month ago
Selected Answer: B
It's B, the answers A and D are equal to the question. So the only answers valid to be analized are B and C. B is more secure than C so it's B.
upvoted 1 times
...
peddyua
2 years, 4 months ago
Selected Answer: A
account-id should be always specified, you can't have wildcard there. It's A
upvoted 2 times
...
jishrajesh
2 years, 6 months ago
B Is the Answer
upvoted 1 times
...
awsmonkey
2 years, 6 months ago
Selected Answer: B
A trust policy in the Identity Account will not give access to the Target Account. Trust policy in the Target account needs to have the role from Identity account designed as allowed principal.
upvoted 2 times
...
jAWStest
2 years, 7 months ago
Selected Answer: B
Current IAM policy allows identity user to assume role, it is not the most secure policy, as it would allow to assume JobFunctionRole in any account, but it would be allowed. Then, the issue must be in the trust policy, and that is why B is the correct answer. ref: https://stackoverflow.com/questions/41566308/how-can-restrict-an-iam-user-to-assume-cross-account-roles-with-a-specific-name
upvoted 1 times
...
JeongPock2y
2 years, 8 months ago
Selected Answer: A
ㅇㅇa is true
upvoted 2 times
...
Qasimac
2 years, 8 months ago
Selected Answer: B
A is similar to policy attached.
upvoted 2 times
yyy
2 years, 8 months ago
B: For example, the Resource element can specify a role by its Amazon Resource Name (ARN) or by a wildcard (*). For example, at least one policy applicable to you must grant permissions similar to the following:
upvoted 1 times
...
...
BKV83
2 years, 9 months ago
Selected Answer: A
A is the correct Answer: Check this Knowledge base Article https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-iam/
upvoted 2 times
...
ashmek
2 years, 9 months ago
A is the correct answer. B is incorrect as principal statement should have JobFunctionRole instead of IdentityRole.
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 ...