AWS Organizations, SCPs, and Control Tower: Multi-Account Security Strategy

Every other boundary in AWS — IAM policies, VPCs, resource policies — operates inside an account and can be misconfigured from inside it. The account boundary is different: by default, no principal in one account can touch anything in another account unless both sides explicitly agree (a resource policy on one side, an identity policy or assumed role on the other). That default-deny property is why the exam treats "put it in a separate account" as a security answer, not just an organizational one.

Separate accounts contain blast radius. If an application account is compromised, the attacker's credentials are worthless against the log-archive account. Separate accounts also give you clean service quotas, clean billing lines, and — most importantly for this domain — a clean place to attach organization policies: SCPs, RCPs, and management policies attach to accounts and OUs, so your account structure is your policy structure.

This thinking is formalized as a landing zone: a pre-configured, secure, multi-account environment with identity, logging, and guardrails established before the first workload lands. You can hand-build one with AWS Organizations, or let AWS Control Tower build and operate one for you (covered below). Either way, the exam expects you to reason about where a workload lives before what IAM policy it gets. When a scenario says "limit the impact of a compromised environment" or "isolate the security team's tooling from application teams," the specialty-level answer starts with account separation, then adds the finer-grained controls inside it. Account-level isolation is the control that keeps working even when everything inside the account is misconfigured.

AWS's published guidance for organizing an environment converges on a recognizable OU layout, and exam scenarios are written against it:

• Security OU — the accounts your security team owns. The two canonical members: the log-archive account, holding the S3 buckets that receive organization-wide CloudTrail logs, AWS Config history, and VPC Flow Logs — write-once storage that workload teams and even most administrators cannot alter; and the audit account (also called the security-tooling account), where delegated administration for GuardDuty, Security Hub, Detective, Macie, and Inspector lives, and where security analysts hold their cross-account read roles.
• Workloads OU — production and non-production application accounts, often split into Prod and SDLC child OUs so production-only guardrails can attach at the OU level.
• Sandbox OU — experimentation accounts with no path to production data, typically fenced by the most restrictive SCPs (Region limits, service allow-lists, spend controls).
• Suspended OU — a quarantine parking spot. Moving a compromised or decommissioned account here instantly applies a deny-almost-everything SCP without touching anything inside the account.

Two design rules follow. First, group accounts by function and policy needs, not by org chart — OUs exist so policies inherit sensibly. Second, keep the Security OU's accounts free of workloads: the log archive stores evidence, the audit account runs tooling, and neither runs applications. When a question asks where organization CloudTrail logs should be delivered, the answer is a dedicated log-archive account in the Security OU — never the management account.

The management account is the most dangerous account in your organization, for one documented reason: SCPs do not apply to the management account. No guardrail you write can constrain it. It also controls billing, can close member accounts, and owns the organization itself. The discipline the exam expects: run no workloads in it, allow almost no human access to it, and move every function that can be moved out of it.

The mechanism for moving functions out is delegated administration. Security services integrate with Organizations through trusted access (enabling the service to operate across the organization), and most then let you register a member account as the delegated administrator — the account from which the service is centrally managed. GuardDuty, Security Hub, AWS Config, Macie, Inspector, Detective, IAM Access Analyzer, and Firewall Manager all support this, and the standard pattern is to delegate them to the audit account. The result: security operations never require logging in to the management account, and findings from every member account aggregate in one place the security team owns.

CloudTrail deserves its own mention. An organization trail logs events from the management account and every member account into one S3 bucket — in the log-archive account — and member accounts can see but cannot modify or delete the trail. That property is the exam trigger: when a scenario needs API logging that individual account administrators cannot switch off, the answer is an organization trail, usually reinforced by an SCP denying cloudtrail:StopLogging and cloudtrail:DeleteTrail.

Service control policies define the maximum available permissions for member accounts. Three properties are tested constantly: SCPs never grant permissions (a principal still needs an IAM policy); they apply to every principal in affected accounts including the root user; and they do not apply to the management account. Effective permissions are the intersection of the SCPs at every level above the account — organization root, each OU in the chain, then the account — with the identity policy evaluated inside that boundary.

The guardrail patterns worth memorizing:

• Region deny — deny all actions when aws:RequestedRegion is outside your approved list, with documented exemptions for global services.
• Root-user deny — deny actions when aws:PrincipalArn matches the root user, forcing all work through IAM roles.
• Protect security tooling — deny cloudtrail:StopLogging, cloudtrail:DeleteTrail, guardduty:DeleteDetector, guardduty:DisassociateFromMasterAccount, config:StopConfigurationRecorder, and config:DeleteConfigurationRecorder so no member account can blind the organization.
• Deny leaving — deny organizations:LeaveOrganization so a compromised account cannot escape its guardrails.
• Deny unencrypted uploads — deny s3:PutObject when the request lacks the expected s3:x-amz-server-side-encryption value.

Strategy: every organization starts with FullAWSAccess attached everywhere, and most stay in a deny-list posture — keep FullAWSAccess, layer targeted Deny statements on top. An allow-list posture (detach FullAWSAccess, explicitly allow only approved services) is tighter but brittle; it fits sandbox OUs and highly regulated enclaves. Full policy-evaluation mechanics belong to Domain 4 — here, know the intersection rule and the exemptions cold.

SCPs constrain your principals; resource control policies (RCPs) constrain access to your resources. An RCP attaches at the root, OU, or account and sets the maximum available permissions on resources in member accounts — regardless of who is calling, including external principals from accounts you don't own. That is the gap SCPs cannot close: an SCP cannot stop an outside attacker from using a mis-shared bucket, because the attacker's principal isn't in your organization. RCPs apply to a documented set of services — Amazon S3, AWS STS, AWS KMS, Amazon SQS, and AWS Secrets Manager — and, like SCPs, never grant anything and do not apply to the management account.

The flagship pattern is the resource perimeter: an RCP that denies access to organization resources unless aws:PrincipalOrgID equals your organization ID, so even a resource policy that mistakenly grants Principal: "*" cannot expose data outside the org. The companion key aws:ResourceOrgID works the other direction — used in SCPs or identity policies to stop your principals writing data to resources outside your organization.

Two management policy types round out Task 6.1. Declarative policies enforce a desired service configuration at the account level — for example, blocking public sharing of AMIs or EBS snapshots — and the configuration cannot be changed from inside member accounts. AI services opt-out policies let you opt every account out of having its content used to improve AWS AI services — a standing compliance question in regulated industries. Tag policies, the fourth type, are covered with deployment governance in Task 6.2.

Exam questions rarely ask you to recite a policy type — they describe an outcome and make you pick the control. Use this chooser:

The discriminator is the verb. "Prevent," "block," "ensure it is impossible" → a preventive control; then ask who is being constrained — your principals (SCP), any caller against your resources (RCP), or a service setting (declarative policy). "Detect," "audit," "report," "remediate" → AWS Config, which is Task 6.3's territory. A wrong-but-tempting distractor is offering an IAM permissions boundary for an org-wide requirement — boundaries are per-principal, per-account artifacts, not organization guardrails.

Everything so far you can assemble by hand. AWS Control Tower assembles it for you: it orchestrates AWS Organizations, IAM Identity Center, CloudTrail, and AWS Config into a managed landing zone — creating the Security OU with the log-archive and audit accounts, enabling organization-wide logging, and applying a baseline of controls. Control Tower is not a separate policy engine; it is an opinionated operator of the services you have just learned. It can be enabled in a new environment or an existing organization, and existing accounts can be enrolled into its governance.

Its controls (historically "guardrails") come in three types, and mapping them to their implementation is a reliable exam question:

• Preventive — implemented as SCPs; stop noncompliant actions from happening (e.g., disallow changes to the CloudTrail configuration Control Tower manages).
• Detective — implemented as AWS Config rules; find noncompliant resources after they exist and surface them on the Control Tower dashboard.
• Proactive — implemented as CloudFormation hooks; evaluate resources during provisioning, before they are created, blocking noncompliant infrastructure-as-code deployments.

Controls are mandatory, strongly recommended, or elective, and you enable optional and custom controls per OU. Account Factory is the account-vending machine: new accounts are created pre-enrolled, landing in the right OU with baselines and controls already applied — the governance answer to account sprawl. Choose plain Organizations when a scenario emphasizes bespoke policy control with minimal managed tooling; choose Control Tower when it emphasizes a standardized, quickly established, continuously governed landing zone.

Two identity planes remain. For the workforce, IAM Identity Center is the standard: users and groups (sourced from your IdP) are assigned permission sets, which Identity Center materializes as IAM roles in each target account. No per-account IAM users, no long-term keys, one place to revoke access. For the root user, centralized root access management lets you manage member-account root credentials from the organization level — removing root passwords from member accounts entirely so there is nothing to phish, while still permitting short-lived, task-scoped privileged root sessions for the rare actions that require root (such as deleting a misconfigured S3 bucket policy). Where root credentials must exist, they get MFA and a break-glass procedure: sealed credentials, an alarmed usage path (CloudTrail root-login alerts), and a documented post-use rotation.

Walkthrough. A regulated financial-services company gives you requirements: workloads isolated per environment, logs tamper-proof for seven years, no data-plane activity outside two approved Regions, security tooling that application admins cannot disable, and standardized new accounts. You map each requirement to this lesson: Control Tower landing zone with Security, Workloads (Prod/SDLC), Sandbox, and Suspended OUs; organization CloudTrail delivering to the log-archive account's locked-down bucket; a Region-deny SCP on the organization root (management account documented as exempt, so it stays workload-free and access-restricted); the protect-security-tooling SCP set; GuardDuty, Security Hub, Config, Macie, and Inspector delegated to the audit account; an RCP perimeter on S3; Identity Center for all human access; root centrally removed with a break-glass exception. Every element is the canonical Task 6.1 answer to its requirement.