Sharing resources securely (AWS RAM, Service Catalog): SCS-C03 study notes and practice questions
What to know about Sharing resources securely (AWS RAM, Service Catalog) for the SCS-C03 exam, from the Security Foundations and Governance domain (14% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.
These questions describe a need to share networking or other resources across accounts without losing control, or to let developers deploy only approved configurations. AWS RAM answers the first need and Service Catalog answers the second. Both are usually asked with a requirement to stay inside the organization.
What decides the answer
AWS RAM shares supported resource types, such as VPC subnets, Transit Gateways and Route 53 Resolver rules, with accounts, OUs or the whole organization. Only the resource types RAM supports can be shared.
Organization sharing needs trusted access for RAM enabled in AWS Organizations. After that, accounts in the organization receive the share without an invitation step.
Restrict external sharing. RAM can block sharing with principals outside the organization, so a share cannot be sent to an unknown account by mistake.
Subnet sharing lets another account launch resources into a shared subnet. The owner still controls the subnet, its route tables and its network ACLs. Security groups and IAM permissions stay with the consuming account.
RAM does not share IAM roles or users. Cross-account access to roles is a trust policy problem, not a RAM problem.
Service Catalog holds portfolios of products, which are reviewed CloudFormation templates. You share a portfolio with accounts, OUs or roles, and end users launch products without permission to create the underlying resources directly.
Launch constraints name an IAM role that CloudFormation uses to create the resources, so users need Service Catalog permissions only.
TagOptions attach required tags to every product launched from a portfolio.
How to choose
Scenario wording
Pick
Share a subnet with the other accounts in the organization
RAM with organization sharing
Prevent a share from reaching accounts outside the organization
RAM setting that restricts external sharing
Developers launch only approved, hardened stacks
Service Catalog portfolio
Developers must not get direct permission to create the resource
Service Catalog launch constraint
Share one Transit Gateway with every account in a department
RAM share to the OU or to the account list
Common traps
Sharing with individual account IDs when an organization-level share is simpler and keeps new accounts covered.
Assuming a consumer of a shared subnet controls routing. The owner keeps route tables and network ACLs.
Granting users CloudFormation or EC2 permissions to launch products, which defeats Service Catalog.
Forgetting the launch role. Without it, users need permissions for every resource in the product.
Sharing IAM roles through RAM. RAM does not do that, so use trust policies.
Leaving external sharing unrestricted when the requirement says data must stay in the organization.
A logistics firm runs a shared services VPC with private subnets for its databases and analytics clusters. Application teams in 25 accounts across the organization need to launch resources in those subnets. The network team does not want the subnets shared with any account outside the organization.
The network team wants to keep one VPC for all teams, avoid managing many peering connections, and have the sharing follow the organization structure as new accounts are added.
Which solution meets these requirements with the LEAST operational overhead?
Choose one answer.
AA. Share the private subnets with AWS Resource Access Manager using the account IDs of the 25 application accounts as principals. Accept any share request that the network team approves later from accounts that join the project.
BB. Create VPC peering connections from the shared services VPC to each of the 25 application VPCs, and update the route tables on both sides. Restrict each peering route to the subnets that each team needs.
CC. Share the private subnets through AWS Resource Access Manager with the organization or the OU of the application accounts, with sharing outside the organization turned off.
DD. Create a Transit Gateway in the network account, share it through RAM, and allow external principals so that outside teams can attach too. Attach each team VPC to the gateway.
Show the answer and explanation
Answer: C
A. Wrong: Sharing by account ID means every new account needs a new share, which defeats the goal of following the organization. Accepting requests from accounts outside the organization also risks sharing with accounts the team does not control.
B. Wrong: Peering works, but 25 connections and their routes are hard to manage, and each new account adds more. Peering does not follow the organization structure, which the network team wants.
C. Right: Correct. Sharing to the organization or an OU follows the account structure, and RAM can restrict sharing to principals inside the organization. Teams launch into the shared subnets without a new connection per account. Learn more: What is AWS Resource Access Manager? (opens in a new tab)
D. Wrong: Allowing external principals opens the network to accounts outside the organization, which the network team forbids. A Transit Gateway also adds attachments and routes for each VPC that the team must manage.
Explanation
AWS RAM can share subnets with an organization or an OU, and it can block sharing with accounts outside the organization. Accounts added to that OU get access automatically, so the network team keeps one VPC with no per-account connections. Per-account shares, peering, and an external-friendly transit gateway each miss one requirement.
Want more on Sharing resources securely (AWS RAM, Service Catalog)? The 5 full-length practice sets have 5 more Sharing resources securely (AWS RAM, Service Catalog) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Sharing resources securely (AWS RAM, Service Catalog)