StackSets and resource sharing: SOA-C03 study notes and practice questions
What to know about StackSets and resource sharing for the SOA-C03 exam, from the Deployment, Provisioning, and Automation domain (22% of the exam guide), then 2 free questions to test it. Part of the SOA-C03 study guide.
These questions ask how to roll out the same setup to many accounts, or share one resource with them.
CloudFormation StackSets
Deploys stack instances of one template to chosen accounts and Regions.
Permission models:
Service-managed (with AWS Organizations): target OUs; StackSets creates the roles it needs; automatic deployment adds stacks to new accounts that join the OU and can remove them when accounts leave.
Self-managed: you create the AWSCloudFormationStackSetAdministrationRole in the admin account and AWSCloudFormationStackSetExecutionRole in each target account.
Deployment options: maximum concurrent accounts, failure tolerance, Region order and concurrency mode control how fast and how safely it rolls out.
A delegated administrator account can manage StackSets instead of the management account.
AWS Resource Access Manager (RAM)
Shares resources with other accounts or the whole organization, without copying them:
VPC subnets (VPC sharing): participants launch their own resources into shared subnets; the owner manages the network.
Transit Gateways, Route 53 Resolver rules, License Manager configurations, Aurora clusters, AWS Network Firewall policies, Systems Manager Parameter Store advanced parameters and more.
Turn on sharing with AWS Organizations in RAM to share with OUs without invitations.
Other tools
AWS Service Catalog: approved products (CloudFormation templates) that users can launch without broad permissions; portfolios can be shared across accounts.
AWS Control Tower: account factory and guardrails for new accounts; Customizations for Control Tower or Account Factory for Terraform add your own setup.
Common traps
Deploying to each account by hand or with scripts. Use StackSets.
Self-managed permissions when the scenario asks for automatic deployment to new accounts. That needs service-managed.
Peering many VPCs when VPC sharing would let accounts use one network.
A regional bank uses AWS Organizations, with about 60 member accounts in a Workloads organizational unit (OU).
Every account in the OU must have the same CloudWatch alarms and an SNS topic for operations alerts, including accounts created in the future.
The team does not want to create or maintain IAM roles in each account for the deployment.
What should a CloudOps engineer do?
Choose one answer.
AA. Create a CloudFormation StackSet with self-managed permissions and add each new account to the stack set manually when it is created.
BB. Share one CloudFormation stack from the management account with the OU by using AWS Resource Access Manager.
CC. Deploy the alarms and topic with an AWS Config conformance pack, which applies to every account in the OU.
DD. Create a CloudFormation StackSet with service-managed permissions that targets the Workloads OU, with automatic deployment turned on for new accounts.
StackSets deploy one template to many accounts and Regions. With service-managed permissions, StackSets works through AWS Organizations, so no roles have to be built by hand, and automatic deployment keeps new accounts in the target OU covered. Self-managed permissions need roles and manual updates in each account.
A solar installer runs a central networking account that owns a VPC with private subnets, NAT gateways and a Direct Connect connection.
Application teams in other accounts in the same AWS Organization must launch their EC2 instances directly into those central subnets, while the networking team keeps sole control of routing.
Which approach should a CloudOps engineer use?
Choose one answer.
AA. Create a VPC peering connection from each application account's VPC to the central VPC.
BB. Deploy a copy of the VPC to every application account with a CloudFormation StackSet.
CC. Create IAM roles in the networking account that the application teams assume to launch instances there.
DD. Share the central subnets with the application accounts by using AWS Resource Access Manager.
Show the answer and explanation
Answer: D
A. Wrong: Peering connects separate VPCs, so instances would still launch into each team's own VPC. It also does not route traffic to the central NAT gateways or Direct Connect connection. Learn more: What is VPC peering? (opens in a new tab)
C. Wrong: This would put the application teams' instances in the networking account, mixing ownership and billing. It also gives them access to the networking account itself. Learn more: IAM roles (opens in a new tab)
VPC sharing uses AWS RAM to share subnets with other accounts in an organization. Participants launch their own resources into the shared subnets, while the owner manages the VPC, routes and gateways. Peering and per-account VPCs keep networks separate.
Want more on StackSets and resource sharing? The 5 full-length practice sets have 10 more StackSets and resource sharing questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →