An animation studio created a RAM resource share for an account that is not in its organization. The share stays pending, and the other account cannot use the resource. What must happen next?
Select an answer to reveal the explanation.
Short Explanation
An invitation left on the table is not a signed contract. You shared a RAM resource with an account outside the organization, and that share stays pending until the other account accepts it. Peering the VPCs does not accept the share for them.
Full Explanation
For a principal outside the organization, AWS RAM keeps the resource share pending until that principal accepts the invitation. Until then, the resource is not available in the other account. The owner can see that the invitation is pending, and only the recipient account can accept it. The owner cannot complete that step by peering VPCs, because peering is a separate network connection and does not change the share status. StackSet automatic deployment enrolls accounts in the organization into a stack, and it does not accept a RAM invitation for an external account. A share created in the other direction is a new invitation owned by the other account, not an acceptance of the one that is already pending. Caveat: sharing with accounts inside the organization can skip the invitation when RAM is set to share with Organizations, and that setting does not cover an account outside the organization. Operational check: in the recipient account, accept the pending invitation and confirm the share moves from pending to associated before anyone uses the resource.