多帳戶策略：Organizations 與 Control Tower

AWS Organizations and AWS Control Tower are the two pillars of every modern multi-account strategy on AWS, and on SOA-C02 they sit squarely under Domain 4 Task Statement 4.1 — "implement secure multi-account strategies (for example, AWS Control Tower, AWS Organizations)". The wording is operational: implement, not architect. Where SAP-C02 (the Pro-tier solutions architect exam) tests the governance design angle — multi-level SCP intersection math, AI services opt-out, tag policies, AWS Resource Access Manager (RAM) sharing strategies, Account Factory for Terraform (AFT), and Customizations for Control Tower (CfCT) — SOA-C02 tests the running-the-system angle: onboarding a new account through Account Factory, debugging why an SCP blocked a developer's legitimate API call, switching on the organization trail, aggregating Config across the org, and reading the consolidated bill.

This guide walks AWS Organizations and Control Tower the way a SysOps engineer experiences them on a Tuesday morning: a developer has been denied an action by an SCP and you must trace which policy, an auditor wants every account's CloudTrail in one S3 bucket, a new team needs a sandbox account by tomorrow, the Control Tower dashboard says one OU is "drifted", and the finance team needs the September bill broken down by business unit. We will keep the framing tight and operator-focused, defer the Pro-tier governance architecture to its own discipline, and call out at every step which question shapes are SOA-C02 territory and which belong to SAA-C03 or SAP-C02.

Why Multi-Account Operations Sits in SOA-C02 Domain 4

The SOA-C02 Exam Guide v2.3 lists six skills under Task Statement 4.1, and three of them touch the multi-account world directly: "validate service control policies (SCPs) and permissions boundaries", "review AWS Trusted Advisor security checks", and "implement secure multi-account strategies (for example, AWS Control Tower, AWS Organizations)". Domain 4 is worth 16 percent of the SOA-C02 exam — about 8 to 11 of the 65 questions — and the multi-account topic typically supplies 3 to 5 of them.

The operator-tier framing matters because SAA-C03 barely covers AWS Organizations beyond a one-line acknowledgement, while SAP-C02 dedicates entire question chains to organization design (multi-level SCP intersection, where to attach allow-list versus deny-list policies, AI services opt-out, tag policies, backup policies, AWS RAM cross-account sharing patterns, AFT account vending pipelines, CfCT custom guardrails). SOA-C02 lives in the middle: you must know enough about Organizations to validate that an SCP is doing what its author intended, and enough about Control Tower to onboard a new account, monitor guardrail compliance, and react to drift — but you do not have to design a 200-account hierarchy from scratch. The exam consistently rewards candidates who can read an existing SCP and predict its operational effect over candidates who can write a new one from scratch.

白話文解釋 AWS Organizations and Control Tower

The Organizations and Control Tower jargon stacks fast — root, OU, SCP, guardrail, landing zone, Account Factory, drift, delegated admin. Three analogies make the constructs stick.

Analogy 1: The Corporate HQ With Branch Offices

AWS Organizations is the corporate headquarters that owns multiple branch offices (member accounts). The management account is the head office — it signs the lease, pays the consolidated electric bill (consolidated billing), prints the company-wide policy manual, and hires the regional managers. Member accounts are the branch offices where day-to-day work happens. Organizational Units are the regional groupings — North America OU, Europe OU, Asia-Pacific OU — each holding a cluster of branches. The root is the corporation itself, the legal entity that contains every region. Service Control Policies are the company-wide rulebooks posted on every branch office wall: "no one in any branch may sign contracts over $1M without HQ approval", "no one outside our approved regions may rent office space". An SCP does not give a branch manager the power to do anything new — local hiring authority (IAM permissions) does that — but it sets the absolute ceiling. The branch manager can do something only if both the company rulebook (SCP) and their local employment contract (IAM identity policy) permit it. Control Tower is the corporate franchise blueprint — when HQ opens a new branch, the franchise blueprint specifies the layout, the safety equipment, the standard signage, and the audit cameras (landing-zone baseline). Account Factory is the standard new-branch onboarding kit. Guardrails are the fixed rules in the franchise contract — preventive guardrails are physical locks on doors that should never open (SCP-backed), detective guardrails are cameras that record violations for later review (Config-rule-backed). Drift is when the local branch manager renovates without HQ approval — the safety inspector arrives and finds that the fire exit was sealed off, the signage replaced, or the audit camera removed.

Analogy 2: The Public Library System With Branches

AWS Organizations is the city library system. The central library (management account) sets the system-wide rules, signs the publisher contracts, and consolidates the budget. Branch libraries (member accounts) serve their local neighborhoods. OUs group the branches — Downtown Cluster, North Side Cluster, South Side Cluster. The system-wide membership rules (SCP) say things like "no branch may lend books outside the city without authorization" and "every branch must use the system-wide catalog". An individual librarian's job description (IAM policy) might allow them to issue library cards to anyone, but the system rule (SCP) caps it: only city residents. Both must agree for the action to happen. The system catalog (Service Catalog) is the pre-approved list of vendors, products, and configurations any branch may self-serve from. CloudTrail organization trail is the system-wide checkout log — every transaction at every branch flows into the central archive. Config aggregator is the system-wide inventory list — at any moment the central librarian can ask "show me every rare book across all branches and which are missing".

Analogy 3: The Manufacturing Group With Multiple Factory Sites

