A network account shares an AMI and a subnet via AWS RAM to a workload account that has SCPs denying certain EC2 and networking actions. What must architects understand about that interaction?
Select an answer to reveal the explanation.
Short Explanation
A borrowed library book still has to follow the branch's quiet-hours rules. RAM can hand over an AMI or subnet, but the consumer account's SCPs still gate what you can do with it.
Full Explanation
When a network account shares an AMI and a subnet via AWS RAM to a workload account that has SCPs denying certain EC2 and networking actions, architects must understand that RAM sharing does not bypass SCP restrictions on the consumer account. Shared resources remain subject to the consumer’s guardrails: if an SCP denies launching from shared AMIs or using shared subnets in forbidden ways, the consumer still receives AccessDenied. RAM distributes resource access invitations; SCPs still define the maximum permission ceiling for API actions in the consuming account.
Believing any RAM share automatically elevates the consumer to OrganizationAdministratorAccess confuses resource sharing with identity privilege escalation and is false. Claiming SCPs are ignored whenever a resource ARN appears in a RAM invitation misunderstands evaluation order—SCPs continue to constrain what IAM can allow. Assuming shared subnets let the consumer disable the management account’s CloudTrail invents a capability RAM does not grant and would violate org security design.
Exam caveat: the intersection of RAM and SCPs is a classic multi-account gotcha—sharing a resource does not override consumer guardrails. Operational check: share a subnet and AMI to a sandbox with a restrictive SCP, attempt a denied launch or ENI action, confirm AccessDenied, then relax only the specific SCP statement required and retest with least privilege.