Day 5 - Week 2 Integration: When Organizations, SCPs, CT, and IDC Meet in a Single Scenario

On the Pro exam, the core four of Domain 1 (Design for Organizational Complexity, 26%) are Organizations, SCPs, Control Tower, and IAM Identity Center. If you studied these four separately over the week, today we seriously work through Pro questions where they operate simultaneously in one scenario.

Domain 1 is hard not because of single-service knowledge but because the layers are stacked on top of each other in the questions. Even a single "the Region restriction isn't working" problem can entangle an SCP NotAction exception, OU inheritance, an IDC Permission Set's inline policy, and an RCP's blocking of external principals all at once. So today, rather than re-explaining each service, we look at what blast radius one service's decision causes in the others.

The structure of today's article is the same as Week 1 Day 5.

1. 30 one-line summaries for Week 2: facts that should come to mind reflexively in the exam room.
2. The multi-account 4-layer thinking method: decompose a scenario as Org → OU → SCP → IDC.
3. The history and theoretical background of account separation: why "one big account" is an anti-pattern.
4. Comparison with other clouds: contrast with Azure Management Groups and GCP Organization.
5. 12 scenario questions: Pro difficulty, 30 minutes to solve.

Domain 1 is an area that SAA barely touched, so it has the highest study ROI. The intent of the 16-week curriculum is to concentrate on this area through Week 4 and move on to new solutions and migration from Week 5.

The History and Theory of Multi-Account Governance

AWS Organizations became GA in February 2017. Before that there was only Consolidated Billing (2010), which bundled only billing, and permission governance was left to each account. SCPs appeared together with Organizations and elevated multi-account from a "cost bundle" to a "governance unit." Control Tower (Landing Zone automation) in 2019 and AWS SSO (now IAM Identity Center) in 2018 came out in turn, completing today's stack. In other words, the four of Domain 1 are layers that accumulated gradually over 7 to 8 years, and the Pro exam looks at the picture of these layers "working together."

Why should you not run a company in a single giant AWS account? The core is the blast radius and the isolation boundary.

In distributed systems reliability theory there is the concept of a fault containment region (FCR). It is a design that divides a system with boundaries so that one fault cannot propagate to other areas. An AWS account is the strongest FCR in the cloud - IAM policy mistakes, resource quotas, and security breaches cannot cross the account boundary. VPC and IAM boundaries are "weak" boundaries within the same account, but the account boundary is a "strong" boundary separated at the AWS backbone level. This is the theoretical basis for "always separate Prod and Non-Prod into different accounts."

Multi-account design enforces the security principle of least privilege and separation of duties (SoD) through structure. SoD is a control principle handed down since the 1970s in accounting and auditing, codified in NIST SP 800-53 AC-5. Splitting the account that stores logs (Log Archive) from the account that analyzes them (Audit), and not putting workloads in the Management account that only handles billing, are both cloud implementations of SoD.

Capital One (July 2019) - through an SSRF vulnerability, credentials of an over-privileged IAM Role were stolen from EC2 metadata, and data on 106 million people was leaked. The direct causes were the WAF configuration and excessive S3 access permissions, but the post-incident analysis pointed out that "the data account and the application account were not separated enough, so one Role could access too many buckets." Lesson: if you divide account and Role boundaries narrowly, the blast radius is limited even if one credential is stolen. After this incident, AWS released IMDSv2 (2019) and strongly recommended account separation in the SRA (Security Reference Architecture).

Multi-Account and Organization Governance in Other Clouds

The Pro exam asks only about AWS, but comparing concepts makes the essence clear.

The biggest structural difference is that in AWS the account is a first-class isolation boundary with "separate billing, separate quotas, and a separate resource namespace." Azure's Subscription is similar, but in Azure, Entra ID natively manages identity across the entire tenant, so a separate integration layer like IDC is less needed. GCP's Project is the lightest and easiest to create, so a "project per resource" pattern is common. If an SCP in AWS is a "default-deny ceiling attached to an OU," Azure Policy is an "audit/deny rule that evaluates resource properties," so the evaluation model itself differs - Azure Policy is closer to a Config Rule (Detective) than to an SCP.

30 One-Line Summaries for Week 2

Organizations (1-8)

1. The 4 motives for multi-account: isolation (blast radius), billing, regulation, operations.
2. The Management account is for billing and Org administration only, no workloads. SCPs do not apply.
3. The Management root gets a hardware MFA + a sealed password + a separate email alias.
4. An OU is a "unit of common SCPs," not an org chart. SRA standard: Security/Infrastructure/Workloads/Sandbox.
5. Always separate Prod/Non-Prod into different accounts - the same IAM policy mistake threatens Prod.
6. PCI/HIPAA/SOX workloads go in separate accounts - to narrow audit scope.
7. The CreateAccount API is asynchronous. You need to poll with DescribeCreateAccountStatus.
8. Delegate security tools to the Audit account with Trusted Access + Delegated Administrator.

SCP (9-16)

9. SCPs do not grant permissions, they only set a ceiling. Intersection with IAM policies.
10. An explicit Deny beats every Allow. Just one is enough.
11. The deny-list strategy is the standard (FullAWSAccess + specific Denies). New services are automatically allowed.
12. A Region-restriction SCP must have a NotAction exception for global services (IAM, Org, Route53, CloudFront, GA, WAF).
13. SCPs that block disabling CloudTrail, GuardDuty, and Config are standard baseline.
14. When enforcing MFA, use BoolIfExists (Bool does not match when the key is absent).
15. Validate in a PolicyStaging OU before attaching to the real OU - effectively a substitute for a dry run.
16. RCP (2024) is a resource-side restriction that blocks external exposure across an entire OU.

Control Tower (17-22)

17. Landing Zone = the reference point of multi-account governance, and Control Tower builds it automatically in 1 hour.
18. Core OU = Log Archive + Audit. The Log Archive S3 uses Object Lock (WORM).
19. Three guardrail types: Preventive (SCP) / Detective (Config) / Proactive (CFN Hook) - defense in depth.
20. Mandatory (cannot be disabled) / Strongly Recommended / Elective.
21. AFT = Terraform GitOps, CfCT = CloudFormation extension, Account Factory = console standard.
22. Drift Detection compares against the baseline every hour, and a Landing Zone Update restores it.

IAM Identity Center (23-30)

23. The multi-account SSO standard. Free.
24. When mapping a Permission Set, an AWSReservedSSO_* Role is automatically created in each account.
25. Okta/Azure AD/Entra/Google → SCIM automatic user and group sync (RFC 7644).
26. IDC = employees and administrators / Cognito = customer users - never confuse them.
27. CLI v2 SSO uses the device authorization grant (OIDC), with tokens refreshed automatically after browser authentication.
28. ABAC + IDC: user attributes → IAM Role session tags → resource tag matching. Prevents an explosion of 100+ projects.
29. Administrator sessions 1h, developers 4h, ReadOnly 8h - the break-glass pattern.
30. Consolidated Billing: RI/SP sharing is ON by default; turn it OFF or use Cost Allocation Tags when separating by department.

The SCIM in item 25 is the RFC 7644 (System for Cross-domain Identity Management) standard, the authentication protocol SAML 2.0 is an OASIS standard, and the device authorization grant used by the IDC CLI is RFC 8628 (OAuth 2.0 Device Authorization Grant). When wording like "automatically sync Okta users to 50 accounts" appears on the exam, it is SCIM (provisioning), and the "login flow" is SAML (authentication). Provisioning (SCIM) ≠ Authentication (SAML) - you need to see these two separately to avoid getting confused among the options.

The Multi-Account 4-Layer Thinking Method

When solving Domain 1 scenarios, checking the 4 layers in order reveals missing elements.

┌──────────────────────────────────────────────────┐
│ Layer 1: Org   "How do we group accounts?"       │
│   - OU design (Security/Infra/Workloads/Sandbox) │
│   - Isolating the Management account             │
│   - New account automation (Account Factory/AFT) │
├──────────────────────────────────────────────────┤
│ Layer 2: SCP   "What is prohibited at OU level?" │
│   - Region restriction, root blocking, MFA       │
│   - Blocking disabling of CloudTrail/GuardDuty   │
│   - Sandbox: Deny high-cost instances            │
│   - RCP: block external principal access         │
├──────────────────────────────────────────────────┤
│ Layer 3: Control Tower   "What are the guardrails?" │
│   - Preventive (SCP auto-attached)               │
│   - Detective (Config Rule automatic)            │
│   - Proactive (CFN Hook)                         │
│   - Log Archive Object Lock + Audit Master      │
├──────────────────────────────────────────────────┤
│ Layer 4: IDC   "What about employee access?"     │
│   - External IdP (Okta/Azure AD) + SCIM          │
│   - Permission Set + session length              │
│   - ABAC (large numbers of projects)             │
│   - break-glass pattern                          │
└──────────────────────────────────────────────────┘

🔍 Going deeper: The 4 layers are not just a memorization frame but match the actual order of permission evaluation. When a request comes in, AWS combines (1) the intersection of the SCPs of all parent OUs from top to bottom, (2) the RCP (resource side), (3) the Permission Boundary, and (4) the Identity Policy + Resource Policy + Session Policy. If any one of these is an explicit Deny, it is denied immediately, and if there is no Allow anywhere, it is denied too (default-deny). Layers 1-2 determine the "OU-level ceiling," and the IDC Permission Set in Layer 4 determines "what employees are actually given within that ceiling." So the debugging order is: if "the SCP doesn't block it but the employee can't access," suspect the Permission Set (IDC), and if "the Permission Set was granted but it still doesn't work," suspect the parent SCPs.

Comparison Table: Frequently Confused Pairs

Regarding the last row - Organizations' SCP/policy metadata is managed in a global control plane and propagated to member accounts. This is an eventually consistent system that chose availability (A) under the CAP theorem. When you change an SCP, it is applied to all accounts within a few seconds to a few minutes, not immediately. In PACELC terms, it is close to a PA/EL system that "prioritizes availability (A) over latency (L) even when there is no partition (P)." So when the exam describes "right after an SCP change, it is not immediately reflected in some accounts," you should understand it as propagation delay, not a bug.

Anti-Patterns: Designs That Lead to Wrong Answers in Domain 1

⚠️ Trap: Domain 1 options always mix in choices that are "plausible but anti-patterns." Memorizing the 5 representative anti-patterns speeds up elimination.

1. Mapping OUs directly to the org chart (departments) - an OU is a "unit of common SCPs," not a human organization. If you split OUs into finance and HR teams, SCPs get pointlessly fragmented.
2. Running workloads/IAM Users in the Management account - if breached, an account with no SCP protection at all is compromised.
3. Creating IAM Users separately in each account and managing them manually - IDC + SCIM is the standard. Creating Users in each account means 50 accounts = 50x the management burden.
4. Mistaking SCPs for a means of granting permissions - putting Allow in an SCP does not create permissions without an IAM policy.
5. Implementing governance with Config Rules (Detective) alone - detection is after the fact. Rules that must be blocked (Region restriction, enforced encryption) are right with Preventive (SCP) or Proactive (CFN Hook).

🎯 Scenario: "A startup has grown quickly and has Prod, Dev, CI/CD, and data analytics all in a single account. The security team recommends moving to multi-account. What is the most appropriate first step?" - Answer: Stand up a Landing Zone with Control Tower, invite the existing single account under the Workloads OU, and then gradually separate Prod/Dev/Security/Log Archive/Audit accounts. Trying to move everything at once fails. From a 7R migration perspective this is close to an account-level "re-platform," and the key is stamping out new accounts with the standard baseline using Account Factory.

📝 Practice Questions

Click a choice to reveal the answer and explanation.

Question 1

5 OUs, 100 accounts. Some OUs must prohibit use of unauthorized Regions. Best?

• AUse Lambda automation to batch-deploy a Region-restricting IAM policy to all Roles in the 100 accounts and periodically reapply it to new Roles
• BAn Org SCP with an aws:RequestedRegion Deny + a NotAction exception for global services
• CPut a 0.0.0.0/0 Deny on the NACL outbound of subnets in unauthorized Regions to block communication of resources in those Regions
• DDeploy a Config Rule (region-restriction) to the entire OU to detect resources in unauthorized Regions and notify the security team via SNS

Question 2

After creating a new OU, the FullAWSAccess SCP is removed and only EC2 is allowed through an allow-list. What happens to an S3 call in that account?

• AAllowed - S3 is a global service, so it is outside the scope of Region- and OU-level SCPs
• BDenied (no S3 Allow in the SCP, implicit Deny)
• CAllowed - if the bucket's Resource Policy gives Allow, it overrides the SCP's implicit Deny
• DAllowed - if the account's IAM Policy gives an S3 Allow, it is evaluated with priority over the SCP

Question 3

Okta users + 50 AWS accounts + console/CLI SSO. What is the most appropriate?

• ARegister Okta individually 50 times as a SAML IdP in each account and manually map Federated Roles per account
• BIAM Identity Center + Okta (SAML + SCIM)
• CRegister employees in a Cognito User Pool and issue each account's IAM Role through an Identity Pool
• DIntegrate Okta with AD Connector and create per-employee IAM Users in each account to issue console and CLI keys

Question 4

When a new account is created, a standard baseline (CloudTrail, IAM Roles, tags) must be applied automatically. Terraform is used. Best?

• AUse Account Factory directly from the console to create new accounts and apply the baseline manually afterward
• BAFT (Account Factory for Terraform)
• CUse CfCT (Customizations for Control Tower) to automatically deploy CloudFormation templates to new accounts
• DUse StackSets alone to automatically deploy CloudTrail, IAM Role, and tag resources to new accounts

Question 5

Company policy: all EBS volumes must be KMS-encrypted. Block from the deployment attempt. Which guardrail?