AWS Organizations is a manufacturing group with multiple factory sites (member accounts). The headquarters (management account) sets the safety standards, runs the corporate ERP, and consolidates the financials. Each factory site (member account) makes its own products. OUs group factories by product line — automotive OU, electronics OU, packaging OU. SCPs are the corporate safety standards — "no factory may operate without lockout-tagout procedures", "no factory may store hazardous chemicals above 5,000 liters". A site safety officer's daily authority (IAM policy) allows them to authorize a wide set of operations, but the corporate ceiling (SCP) clips it. Control Tower's Account Factory is the standard new-factory commissioning checklist — when a new factory opens, the commissioning team installs the same fire suppression system, the same ERP connection, the same audit logging. Preventive guardrails are the physical safety interlocks — you cannot start the machine without the safety guard in place. Detective guardrails are the routine inspection rounds — the inspector walks each line and notes deviations for next week's review. Drift is the moment the inspector arrives and finds someone bypassed an interlock or stopped logging maintenance — the factory is no longer compliant with corporate baseline. Delegated administrator is the regional safety manager — corporate has appointed one factory to run safety operations on behalf of the entire group, so HQ doesn't have to micromanage every plant.

Organizations Structure: Management Account, Member Accounts, OUs, and the Root

Before SCPs and Control Tower make sense, you need a precise mental model of the Organizations object hierarchy.

The management account

Every AWS Organizations organization has exactly one management account, formerly called the master account. The management account:

• Creates the organization with CreateOrganization and is the root payer for consolidated billing.
• Invites or creates member accounts.
• Attaches Service Control Policies, tag policies, backup policies, and AI services opt-out policies at the root, OUs, or specific accounts.
• Enables trusted access for AWS service integrations (CloudTrail, Config, Security Hub, GuardDuty, IAM Access Analyzer, RAM, Service Catalog, Backup, License Manager, Systems Manager, and more).
• Designates delegated administrators for specific services so day-to-day operation can move out of the management account.
• Is never subject to SCPs — the management account is exempt from organization SCP enforcement, even when an SCP is attached to the root.

The last point is the single most-tested SCP gotcha on SOA-C02 and is covered in detail in the Common Trap section below.

Member accounts

Every other account in the organization is a member account. Members:

• Inherit the SCPs and other policies attached to the root, to OUs along their path, and directly to themselves.
• Pay no bill of their own — all charges flow up to the management account through consolidated billing.
• Can leave the organization (with the management account's permission) and become standalone payer accounts again.
• Cannot perform organization-management API calls (organizations:* is denied at the org level except for read APIs the management account explicitly delegates).

Organizational Units (OUs)

An OU is a container inside the organization that holds accounts and/or other OUs. OUs are the structural mechanism for grouping accounts so the same policy applies to all of them in one attachment. Common OU patterns SOA-C02 candidates encounter in scenarios:

• Environment-based: Production, Staging, Development, Sandbox — different SCPs per environment.
• Workload-based: Workloads/Web, Workloads/Data, Workloads/AI — different service guardrails per workload type.
• Compliance-based: Regulated, NonRegulated, Quarantine — different region restrictions and data-residency SCPs.
• Lifecycle-based (Control Tower): Core, Custom, Sandbox, Suspended — Control Tower's recommended baseline OUs.

OUs can be nested up to five levels deep beneath the root. Nesting is rarely necessary in SOA-C02 scenarios; one or two levels is the usual depth.

The root

The root is the top-level container. It is automatically created when you create the organization. There is exactly one root per organization. SCPs attached to the root apply to every OU and every account beneath, except the management account.

SCP Basics: Allow-List vs Deny-List, NotAction Trap, and Evaluation Mechanics

Service Control Policies are the operational heartbeat of organization-level governance, and SOA-C02 tests them harder than any other Organizations construct.

What an SCP is — and is not

An SCP is a permissions ceiling, not a permissions grant. It defines the maximum set of API actions that any IAM principal (user, role, federated identity) inside a member account may perform. An action succeeds only if both an IAM identity policy (or resource policy) allows it and every applicable SCP along the path from the root to the account also allows it. SCPs cannot grant permissions; if no IAM policy permits the action, no SCP can change that.

The default state of any new organization is an SCP named FullAWSAccess attached at the root. FullAWSAccess allows *:* on *. Detaching it without attaching another permissive SCP locks every member account out of every API call — a famous operational disaster.

The FullAWSAccess SCP is the implicit "everything is allowed" baseline that ships with every new organization. The moment you detach it from the root or an OU without first attaching a replacement Allow SCP that covers the actions your workloads need, every IAM principal in every member account beneath that scope loses the ability to call any AWS API — including the very APIs the SysOps team would use to recover. The recovery path is to use the management account (which is not subject to SCPs) to re-attach FullAWSAccess or a permissive replacement. The SOA-C02 exam-correct rule: build deny-list SCPs that add explicit denies on top of FullAWSAccess, and treat any operation that detaches FullAWSAccess as a high-risk change requiring rollback rehearsal. Reference: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html ::

Allow-list versus deny-list strategy

Two SCP authoring strategies and SOA-C02 routinely tests both.

Deny-list strategy keeps FullAWSAccess attached at the root and adds explicit deny SCPs for actions you want to forbid. The mental model: "everything is allowed except X". This is the common operational style:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideApproved Regions",
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "StringNotEquals": { "aws:RequestedRegion": ["ap-southeast-1", "us-east-1"] }
    }
  }]
}

Allow-list strategy detaches FullAWSAccess and attaches an SCP whose Effect: Allow lists the explicit actions permitted. The mental model: "nothing is allowed except X". This is more restrictive and harder to maintain because every newly launched AWS service must be added to the allow-list. SAP-C02 tests allow-list scenarios more than SOA-C02; on the SysOps exam the allow-list pattern usually appears as a distractor for a problem that should have been solved with a targeted deny.

