1.4 - Multi-account governance and sharing (Organizations, SCPs, RAM, StackSets)
AWS Solutions Architect Professional objective 1.4 covers governing and sharing resources across an organization. You share a Transit Gateway and VPC subnets to application accounts with AWS RAM so they attach and launch without copying network resources, and you know Service Control Policies set the maximum permissions while identity policies must still grant access, with an explicit Deny in any SCP on the account's path overriding every Allow. CloudFormation StackSets with service-managed permissions deploy automatically to accounts newly added to a target OU, and IAM Identity Center federates an external IdP like Okta to assign permission sets across dozens of accounts. AWS Backup Vault Lock in compliance mode makes retention immutable even for root, tag policies standardize and report on tagging, an allow-list SCP with FullAWSAccess removed enforces default-deny, a Direct Connect gateway shares one link, and an organization trail plus IAM Access Analyzer cover audit. Expect scenarios about default-deny guardrails, automatic StackSet enrollment, or immutable backups, and ask which governance feature applies.
SCP caps permissions, never grants, and an explicit Deny in the path always wins. Auto-deploy to accounts added to an OU = StackSets with service-managed permissions. Immutable backups even root cannot delete = AWS Backup Vault Lock in compliance mode.
Practice questions
1. A company wants central governance so no member account, even its root user, can leave AWS Organizations or disable CloudTrail. Which control enforces this across all accounts?
- A permissions boundary attached to every IAM role in each member account
- A service control policy (SCP) applied at the organization root or OU (correct answer)
- An IAM identity-based policy pushed to each account by IAM Identity Center
- A resource-based policy on the organization CloudTrail trail bucket
SCPs set the maximum permissions for member accounts and even bound the root user, so denying leave-organization and cloudtrail:StopLogging at the root/OU blocks everyone. Permissions boundaries and identity policies do not constrain the root user, and a bucket policy cannot stop the trail itself.
2. A company wants a pre-built multi-account environment with a security OU, a centralized log-archive account, an audit account, and SSO via IAM Identity Center, deployed quickly to AWS best practices. Which service establishes this landing zone?
- AWS Control Tower (correct answer)
- AWS Organizations configured entirely by hand with custom SCPs and no baseline
- AWS Config aggregators deployed one by one into each account of the company
- A CloudFormation StackSet that builds every account and control from scratch
Control Tower orchestrates a best-practice landing zone: Organizations, a security OU, log-archive and audit accounts, IAM Identity Center, and guardrails, in a few clicks. Building it manually with Organizations, Config, or a StackSet reproduces the pieces but is slow, error-prone, and unmanaged.
3. In AWS Control Tower, which statement correctly maps guardrail types to the mechanism that enforces them?
- Preventive guardrails use SCPs; detective guardrails use AWS Config rules (correct answer)
- Preventive guardrails use AWS Config rules, and detective guardrails use SCPs applied at the organization root
- Both preventive and detective guardrails are implemented exclusively with service control policies attached per OU
- Both preventive and detective guardrails rely only on Amazon GuardDuty and AWS Security Hub findings
Preventive guardrails block disallowed actions using SCPs; detective guardrails continuously check for noncompliance using AWS Config rules. Swapping the two is wrong, and neither type is built solely on SCPs or on GuardDuty/Security Hub findings.
4. A platform team must automatically deploy custom baseline resources (IAM roles, VPC flow logs) and extra SCPs to every new and existing account governed by Control Tower, using their own CloudFormation. Which TWO approaches fit? (Choose TWO.)
- Use Customizations for AWS Control Tower (CfCT) tied to the account lifecycle (correct answer)
- Deploy the resources with service-managed StackSets targeting the org's OUs (correct answer)
- Manually run each CloudFormation template in the console of every account after Account Factory provisions it, then repeat for all future accounts
- Disable Control Tower and manage everything from one monolithic stack
CfCT wires custom CloudFormation templates and SCPs into the Control Tower account lifecycle so they apply to new and existing accounts. Service-managed StackSets targeting OUs auto-deploy to accounts as they join. Manual per-account console runs do not scale, and disabling Control Tower removes the governance you need.
5. Which Control Tower feature lets authorized users provision new AWS accounts through a standardized, pre-approved configuration (network baseline, guardrails) surfaced via Service Catalog?
- Account Factory (correct answer)
- A manually maintained runbook stored in the company's internal Confluence wiki
- The AWS Organizations CreateAccount API invoked directly by each requesting team
- IAM Identity Center permission sets assigned to the newly created account
Account Factory is the Control Tower capability, delivered through Service Catalog, that provisions new accounts with a standardized baseline and guardrails already applied. A runbook or a raw CreateAccount call skips the baseline, and permission sets grant access but do not provision accounts.
6. A networking account owns Transit Gateway and subnets that application accounts must attach to and deploy into, without copying network resources into each account. Which TWO Resource Access Manager actions enable this? (Choose TWO.)
- Share the Transit Gateway with the application accounts via RAM (correct answer)
- Grant each application account a full administrative role over the entire central networking account
- Recreate all of the subnets inside every application account using matching overlapping CIDR ranges
- Share the VPC subnets so application accounts launch resources into them (correct answer)
RAM shares specific resources across accounts: sharing the Transit Gateway lets application accounts create attachments, and sharing the subnets (VPC sharing) lets them launch instances directly into the central VPC, all owned by the networking account. Full admin access is excessive and insecure, and recreating subnets defeats centralized ownership and can create overlaps.