AWS Organizations and Control Tower

AWS Organizations and multi-account strategy

Domain 6 begins one level above everything you have studied so far. Instead of one account, you now design many accounts that work as one company. An AWS account is the strongest isolation boundary in AWS: resources, IAM, quotas and bills are separate by default. AWS Organizations groups those accounts so you can bill them together and apply rules to all of them from one place.

Skill 6.1.1 asks you to deploy and configure an organization. The exam tests three ideas: enable all features, design OUs by function and control needs, and keep the management account almost empty.

Recommended OUs

The AWS guidance “Organizing your AWS environment using multiple accounts” suggests foundational OUs: Security (Log Archive and security tooling accounts), Infrastructure (networking and shared services), then Workloads split into Prod and Non-prod (SDLC) OUs, plus Sandbox, Suspended and a Policy Staging OU to test new policies before you attach them to production. Accounts with the same controls should sit in the same OU, so one policy attachment covers them all.

$ aws organizations create-organizational-unit \
    --parent-id r-a1b2 --name Workloads-Prod
{ "OrganizationalUnit": { "Id": "ou-a1b2-prod1234",
    "Arn": "arn:aws:organizations::111111111111:ou/o-exampleorg/ou-a1b2-prod1234",
    "Name": "Workloads-Prod" } }

$ aws organizations move-account --account-id 222233334444 \
    --source-parent-id r-a1b2 --destination-parent-id ou-a1b2-prod1234

AWS Control Tower landing zone

Building a good organization by hand takes weeks: shared logging, a security account, baseline roles, guardrails and a way to create new accounts. AWS Control Tower automates this on top of Organizations. Skill 6.1.2 asks you to use it both in a new environment and in an existing organization that already has accounts.

Existing environments: register and enroll

In an organization that already exists, set up the landing zone first. Then register an OU to bring it under governance; Control Tower enrolls the accounts in it. You can also enroll one account at a time. Before enrolling, check each account: no conflicting AWS Config recorder or delivery channel, the AWSControlTowerExecution role present (for invited accounts), and delete old account-level trails to avoid paying twice, because the organization trail now covers them. Enrollment deploys baseline StackSets, turns on AWS Config, adds detective control rules and moves the account into the OU. Enrolled accounts keep their existing VPCs.

$ aws configservice describe-configuration-recorders
{ "ConfigurationRecorders": [ { "name": "default",
    "roleARN": "arn:aws:iam::222233334444:role/aws-service-role/config.amazonaws.com/..." } ] }

$ aws configservice describe-delivery-channels
{ "DeliveryChannels": [ { "name": "default", "s3BucketName": "old-config-bucket" } ] }

# Either remove them, or follow the documented steps for
# enrolling accounts that have existing AWS Config resources.

Control Tower controls and Account Factory

A control (formerly “guardrail”) is a plain-language rule that Control Tower applies to an OU, such as “disallow public read access to S3 buckets”. The exam wants you to pick the right behavior: stop it, find it, or block it in the template. It also asks how to create new accounts that are governed from day one.

Account Factory, AFC and AFT

Account Factory creates new accounts that are enrolled and baselined automatically. It is a product in AWS Service Catalog, so you can use the console or let users request accounts. Account Factory Customization (AFC) adds blueprints (CloudFormation or Terraform) that run when an account is created. Account Factory for Terraform (AFT) is a GitOps pipeline: you add an account request file to a repository, git push, and AFT creates the account and applies global and account-specific customizations. AFT runs in its own AFT management account, separate from the Control Tower management account, and supports CodeCommit or other Git providers through CodeConnections.

$ aws controltower enable-control \
    --control-identifier arn:aws:controlcatalog:::control/EXAMPLEID \
    --target-identifier arn:aws:organizations::111111111111:ou/o-exampleorg/ou-a1b2-prod1234
{ "operationIdentifier": "0f6b3a2e-...-example",
  "arn": "arn:aws:controltower:us-east-1:111111111111:enabledcontrol/EXAMPLE" }

$ aws controltower get-control-operation \
    --operation-identifier 0f6b3a2e-...-example
{ "controlOperation": { "operationType": "ENABLE_CONTROL", "status": "SUCCEEDED" } }

Organization policies: which one when

IAM Day 2 covered how policies are evaluated. Today the question is design: which organization policy type fits the requirement, and where to attach it. Skill 6.1.3 names SCPs, RCPs, AI services opt-out policies and declarative policies. Tag and backup policies also come up.

Declarative, AI opt-out, tag and backup policies

Declarative policies set a baseline configuration for a service, enforced in its control plane, so it still holds when the service adds new APIs, when new accounts join, and for service-linked roles. EC2 attributes include VPC Block Public Access, VPC Encryption Controls, serial console access, image (AMI) block public access, Allowed Images, instance metadata defaults (IMDSv2) and EBS snapshot block public access. You can add a custom error message, and an account status report shows current settings. If you detach the policy, the setting returns to its previous state. AI services opt-out policies stop AWS AI services from storing and using your content to improve the service, including model training, in all accounts and Regions; opting out also deletes stored copies. Use the default key to opt out of all supported services. Tag policies standardize tag keys and values (Day 2 goes deeper) and backup policies deploy AWS Backup plans to accounts.

{ "ec2_attributes": {
    "instance_metadata_defaults": {
      "http_tokens":                 { "@@assign": "required" },
      "http_put_response_hop_limit": { "@@assign": "2" },
      "http_tokens_enforced":        { "@@assign": "enabled" } },
    "snapshot_block_public_access": {
      "state": { "@@assign": "block_all_sharing" } },
    "image_block_public_access": {
      "state": { "@@assign": "block_new_sharing" } },
    "exception_message": {
      "@@assign": "Blocked by org baseline. See https://wiki.example.com/ec2" } } }

Delegated administrators for security services

Security services such as GuardDuty and Security Hub need to see every account. You could run them from the management account, but that breaks the rule of keeping it nearly empty. Skill 6.1.4 is about the right pattern: register a delegated administrator, usually a dedicated security tooling account (in Control Tower, often the Audit account).

$ aws organizations enable-aws-service-access \
    --service-principal guardduty.amazonaws.com
$ aws guardduty enable-organization-admin-account \
    --admin-account-id 333344445555

# In the delegated admin (333344445555), for each Region:
$ aws guardduty update-organization-configuration \
    --detector-id 12abc34d567e8fa901bc2d34eexample \
    --auto-enable-organization-members ALL

$ aws organizations list-delegated-administrators \
    --query "DelegatedAdministrators[].{Id:Id,Name:Name}"
[ { "Id": "333344445555", "Name": "security-tooling" } ]

Root user: centralized root access, MFA and break-glass

Every AWS account has a root user that can do anything, and SCPs can limit it in member accounts but not in the management account. Skill 6.1.5 asks how to manage root credentials at scale. The modern answer is centralized root access for member accounts, MFA everywhere, and a tested break-glass procedure for the management account.

MFA and break-glass

AWS now requires MFA for the root user of all account types (standalone, management and member); users must register MFA within 35 days of their first console sign-in attempt if it isn’t set up. AWS recommends passkeys or security keys because they resist phishing, and you can register more than one MFA device. Accounts whose root credentials were deleted through centralized root access don’t need root MFA at all. A break-glass procedure is the documented emergency path when normal access fails (for example IAM Identity Center or the identity provider is down): a few emergency IAM roles or users in a dedicated account, or the management account root, with credentials split and stored in a safe or vault, MFA held by different people, CloudWatch/EventBridge alarms on every use, and a regular test. After use, rotate the credentials and review CloudTrail.

$ aws sts assume-root --region eu-west-1 \
    --target-principal 222233334444 \
    --task-policy-arn arn=arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy \
    --duration-seconds 900
{ "Credentials": { "AccessKeyId": "ASIA...", "SecretAccessKey": "...",
    "SessionToken": "...", "Expiration": "2026-10-10T09:15:00Z" },
  "SourceIdentity": "..." }