Evaluation logic

The SCP evaluation rules are precise:

1. An explicit Deny anywhere along the path — root SCP, OU SCP, account-level SCP — wins. The action is denied no matter what else allows it.
2. If there is no explicit Deny, the action must be explicitly Allowed by every SCP along the path. Both FullAWSAccess and any custom Allow SCP at each level count, and the intersection is what is permitted.
3. The result is then evaluated against the IAM identity policy (and the resource policy, where applicable). The action succeeds only if IAM also allows it.

The intersection rule is what makes multi-level SCPs powerful and confusing — and it is the chief governance design topic on SAP-C02. SOA-C02 keeps it simple: most operational scenarios use a deny-list with one or two explicit deny statements applied at the root or a single OU.

The NotAction trap

An SCP using NotAction with Effect: Deny sounds intuitive but is a classic trap. Deny + NotAction: [...] means "deny everything except the listed actions". Combined with Resource: *, this denies every API call in AWS except the ones in the list — including all the supporting APIs that the listed actions depend on. A SysOps engineer who writes this expecting "allow only these actions" is actually building a deny-everything-else policy that breaks all logging, IAM, billing, and tag operations the workload silently relies on.

The exam-correct mental rule:

• For deny-list SCPs, prefer Action (positive list of actions to deny). Avoid NotAction with Deny unless you are deliberately constructing a kill-list.
• For allow-list SCPs, use Effect: Allow with Action (positive list of actions to allow). Avoid NotAction with Allow unless you mean "allow everything except these".

Common SCP Operational Patterns on SOA-C02

The exam keeps returning to a small set of SCP patterns. Memorize the shape of each.

Restrict regions

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": { "aws:RequestedRegion": ["ap-southeast-1"] },
    "ArnNotLike": {
      "aws:PrincipalARN": "arn:aws:iam::*:role/OrganizationAccountAccessRole"
    }
  }
}

Add an exception list (StringNotEqualsIfExists with services like IAM, Organizations, CloudFront, Route 53, Support) because these are global services that report us-east-1 as their region and would break under a naive region-restriction SCP.

Require encryption at rest

{
  "Effect": "Deny",
  "Action": ["s3:PutObject"],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
  }
}

Prevent disabling security services

A standard pattern: deny cloudtrail:StopLogging, cloudtrail:DeleteTrail, config:DeleteConfigurationRecorder, config:StopConfigurationRecorder, guardduty:DeleteDetector, securityhub:DisableSecurityHub. Every member account becomes unable to turn off audit and security tooling.

Restrict instance types or services

Deny launching expensive instance families in development OUs, or deny entirely the use of services not yet vetted (e.g., iotcore:*, sagemaker:*).

Allowlist for workload accounts

In a strict allow-list strategy, an OU might receive an SCP allowing only ec2:*, s3:*, lambda:*, cloudwatch:*, logs:*, iam:Get*, sts:* — every other action is denied implicitly because there is no allow.

AWS Control Tower: The Landing Zone Bootstrap

Where AWS Organizations gives you raw multi-account primitives, AWS Control Tower wraps them in an opinionated, AWS-managed baseline called a landing zone. Control Tower is the service most multi-account environments use to avoid hand-rolling the same setup that every customer needs.

What Control Tower sets up

When you launch Control Tower in your management account, it provisions:

• A home region for the landing zone (the region where Control Tower itself runs and the audit/log archive accounts live).
• A Security OU containing two new accounts:
  • Log Archive account — receives the organization CloudTrail trail destination S3 bucket, the AWS Config delivery channel, and (optionally) other log destinations. By design no production workload runs here.
  • Audit account (also called the security tooling account) — the delegated admin account for Security Hub, GuardDuty, IAM Access Analyzer, and the cross-account IAM role used by security operators to audit member accounts.
• A Sandbox OU intended for Account Factory new-account vending until the operator builds out additional OUs.
• An organization CloudTrail trail that delivers all-region management events from every account to the Log Archive S3 bucket.
• An AWS Config recorder in every governed account and an aggregator in the Audit account.
• A baseline set of mandatory and strongly recommended guardrails attached at the OU level.
• A set of Control Tower-managed CloudFormation StackSets that maintain the above resources across every account and region.

Operational interactions a SysOps engineer has with Control Tower

After landing-zone setup, the SysOps engineer typically:

• Vends new accounts through Account Factory.
• Registers existing OUs so accounts under them become governed.
• Enrolls existing accounts that pre-date the landing zone.
• Enables additional guardrails (strongly recommended or elective) on specific OUs as compliance needs evolve.
• Adds governed regions (Control Tower must be told which regions to govern; out-of-scope regions are unmanaged).
• Reacts to drift — Control Tower flags drift via the dashboard and via EventBridge events on aws.controltower.

Account Factory: The Account Vending Mechanism

Account Factory is the Control Tower feature that provisions new member accounts with the landing-zone baseline pre-applied. SOA-C02 frequently tests the Account Factory operational flow.

What Account Factory does on CreateAccount

1. Creates a new AWS account through Organizations.
2. Places the account in the chosen OU (typically the Sandbox OU by default).
3. Applies the OU's SCP guardrails so the account inherits the policy ceiling.
4. Deploys the Control Tower baseline StackSet — Config recorder, Config rules for detective guardrails, organization CloudTrail member configuration, and other landing-zone resources.
5. Sets the account email to a unique address.
6. Attaches the AWSControlTowerExecution role so Control Tower can manage the account.
7. Optionally pre-creates a network — a VPC with default subnets — based on the Account Factory network configuration.
8. Creates an SSO user (or AWS IAM Identity Center user) with the chosen permission sets so a human can sign in.

Account Factory inputs

When vending an account through the Control Tower console, AWS Service Catalog, or the Account Factory API, you provide:

• Account name and email (must be a unique, deliverable email address).
• Target OU (must be a registered OU under Control Tower governance).
• SSO user details (email, first name, last name) for the initial sign-in identity.
• Optional account-level tags that flow into the consolidated billing chargeback path.

The blueprint-update gotcha

Account Factory uses a Service Catalog product behind the scenes. When you change the Account Factory network configuration or other blueprint settings, the change applies only to newly vended accounts. Existing accounts vended under the old blueprint are not auto-updated. The SysOps engineer must explicitly re-run the StackSet or update each account's resource manually if the change should affect existing accounts. SAP-C02 tests Account Factory for Terraform (AFT) and Customizations for Control Tower (CfCT) for richer blueprint-update workflows; SOA-C02 only requires that you know the basic blueprint-change-doesn't-auto-apply rule.

Guardrails: Preventive vs Detective, Mandatory vs Elective

Guardrails are the curated rules Control Tower offers as packaged compliance controls. Each guardrail has a category and a behavior.

Behavior: preventive vs detective

• Preventive guardrails are implemented as SCPs attached to the governed OU. They block the disallowed action at the API level. Examples: "disallow changes to CloudTrail", "disallow public read access to log archive bucket", "disallow deletion of organization trail".
• Detective guardrails are implemented as AWS Config rules evaluated continuously in each governed account. They flag non-compliant resources on the Control Tower dashboard but do not block the underlying API call. Examples: "detect whether MFA is enabled for root user", "detect whether EBS volumes are encrypted", "detect whether S3 buckets have public read access".

Category: mandatory, strongly recommended, elective

• Mandatory guardrails are always on, attached automatically when an OU is registered. They enforce the bedrock landing-zone protections (no disabling CloudTrail, no S3 public read on log archive, etc.).
• Strongly recommended guardrails are off by default but recommended; the operator enables them as the org matures.
• Elective guardrails are off by default and represent narrower or more situational controls.

Why preventive vs detective matters operationally

A preventive guardrail produces an AccessDenied error when an actor tries the disallowed action. The actor sees the failure immediately and the action never happens — but the SysOps team must respond to legitimate developers blocked by the SCP and either change the guardrail (rare) or change the developer's design (more common).

A detective guardrail produces a non-compliant finding on the Control Tower dashboard and emits a Config rule event. The disallowed state already exists when the finding fires; remediation happens after the fact through SSM Automation, Lambda, or human intervention. Detective guardrails compose well with Config auto-remediation.

Organizations Service Integrations: CloudTrail Org Trail, Config Aggregator, Security Hub, GuardDuty

Organizations becomes much more than a billing wrapper once you enable trusted access for AWS service integrations. SOA-C02 tests the four most commonly used integrations.

CloudTrail organization trail

An organization trail is a single trail created in the management account (or a delegated admin) that automatically applies to every member account, logs all-region management events, and delivers them to a single S3 bucket and (optionally) a single CloudWatch Logs group. Member accounts cannot disable, modify, or delete the organization trail — even with full account admin permissions — because it is enforced by the Organizations integration plus a preventive guardrail.

Two operational outcomes:

• One audit-of-record S3 bucket containing every API call across every account.
• A single delivery point for downstream tools (Security Hub, Splunk, Athena queries) instead of N per-account trails to stitch together.

The organization trail does not stop a member account from creating its own additional trail for application-specific logging. The org trail is the floor, not the ceiling.

AWS Config aggregator

A Config aggregator collects Config configuration item snapshots and rule evaluation results from every account in the organization (or a chosen subset of accounts and regions) into a single account. The aggregator account is typically the Audit account in a Control Tower landing zone. The aggregator does not record configurations itself; it relies on each member account having Config enabled and recording, and aggregates the results for centralized querying through the Config console, the API, or Athena.

SOA-C02 frequently asks "the security team needs a single inventory of all S3 buckets across 30 accounts" — the answer is the Config aggregator, not stitching together console screenshots.

Security Hub

Security Hub aggregates security findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, AWS Config, and many partner tools. With Organizations integration enabled, Security Hub is delegated to the Audit account, automatically enrolls every member account, and aggregates findings into a single dashboard with cross-account workflow.

GuardDuty

GuardDuty for Organizations follows the same pattern: enable trusted access, designate the Audit account as the GuardDuty delegated admin, and GuardDuty will auto-enable on every member account (existing and future). Findings flow to the delegated admin's GuardDuty console.

Delegated administration in general

Most security and operational services support delegated administration so that day-to-day operation does not have to live in the management account. The pattern: enable trusted access in Organizations, then call RegisterDelegatedAdministrator for a chosen member account. That account now manages the service across the organization while the management account stays out of the daily loop. SOA-C02 expects you to know this is the recommended pattern for Security Hub, GuardDuty, IAM Access Analyzer, Config, Backup, RAM, and Service Catalog among others.

Consolidated Billing Mechanics

Consolidated billing is the financial side of Organizations: one invoice for every account in the org, with cross-account benefit aggregation.

What rolls up

• Volume-tiered pricing (e.g., S3 storage tiers, data transfer tiers) aggregates across all accounts. If account A is in the first 50TB tier and account B is in the next 450TB tier, consolidated billing computes the org-wide tier first, then allocates the blended unit price back to each account.
• Reserved Instances and Savings Plans purchased in any account can apply to matching usage anywhere in the organization (subject to RI sharing being enabled at the management account level).
• AWS Free Tier allowances are pooled at the organization level — not multiplied per account.

What doesn't roll up automatically

• Service quotas are per-account. An organization with 50 accounts has 50 separate vCPU quotas, not a pooled one.
• IAM is per-account. There is no organization-wide IAM principal; the management account's users do not implicitly get any access in member accounts.
• Billing data per account is still visible to the management account, with cost allocation tags activated, for chargeback.

Cost allocation tags and AWS-generated tags

The management account activates cost allocation tags in the Billing console — both user-defined tags (e.g., CostCenter, Project, BusinessUnit) and AWS-generated tags (e.g., aws:createdBy). Activated tags appear as columns in Cost Explorer and the Cost and Usage Report (CUR), enabling chargeback by team or business unit. Tag activation has a 24-hour propagation delay before tags appear in cost data.

The CUR for advanced billing analysis

The Cost and Usage Report delivers granular billing data to S3 in CSV or Parquet format. With Organizations enabled, the management account receives a single org-wide CUR; each row carries the linked account ID and any active cost allocation tag. The standard analysis pattern is CUR -> S3 -> Athena query for "monthly NAT gateway spend by account" or "Aurora cost by environment".

Member Account Onboarding and Removal

Adding and removing member accounts is the operational lifecycle a SysOps engineer touches most often.

Onboarding paths

Three ways to bring an account into an organization:

1. Account Factory (Control Tower) — vends a new account, places it in a registered OU, applies the landing-zone baseline. Operationally the cleanest path; preferred for any new account the org creates.
2. CreateAccount API or Organizations console "Add account" — creates a raw new account directly via Organizations without Control Tower's baseline. Used in non-Control-Tower orgs.
3. InviteAccountToOrganization — invites an existing standalone AWS account to join. The invited account's owner must accept the invitation. Once accepted, the account becomes a member.

For an existing account that joins via invitation, Control Tower's Enroll Account feature applies the landing-zone baseline retroactively (with caveats — some pre-existing CloudTrail or Config setups must be reconciled before enrollment succeeds).

Removal paths

• Member account removal: the management account calls RemoveAccountFromOrganization. The removed account becomes a standalone account with its own payer relationship. The account must have completed standalone-account requirements (a contact phone, a billing payment method, etc.) before removal.
• Account closure: the account is shut down entirely via the AWS account closure flow. Closure has a 90-day post-closure recovery window before resources are permanently deleted.
• Suspending an account: not the same as removing; AWS Support can suspend an account for billing or compliance reasons, but the account stays in the organization until removed.

Cross-account roles for daily operations

Even after Organizations and Control Tower are set up, day-to-day operations require switching into member accounts. Two recurring SOA-C02 patterns:

• OrganizationAccountAccessRole — Account Factory and the Organizations CreateAccount API automatically create this role in the new account. It trusts the management account and grants AdministratorAccess. SysOps engineers sts:AssumeRole from the management account into the role for break-glass administration. The role is created only on accounts created through Organizations — invited accounts do not get it automatically and must create the role manually.
• AWSControlTowerExecution — created by Control Tower in every governed account. Trusted by Control Tower itself. Do not edit or remove it; doing so causes drift.
• AWS IAM Identity Center (formerly AWS SSO) — the modern, exam-favored cross-account access pattern. Permission sets defined in IAM Identity Center map to roles in each member account; users sign in once at the SSO portal and switch into accounts via the portal UI, with full audit through CloudTrail.

Scenario Pattern: Onboarding a new development team via Account Factory

A typical SOA-C02 scenario: "a new development team needs an isolated AWS environment with the company's standard guardrails, logging, and access controls — what is the operational sequence?"

1. The SysOps engineer signs into the management or delegated admin account.
2. Opens the Control Tower console -> Account Factory -> Create account.
3. Provides the account name (dev-team-acme), the unique email ([email protected]), the target OU (Sandbox or a registered Dev OU), and the SSO user details for the team lead.
4. Submits. Control Tower runs the Service Catalog product behind the scenes, creates the new AWS account through Organizations, places it in the OU, applies the OU's SCPs, deploys the baseline StackSet (Config recorder, organization trail member, default network if configured), and enrolls the SSO user with the chosen permission set.
5. The new account is ready — typically within 15 to 30 minutes — and the team lead receives an SSO invitation email.

Scenario Pattern: SCP blocks a developer's legitimate action — debug

The other canonical SOA-C02 scenario: "a developer cannot launch an EC2 instance in us-east-1 and gets an explicit-deny error — diagnose."

1. The SysOps engineer reads the developer's CloudTrail event in the member account: the errorCode is AccessDenied and the errorMessage mentions "with an explicit deny in a service control policy".
2. The engineer identifies which SCP fired by listing the SCPs attached to the account and to every parent OU and the root: aws organizations list-policies-for-target for each level.
3. The engineer reads each SCP and finds the region-restriction policy at the Production OU denying us-east-1.
4. Resolution depends on intent: if the policy is correct and the developer should not be using us-east-1, the developer must redeploy in ap-southeast-1. If the policy is wrong, the SysOps engineer adjusts the SCP after change-management approval. If the developer's account was placed in the wrong OU, the engineer moves the account to the correct OU.

The exam will ask which step is first; the operational answer is to read the CloudTrail error message — it tells you the SCP is the culprit before you waste time looking at IAM.

Common Trap: Control Tower Drift

Control Tower expects every guardrail SCP, every OU registration, and every baseline StackSet instance to remain exactly as Control Tower configured them. When something is changed outside Control Tower — an SCP edited directly in the Organizations console, an account moved manually between OUs, a guardrail SCP detached, a baseline resource deleted — Control Tower flags drift on its dashboard and emits an EventBridge event on aws.controltower.

Common drift causes:

• A SysOps engineer edits a guardrail SCP directly in the Organizations console to add an exception.
• An account is moved between OUs through the Organizations API rather than through Control Tower.
• A Control Tower-managed CloudFormation StackSet instance fails or is manually deleted.
• The Log Archive S3 bucket policy is modified.

Drift remediation depends on the cause: re-running landing-zone update from the Control Tower console fixes most managed-resource drift; OU drift is fixed by moving the account back through Control Tower; SCP drift is fixed by reverting the manual edit. Severe drift sometimes requires landing-zone version update or, in rare cases, Control Tower setup re-run.

Trusted Advisor Security Checks in the Multi-Account World

AWS Trusted Advisor runs a set of curated checks across an account and reports findings in five categories: cost optimization, performance, security, fault tolerance, and service limits. SOA-C02 Domain 4 explicitly tests the security checks.

The security checks SOA-C02 cares about

• Root account MFA: alarms if the root user does not have MFA enabled.
• IAM use: alarms if no IAM users exist (root-only operation is a finding).
• Exposed access keys: scans public sources for leaked AWS access keys associated with the account.
• S3 bucket public read access: lists buckets with public ACLs or bucket policies.
• Security groups — specific ports unrestricted: lists SGs with 0.0.0.0/0 on dangerous ports (22, 3389, 1433, etc.).
• CloudTrail logging: alarms if CloudTrail is not enabled in the account.

Multi-account Trusted Advisor

Trusted Advisor by itself runs per account. With AWS Support Business or Enterprise plan, the management account receives organization-level Trusted Advisor data through the Trusted Advisor Priority feature and the Support API. Without Business or Enterprise support, the free Trusted Advisor checks are limited to a small subset (generally five security and three service-limits checks). Many SOA-C02 questions hinge on the candidate knowing that full Trusted Advisor requires Business or Enterprise support.

Wiring Trusted Advisor into operational workflow

The SysOps team typically wires the Trusted Advisor Refresh Schedule and the Trusted Advisor EventBridge events into:

• An SNS topic for daily security findings summaries.
• A Lambda function that opens tickets for newly opened high-severity findings.
• A CloudWatch dashboard custom widget that shows the count of open security findings across the org.

AWS Service Catalog for Multi-Account Self-Service

AWS Service Catalog is the service that lets the SysOps team pre-approve a set of CloudFormation-templated products (a VPC, a hardened S3 bucket, an EC2 with the agent baked in) and publish them as a portfolio that developers in any member account can self-serve from. Service Catalog is the supported extension layer behind Control Tower's Account Factory: Account Factory products are themselves Service Catalog products in the management account.

Why SOA-C02 cares

The exam tests the operational pattern of giving teams a paved-road self-service rather than handing them admin keys: the SysOps engineer publishes a Service Catalog portfolio with the approved products, shares it across the organization through AWS RAM (Pro-tier territory) or Service Catalog's organization sharing, and developers launch products via Service Catalog without ever needing to write CloudFormation themselves. The combination is the "secure multi-account strategy" the exam guide phrase points at.

SOA vs SAA: Multi-Account on the Two Associate Exams

SAA-C03 and SOA-C02 treat AWS Organizations very differently. The headline: SAA-C03 hardly tests it.

The SAA candidate considers Organizations as a high-level cost benefit; the SOA candidate runs Organizations every week.

SOA vs SAP: Where the Pro-Tier Governance Lives

SAP-C02 (the Solutions Architect Professional exam) owns the multi-account governance design discipline. SOA-C02 deliberately stops at the operator boundary. The differences are stark and exam-relevant.

If a SOA-C02 question feels like it requires multi-level SCP arithmetic, AI opt-out, tag policies, or RAM sharing across the organization, you are reading a SAP-style distractor that has slipped into your study material — the actual SOA-C02 question is almost always a more direct operational debug or onboarding scenario. Stay grounded in the operator framing.

Common Trap Recap — Multi-Account Operations

Every SOA-C02 attempt will see two or three of these distractors.

Trap 1: SCPs apply to the management account

They do not. The management account is exempt from SCP enforcement no matter where the SCP is attached. Don't run workloads in the management account; rely on IAM, MFA, and CloudTrail monitoring there.

Trap 2: NotAction with Deny is an allow-list

It is the opposite of an allow-list. It denies every action except the listed ones. Use Action with Allow for an allow-list.

Trap 3: Account Factory blueprint changes apply to existing accounts

They do not. Blueprint changes apply only to newly vended accounts. Existing accounts must be updated through StackSets or manual remediation.

Trap 4: Direct edits to Control Tower-managed SCPs are safe

They are not. Direct edits cause drift and may be overwritten at the next landing-zone update. Use custom SCPs alongside the managed guardrails.

Trap 5: SCPs grant permissions

They do not. SCPs only cap permissions. An action requires both an SCP allow and an IAM allow.

Trap 6: An invited account gets the OrganizationAccountAccessRole automatically

It does not. The role is auto-created only on accounts created through CreateAccount (and Account Factory). Invited accounts must create the role manually.

Trap 7: Detective guardrails block actions

They do not. Detective guardrails only flag non-compliant resources after the fact. Use preventive guardrails when blocking is required.

Trap 8: Free-tier Trusted Advisor includes all security checks

It does not. Free-tier shows a limited subset; the full set requires AWS Support Business or Enterprise.

Trap 9: Cost allocation tags apply retroactively

They do not. Tag activation is forward-only and takes roughly 24 hours to propagate. Activate on day one.

Trap 10: Organization trail prevents per-account trails

It does not. Member accounts can still create their own trails for application-specific logging. The org trail is the floor, not the ceiling.

Decision Matrix — Multi-Account Construct for Each SysOps Goal

Use this lookup during the exam.

FAQ — AWS Organizations and Control Tower for SysOps

Q1: Why doesn't the SCP I attached at the root affect the management account?

By design, the management account is exempt from SCP enforcement no matter where the SCP is attached. AWS reasons that the management account is the entity that creates and operates the organization itself, and locking it out via its own SCPs would create unrecoverable failure modes (no one could remove the policy that locked them out). The operational implication is twofold: never run real workloads in the management account, and never rely on SCPs as the security control for the management account. Instead, treat the management account as a thin governance layer with a minimal break-glass IAM user set, MFA enforced, IAM Access Analyzer monitoring, and CloudTrail logging into the org trail. Place workloads only in member accounts where SCPs do apply.

Q2: An SCP with Effect: Deny and NotAction: ["s3:*"] — what does it actually do?

It denies every API call across every AWS service except S3 actions. That is almost never what the author intended. The phrase "deny everything except S3" reads like an allow-list ("only S3 is allowed"), but in SCP semantics it is a kill-list that blocks all the supporting actions a workload depends on — IAM, CloudTrail, CloudWatch, tagging, role assumption, billing, monitoring. The workload appears to work briefly, then fails in subtle ways. The exam-correct rule: prefer Effect: Deny with an explicit Action list (deny these specific things) for deny-lists, and Effect: Allow with an explicit Action list (allow these specific things) for allow-lists. Use NotAction only when you genuinely mean "everything except these" and you have audited the full set of side-effect APIs.

Q3: A developer is getting AccessDenied on ec2:RunInstances in us-east-1 — how do I trace it?

Read the CloudTrail event in the developer's account and look at the errorMessage. AWS includes specific text patterns: "with an explicit deny in a service control policy" means an SCP blocked the call, "with an explicit deny in an identity-based policy" means an IAM policy blocked it, "implicit deny" means no policy granted the action. For an SCP block, list every SCP along the path: account-level, parent OU, grandparent OU, ..., root. aws organizations list-policies-for-target --target-id <id> for each level. Read each SCP to find the offending statement — most commonly a region restriction or a service deny. Decide whether to (a) fix the developer's deployment region, (b) move the account to a different OU, or (c) adjust the SCP after change-management approval. The first step is always the CloudTrail error message; jumping to IAM debugging without reading it wastes time.

Q4: We changed the Account Factory network configuration and 30 existing accounts didn't update — is that expected?

Yes. Account Factory changes apply only to accounts vended after the change. The 30 existing accounts retain the network configuration they were vended with. To propagate the change, either (a) re-provision each account through the Account Factory product (operationally heavy and may not be acceptable), (b) deploy a separate CloudFormation StackSet to the existing accounts that updates the network resources, or (c) for Pro-tier organizations, use Customizations for Control Tower (CfCT) or Account Factory for Terraform (AFT) to manage the account baseline lifecycle. SOA-C02 expects you to know the limitation and recognize that StackSets is the SOA-tier propagation mechanism; CfCT and AFT are SAP-C02 territory.

Q5: How do preventive and detective guardrails differ in incident response?

A preventive guardrail is an SCP that blocks the disallowed action at the API layer. The actor sees an immediate AccessDenied, the action never happens, and the SysOps team's job is to either (a) accept that the developer must take a different approach or (b) adjust the guardrail (rare). A detective guardrail is an AWS Config rule that evaluates resource state continuously. The disallowed state already exists when the rule fires; the SysOps team's job is to remediate after the fact through SSM Automation, Lambda, or human intervention. Pick preventive when the action itself causes damage (disabling CloudTrail, deploying in a forbidden region, deleting a KMS key). Pick detective when the state is auditable and remediation can happen later (an unencrypted EBS volume, a public S3 bucket). Detective guardrails compose well with Config auto-remediation pipelines.

Q6: Why does Control Tower keep saying we are "drifted" even after we re-applied the configuration?

Drift means a resource Control Tower manages no longer matches the landing-zone definition. Common causes you may have missed: a guardrail SCP was edited directly in the Organizations console; an account was moved between OUs through the Organizations API rather than the Control Tower console; a Control Tower-managed CloudFormation StackSet instance failed in some accounts; or the Log Archive S3 bucket policy was modified. Reconciling drift requires fixing the original deviation: revert the SCP edit, move the account back through Control Tower, re-deploy the failed StackSet instance, or restore the bucket policy. Then re-run landing-zone update from the Control Tower console. If drift is severe and the landing zone version is outdated, AWS recommends a landing-zone version update which itself rebuilds the managed resources.

Q7: What is the practical difference between an organization trail and per-account trails?

An organization trail is created once in the management account (or a delegated admin) and automatically applies to every member account, present and future. Member accounts cannot disable, modify, or delete it — even with full account admin permissions — because the org trail is enforced by the Organizations integration plus a preventive guardrail. The result is one S3 bucket and one CloudWatch Logs group containing API events from every account. Per-account trails are created independently in each account and managed by that account's owner; they remain useful for application-specific logging or non-management-event capture. The two trails coexist; the organization trail is the audit-of-record floor, and per-account trails layer on top. SOA-C02 tests the org-trail pattern as the right answer to "auditor needs all API calls across all accounts in one place".

Q8: How do I designate a delegated administrator and why does it matter?

Delegated administration moves day-to-day operation of an integrated service out of the management account. The pattern: enable trusted access in Organizations for the service (e.g., aws organizations enable-aws-service-access --service-principal config.amazonaws.com), then call RegisterDelegatedAdministrator for a chosen member account. After registration, the delegated admin account can perform organization-wide operations of that service: view all members' findings, configure org-wide rules, manage member account enrollment. Why it matters: AWS guidance and the SOA-C02 exam answer is to keep the management account minimal — no human users for daily ops, no workloads. Delegating Security Hub, GuardDuty, IAM Access Analyzer, Config, Backup, and Service Catalog admin to a dedicated security tooling account (often the Audit account in a Control Tower landing zone) follows that principle. The management account becomes a thin governance layer, and the day-to-day work happens where compromise is less catastrophic.

Q9: Can a member account leave the organization on its own?

Not by default. Removal is initiated by the management account through RemoveAccountFromOrganization (or by the member account if the management account explicitly grants the necessary permission, which is unusual). Even when removal is initiated, the member account must satisfy standalone-account requirements first: a primary contact phone number, a billing payment method, agreement to standalone Customer Agreement terms. Without those, removal fails. In Control Tower environments, accounts must also be unenrolled through Control Tower before removal is allowed without breaking the landing zone. The operational answer for most "move an account out of the org" scenarios is to coordinate with both the member account owner and the management account, complete the standalone-account requirements, unenroll from Control Tower, then run RemoveAccountFromOrganization.

Q10: What is the right way to share AWS Reserved Instance and Savings Plan benefits across the org?

Consolidated billing automatically aggregates RI and Savings Plan benefits across every account in the organization, but only when RI sharing is enabled at the management account level (it is on by default; the management account or a member account can opt out at the account level if RI sharing must be restricted). With RI sharing on, an RI purchased in account A can apply to matching usage in account B if account A's matching usage is below the RI quantity. Savings Plans work the same way — an SP purchased anywhere applies to matching usage anywhere. The operational implication is that finance teams typically purchase RIs and SPs in the management account or a dedicated savings account so the benefits flow naturally to the rest of the org without manual reallocation. SOA-C02 tests the awareness that this aggregation exists and that opt-out is per-account.

Exam Signal: How to Recognize a Multi-Account Question

Multi-account questions on SOA-C02 follow predictable shapes.

• "AccessDenied with explicit deny in a service control policy" — the answer is to trace which SCP fired by listing policies on the account and parent OUs, then deciding whether to adjust the SCP, move the account, or change the developer's approach.
• "All accounts must have a uniform baseline" — the answer is Control Tower with Account Factory, plus appropriate guardrails on the OU.
• "Auditor needs all API calls across all accounts in one bucket" — the answer is the organization CloudTrail trail in the management or delegated admin account.
• "Security team needs a single inventory of resources across the org" — the answer is the Config aggregator, typically in the Audit account.
• "Restrict deployment to approved regions" — the answer is an SCP with aws:RequestedRegion deny condition, with global-service exceptions.
• "New team needs a sandbox account quickly" — the answer is Account Factory vending into the Sandbox OU.
• "Cost allocation across business units" — the answer is cost allocation tags activated in the Billing console plus Cost Explorer or CUR.
• "Drift on the Control Tower dashboard" — the answer is to identify what was changed outside Control Tower and either revert it or adopt a custom SCP/StackSet alongside.
• "Management account should not run workloads" — the answer is delegated administration plus a dedicated security tooling account, with workloads in member accounts only.
• "Per-account quota is being hit" — the answer is service quota request, not consolidated billing aggregation; quotas do not pool.

Further Reading and Related Operational Patterns

• What is AWS Organizations
• AWS Organizations Terminology and Concepts
• Service Control Policies (SCPs)
• SCP Evaluation Logic
• AWS Organizations Quotas
• AWS Service Integrations with Organizations
• What is AWS Control Tower
• Getting Started with AWS Control Tower
• AWS Control Tower Account Factory
• About Guardrails in AWS Control Tower
• Detect and Remediate Drift in Control Tower
• Creating a CloudTrail Trail for an Organization
• Multi-Account Multi-Region AWS Config Aggregation
• Security Hub with AWS Organizations
• Managing GuardDuty Accounts with AWS Organizations
• Consolidated Billing for AWS Organizations
• AWS Trusted Advisor
• AWS Service Catalog Administrator Guide
• AWS SOA-C02 Exam Guide v2.3 (PDF)

Once the multi-account foundation is in place, the next operational layers are: IAM Policies, MFA, SCPs, and Access Troubleshooting for the per-account permission diagnostics that complement org-level SCPs, CloudTrail and AWS Config for Audit and Compliance for the detection-and-remediation pipeline that flows into the organization trail and aggregator, CloudFormation Stacks and StackSets for the IaC mechanism that propagates baseline updates across the org, and Cost Visibility, Budgets, and Resource Rightsizing for the chargeback and budget-action flow built on top of consolidated billing.

• IAM Policies, MFA, SCPs, and Access Troubleshooting — SOA-C02 Study Notes
• CloudTrail and AWS Config for Audit and Compliance — SOA-C02 Study Notes
• CloudFormation Stacks, StackSets, and Troubleshooting — SOA-C02 Study Notes
• Cost Visibility, Budgets, and Resource Rightsizing — SOA-C02 Study Notes