• ADetective - detect unencrypted EBS with a Config Rule (encrypted-volumes) and correct it afterward with automatic Remediation
• BProactive (CloudFormation Hook)
• CPreventive - an SCP Deny on ec2:CreateVolume with the condition ec2:Encrypted=false
• DStandardize encryption status as a tag with Tag Policy and flag missing ones as noncompliant

Question 6

How do you collect the CloudTrail logs of 100 accounts in one place immutably?

• AEach account stores logs in its own S3 bucket and removes delete permissions via IAM policy to enforce immutability
• BLog Archive account + S3 Object Lock (WORM) + Organization Trail
• CConsolidate all accounts' CloudTrail into a central CloudWatch Logs group and set retention to permanent
• DCollect each account's logs in S3 and continuously audit for changes by querying directly with Athena

Question 7

An OU where a developer group can experiment freely. Risk of cost explosion. Best?

• AInclude it inside the Workloads OU
• BSandbox OU + SCP (Deny high-cost instances such as p4/p5/x2) + AWS Budgets Alert + automatic cleanup Lambda
• CAn IAM User in the Management account
• DDirect Connect + a separate VPC

Question 8

The CFO wants to bill costs separately by department. Best?

• AConsolidated Billing + per-department OUs + Cost Allocation Tags + the Cost Explorer per-department view
• BA separate Org per department
• CAbolish Linked Accounts
• DTrusted Advisor

Question 9

Guarantee that no one can disable CloudTrail. Best?

• ARemove the cloudtrail:StopLogging permission from IAM policies in all accounts and enforce the same policy on new Roles
• BAn SCP with explicit Deny on cloudtrail:StopLogging, DeleteTrail, and UpdateTrail
• CPlace a NACL in front of the S3 bucket where the Trail records to block CloudTrail control API traffic
• DInspect CloudTrail console and API requests with AWS WAF and block disabling attempts with rules

Question 10

Right after joining an Org, a company wants to quickly set up a Landing Zone and automate the Audit and Log standard. Best?

• ACombine CloudFormation, SCPs, and Config directly to self-build the Landing Zone and Audit/Log accounts over several months
• BControl Tower
• CCreate account and baseline products as a portfolio in Service Catalog for self-service provisioning
• DManually apply a standard account configuration based on the results of Trusted Advisor's security and fault tolerance checks

Question 11

A SaaS company wants to prevent principals outside the company from accessing any S3 bucket in an OU. Block in bulk with a policy from one place. Best?

• AWrite a Bucket Policy on each bucket one by one
• BLambda monitoring
• CA Resource Control Policy (RCP) attached to the OU (aws:PrincipalOrgID != o-xxxx Deny)
• DA GuardDuty alarm

Question 12

A company runs 100 projects. Each project has separate S3 buckets and EC2. Users must be able to access only their own project's resources. RBAC would explode into 100 Roles. What is the most suitable pattern?

• ACreate a Permission Set per project, define 100 in IDC, and assign per user
• BABAC + IDC: propagate IdP attributes as IAM Role session tags and match against resource tags
• CCreate an OU per project and block access to other projects' resources with SCPs on the 100 OUs
• DIsolate each project in its own account, 100 accounts, and map users only to the corresponding account

Wrapping Up

Week 2 covered the core four of Domain 1 in depth. Organizations groups accounts, SCPs set the ceiling, Control Tower automates governance, and IDC integrates employee SSO - these four are the standard stack of a multi-account environment. What we additionally saw today is (1) the historical context that this stack is layers accumulated over 7 to 8 years, (2) the theory that the account boundary is the strongest fault containment region in the cloud, (3) why the Capital One, Equifax, and S3 public incidents lead to account separation and SCPs/RCPs, and (4) the contrast with Azure Management Groups and GCP Folders.

Next week is Advanced Networking (Week 3). We revisit the networking that SAA touched lightly - VPC Peering vs. Transit Gateway, Direct Connect redundancy, Site-to-Site VPN, PrivateLink - at Pro depth. It is an area frequently tested in Domains 1 and 2, and scenarios like "how do you tie together thousands of VPCs" appear in earnest.

Re-solve the 12 questions you saw today, and for the ones you got wrong, apply the 4-layer thinking method (Org → SCP → CT → IDC) to check where you went wrong. The moment your hand automatically draws the 4 layers in the exam room is the signal of passing Domain 1. In particular, getting the distinguishing points of "SCP or IDC," "Preventive or Detective," and "SCIM or SAML" into your hands speeds up eliminating options.

---

📌 Next Week Preview

Week 3: Advanced Networking

• VPC Peering vs. Transit Gateway (environments with thousands of VPCs)
• Direct Connect redundancy + LAG + Resilience
• Site-to-Site VPN, Client VPN
• PrivateLink, VPC Endpoint, Service Endpoint
• Network Firewall, GWLB, Resolver