# With those credentials:
$ aws s3api delete-bucket-policy --bucket locked-reports-bucket

Cheatsheet extras: shared responsibility, security basics and SCP inheritance

Your cheat sheet opens with “Security 101”: the shared responsibility model, the CIA and AAA ideas, and how AWS secures its own side. Domain 6 is called Security Foundations and Governance, so these basics still appear in questions, usually hidden inside a scenario (“who must patch this?”, “which service gives non-repudiation?”). This section also adds the SCP inheritance rules the cheat sheet stresses, updated for 2025.

Security basics: CIA, AAA and non-repudiation mapped to AWS

AWS’s own side, which you inherit: physical security of data centers, disk destruction when decommissioned, separation of the Amazon.com corporate network from AWS, staff access through bastions with regular access reviews, formal change management, secure design reviews and penetration testing of AWS software. You can’t audit these yourself; you read AWS’s reports in AWS Artifact (Day 3).

SCP inheritance, deny lists and allow lists

The cheat sheet says SCPs are “a filter”. Here is exactly how the filter works. For an action to be allowed in a member account, an SCP must allow it at every level from the root down: the root, each OU on the path, and the account itself. A deny at any level wins, and nothing lower can add the action back.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideApprovedRegions",
    "Effect": "Deny",
    "NotAction": [ "iam:*", "organizations:*", "sts:*", "support:*",
                   "cloudfront:*", "route53:*", "waf:*", "budgets:*" ],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": { "aws:RequestedRegion": [ "eu-west-1", "eu-central-1" ] },
      "ArnNotLike": { "aws:PrincipalARN": "arn:aws:iam::*:role/BreakGlassAdmin" }
    }
  }]
}

Lecture summary map

Day 1 of Domain 6 on one screen.

1. Mind map

2. Match the requirement to the control

3. “If the question says… pick…”

Must-remember cheat sheet

Core quiz

Check the basics first. Pick an answer, then press Check.

Hard quiz

Harder than most real exam questions on purpose, with one “choose two” and one matching question. Aim for 9 out of 12 before Day 2.

Practice test questions (from your mock exams)

Nine questions about Organizations, SCPs and the root user. These questions come from your own mock exams in the practice tests folder, matched to this lecture. Each one was checked against current AWS behavior, so some wording and answers are updated; the source is shown at the end of each explanation. Questions marked (New) were written in October 2026 for exam-guide skills or AWS changes that the mocks don’t cover.

Hands-on lab (30 minutes, low cost)

Use a personal test organization, never a company one. Organizations, SCPs, RCPs and declarative policies are free.

1. In a test management account, create an organization with all features. Create OUs Sandbox and Suspended, and create one member account into Sandbox (it needs its own unique email address).
2. Enable SCPs and attach an SCP to Sandbox that denies organizations:LeaveOrganization and all Regions except one (aws:RequestedRegion). Use OrganizationAccountAccessRole to switch into the member and try to create something in another Region: you should get AccessDenied.
3. Enable RCPs and look at RCPFullAWSAccess on every target. Attach an RCP to Sandbox that denies s3:* unless aws:PrincipalOrgID is your organization (keep an exception for AWS service principals). Read the effective policy for the account.
4. Enable declarative policies for EC2 and attach one that sets image block public access and snapshot block public access to block_new_sharing. Open the account status report.
5. In IAM, open Root access management, enable it, and run the IAMAuditRootUserCredentials task on the member account. Notice that the new account has no root credentials.
6. Read, but don’t deploy, the Control Tower setup page: a landing zone creates extra accounts and AWS Config and CloudTrail resources that cost money.
7. Clean up: detach and delete the policies, move the member account to Suspended and close it (closed accounts stay visible for a while before they are removed), then delete the OUs. Don’t leave AWS Config or GuardDuty running in test accounts: they bill per resource or per event.