A regional health system owns a transit gateway in its network account and wants a second account to attach a VPC to that same gateway. Ownership of the gateway should stay put. How should they share it?
Select an answer to reveal the explanation.
Short Explanation
The highway stays owned by one agency even when another agency is allowed to build an on-ramp. You share the transit gateway with the other account through AWS RAM, and that account then attaches its VPC. Peering the VPCs, or copying a route table, does not hand over the existing gateway.
Full Explanation
A transit gateway is shared by a RAM resource share that names the gateway and the other account as a principal. Ownership stays with the network account. After the share is associated, the other account creates a VPC attachment to that gateway, and the network account accepts the attachment unless auto-accept is already enabled. Peering the VPCs builds a separate path between two networks and does not let the second account attach to this gateway. Copying a route table into the other account does not create a transit gateway there. A VPN is a different kind of attachment you might add later, and it is not the share that lets the other account attach its VPC. Caveat: if the second account is outside the organization, the RAM share stays pending until that account accepts it, so the attachment cannot be created any earlier. Operational check: confirm the resource share is associated, create the VPC attachment from the second account, accept it in the network account, and verify the attachment is available before routes are added.