Cross-account resource sharing (AWS RAM): SAP-C03 study notes and practice questions
What to know about Cross-account resource sharing (AWS RAM) for the SAP-C03 exam, from the Security, Compliance, and Governance domain (25% of the exam guide), then 1 free question to test it. Part of the SAP-C03 study guide.
These questions describe a central team that owns networking or other shared infrastructure and many workload accounts that need to use it, and ask for the simplest secure way to share without copying resources into every account.
How AWS RAM works
The owner creates a resource share, adds resources, and names principals: the whole organization, an OU, accounts, or for some resource types IAM roles and users.
Enable sharing with AWS Organizations once from the management account; shares inside the organization are then accepted automatically with no invitations. Sharing outside the organization needs the recipient to accept.
Managed permissions define what consumers can do with each resource type; some types offer customer managed permissions for tighter control.
Shared resources stay owned by the owner account; consumers can’t delete them. Removing a principal from the share removes access.
Sharing to an OU means new accounts in that OU get access automatically.
What gets shared most
VPC subnets (VPC sharing): a central network account owns the VPC, subnets, route tables, NAT gateways and endpoints; participant accounts launch their own instances, databases and load balancers into the shared subnets. Each participant pays for its own resources and manages its own security groups. Fewer VPCs, fewer IP ranges and no peering mesh.
Transit gateways: one hub shared to all accounts, which create their own attachments (multi-VPC connectivity).
Route 53 Resolver rules: central forwarding rules for hybrid DNS, associated with VPCs in each account.
Customer managed prefix lists for consistent security group and route entries, IPAM pools for central IP allocation, Network Firewall policies, VPC Lattice service networks, AWS Private CA for certificate issuance, EC2 capacity reservations and Outposts.
RAM or a resource policy?
Services with resource-based policies (S3, KMS, SQS, SNS, Lambda, Secrets Manager, ECR) share through the policy, often with aws:PrincipalOrgID.
Resources without resource policies (subnets, transit gateways, Resolver rules) share through RAM.
AMIs and snapshots can be shared through their own permission settings; encrypted ones also need KMS key access.
How to choose
Scenario wording
Pick
Central network team, app teams deploy into it, avoid peering
VPC sharing through RAM
Every account connects to one hub
Share the transit gateway through RAM
Same on-premises forwarding rules in all VPCs
Share Resolver rules through RAM
Consistent allowlists across accounts
Shared prefix list
Bucket readable by all org accounts
Bucket policy with aws:PrincipalOrgID
Common traps
Recreating the same resource in every account when sharing works.
Expecting participants to modify shared subnets or route tables; only the owner can.
Leaving Organizations sharing disabled, which forces invitations for every account.
VPC peering meshes for dozens of accounts when VPC sharing or Transit Gateway scales.
Sharing an encrypted snapshot without granting the KMS key.
A logistics firm's network team runs the company's shared subnets in a network account. About 15 application accounts must launch databases and containers into those subnets, but the network team must keep ownership of the subnets, their route tables and their IP ranges.
The network team wants new application accounts added to the shared subnets without a manual change in the network account for each one.
Which solution meets these requirements?
Choose one answer.
AA. Peer each application VPC with the network account's VPC, and let each application team create its own subnets in the peered VPC.
BB. Deploy the network stack into each of the 15 accounts with CloudFormation StackSets, so that each account gets its own copy of the subnets and route tables.
CC. Share the subnets from the network account with AWS Resource Access Manager, using the organization as the principal, so each application account can launch resources into them.
DD. Create an IAM role in the network account for each application team, and let the teams assume the role to change the shared route tables and the IP ranges.
Show the answer and explanation
Answer: C
A. Wrong: Peering connects the networks but leaves the subnets in the application accounts, so the network team does not own the subnets. The design also needs a peering connection and routes for every account.
B. Wrong: Each account would own its own copy of the subnets and routes, so the network team would lose central control of the IP ranges. Copies also drift as the network changes.
C. Right: Correct. RAM shares the subnets while the network account keeps ownership of them, their route tables and their CIDR ranges. Accounts that join the organization get access without a manual change in the network account.
D. Wrong: This gives the application teams the power to change the routes and ranges that the network team should own. Assuming a role does not put the subnets into the application accounts' scope.
Explanation
RAM shares the subnets from the network account to the organization, so ownership of the subnets and routes stays central while accounts launch into them. Peering, copied stacks and roles that change routing each break the ownership or scale requirement.
Want more on Cross-account resource sharing (AWS RAM)? The 5 full-length practice sets have 5 more Cross-account resource sharing (AWS RAM) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →