You are looking to migrate your Development (Dev) and Test environments to AWS. You have decided to use
separate AWS accounts to host each environment. You plan to link each accounts bill to a Master AWS account
using Consolidated Billing. To make sure you Keep within budget you would like to implement a way for
administrators in the Master account to have access to stop, delete and/or terminate resources in both the
Dev and Test accounts. Identify which option will allow you to achieve this goal.
A.
Create IAM users in the Master account with full Admin permissions. Create cross-account roles in the Dev and
Test accounts that grant the Master account access to the resources in the account by inheriting permissions
from the Master account.
B.
Create IAM users and a cross-account role in the Master account that grants full Admin permissions to the Dev
and Test accounts.
C.
Create IAM users in the Master account Create cross-account roles in the Dev and Test accounts that have full
Admin permissions and grant the Master account access.
D.
Link the accounts using Consolidated Billing. This will give IAM users in the Master account access to resources
in the Dev and Test accounts
c
0
0
C it is.
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html
0
0
C.
Create IAM users in the Master account Create cross-account roles in the Dev and Test accounts that have full
Admin permissions and grant the Master account access.
0
0
1. Create Account is Master Account
2. Attach Policy Administrator Access or Create a Group and attach policy Administrator-Access
3. Create a Group in DEV and Test Cross-Account Access
4. Create Policy – Assume Role in Master Account and attach the policy to the master account.
5. Provide Assume role link to Master Account Admin.
Non of the answers are correct — Because we need “AssumeRole”
If i need pick one – I would go with “A”
0
0
c
0
0
I vote C:
A. This one is incorrect because you cannot “inherit permissions” from one AWS account to another. You could get the other account holder to send you the policy document on their side and cut and paste it into your policy document if you wanted to do so, but you cannot automatically “inherit” that policy.
B. Incorrect because the role for cross-account access is not created in the “Master” account. It would be created in the “Dev” and “Test” accounts that are trusting the “Master” account. (It would be a very bad scenario if the account wishing to have access to another account could create the role and everything all in their own account, without the truster account having to do anything to allow it. Any one account could take over any other account at any time. Clearly wrong.)
C. This is correct. You would have users log into IAM in the “Master” account, and have the role created by the admins in the “Dev” and “Test” accounts. Those IAM users in the “Master” account would switch role either using the pre-populated URL containing the AccountID and Role Name that the Dev and Test admins sent them, or would have to know those values and input them manually. Permissions would be needed in both accounts in order for this to work:
– The Master account IAM users would need to be either full Administrator or Power User access, or if not, would need to explicitly have access granted via policy to perform “Action”: “sts:AssumeRole” with the resource for that action being the ARN of the other accounts’ roles (which the other accounts administrators would have to send to the Master account admin)
– The “Test” and “Dev” account admins would need to grant the role in their accounts access to do pretty much anything, because the scenario is asking for the Master account to have full access.
Note: Srinivasu’s comment is very observant. He notes that option A mentions that the Master account IAM users will have full Administrator access, thus allowing them to perform action “sts:AssumeRole”, which they might not necessarily have unless they are Adminstrators or Power Users. And option C does not explicitly mention this, somewhat implying that option C may be missing this piece in the Master account. If you want to be that detailed/picky, then he is right, none of these answers are correct. But C is closest, and A is definitely wrong due to not being able to “inherit” permissions between accounts. So I’m voting C.
D. This is incorrect because linking accounts for consolidated billing purposes does not give the payer account access to do anything in the linked accounts. The payer account can only see billing info for those linked accounts.
4
0
C
0
0