Exam AWS Certified Solutions Architect - Professional topic 1 question 768 discussion

https://docs.aws.amazon.com/directconnect/latest/UserGuide/multi-account-associate-vgw.html With above guideline, you should: Project Account: a lambda function to: - Create an associate from VPG to the DX Gateway ID (input DX Gateway Owner) (answer A, need directconnect:* permission to do this) - Assume role on Share Service account to accept the association request. Share Service account: - an IAM role to allow Project account's Lambda to assume with directconnect:* permission to allow acction accept/deny the request (answer E) So A,C,E are correct

I would say it is B, D, F

I agree with A,C,E. The key is lambda is in project account. SO B,D,F all mentioned lambda in shared account are out

Why would we give lambda function access to directconnect directly?

The answer is ACE. Quick Resolution: The Lambda must be in the same account with network stack, meaning project account. Therefore, B(wrong): ... Lambda function in the shared services account. D(wrong): Deploy the lambda function .... to the shared services account F(wrong): ... references the lambda function in the shared services account E(correct): Really bad worded answer. 1) Create a cross-account IAM role in the shared services account 2) The cross-account IAM role grants sts:AssumeRole permission to the Lambda function, allowing lambda function in project account to assume it. 3) The cross-account IAM role has directconnect:* permission 4) Add policy to allow Lambda execution role to assume the cross-account role. This is a typical use case of cross account IAM role, but E describes it in a very vague and misleading way.

The correct version is a combination of B and E: 1) The role in shared services contains allow for "directconnect:*". Its trusted policy allows sts:AssumeRole for a principle which is lambda role in B. 2) The role in the project account allows sts:AssumeRole and Resource is the role in the shared services account. So that lamda assumes the role (allowed by its role) and recives the privileges of ASSUMED role. So neither is correct. Apparently the functions should be in the same account (or created along with a VPC networking stack). So it's A without second sentence. In case of the Lambda in the shared account, we don't need any cross-account roles. Bad-worded answers

ACE is correct.

how did you choose between B and E?

ACE makes the most sense. According to AWS "The owner of the virtual private gateway creates an association proposal and the owner of the Direct Connect gateway must accept the association proposal." So it makes sense in this case that the project account would create a virtual gateway association first, and then assume the cross-account role to accept the association in the shared services account.

A,C,E New role in shared account + Lambda in project account

Only 1 lambda function in shared service account is enough. BDF.

It's A C E

AAA CCC EEE ---

ACE is the answer

C,D,E Story explanantion: Project team deploys something which - as a result - creates VGW association in shared account. The flow works as follows (_P for Project, _S for shared) Project team runs a lambda_P which invokes lambda_S (the one team has already tested) and lambda_S creates a desired association In order to do so: lambda_S needs directconnect:* permission to handle DC (option D) lambda_P needs permissions to run lambda_S, which is done via 2 roles - lambda_S can be assumed via dedicated cross-account IAM_1 role (option D part 1) - lambda_P can assume IAM_1 via IAM_2 (role for lamda_P) (option D part 2) Cloudformation is run from _P account and runs lamda_P, --> thus C

https://aws.amazon.com/premiumsupport/knowledge-center/lambda-function-assume-iam-role/

I would say B / C / D https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html