What's changed: Deepened SCS-C02 Chapter 6 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
6.1Multi-Account Security Governance
Understand org-scale governance—AWS Organizations/SCP, Control Tower, delegated administrators, central log/security accounts, and Firewall Manager. Enforce consistent guardrails across accounts.
Security at scale comes from org-level governance. Use Organizations and SCPs to impose guardrails and separate accounts by role.
6.1.1Organizational security governance
- Organizations/SCP: impose preventive guardrails (permission ceilings) on OU hierarchy (e.g., region restriction).
- Control Tower: auto-build landing zone and guardrails for standardization.
- Delegated admin/dedicated accounts: manage GuardDuty/Security Hub/Config from a dedicated security account.
- Firewall Manager: apply WAF/Shield/SG rules org-wide.
Common on SCS-C02: preventive guardrail = SCP (permission ceiling, not a grant), landing-zone automation = Control Tower, org-wide security service management = delegated administrator (dedicated account), logs to a dedicated log account. An SCP is effective only with both IAM allow AND SCP allow.
SCS-C02 multi-account governance probes "imposing consistent guardrails at the org level and operating security centrally." AWS Organizations nests accounts into OUs, with SCPs (Service Control Policies) imposing preventive guardrails (permission ceilings)—SCPs grant nothing; with Deny they enforce "no operations without MFA org-wide," "deny non-approved regions," "deny specific dangerous APIs," and "restrict root usage." Control Tower auto-builds a CAF-based landing zone (management/log-archive/audit accounts, networking, SSO) and controls (guardrails), vending new accounts with a baseline via Account Factory. Aggregate security services to a delegated administrator account (typically a dedicated security/audit account), managing GuardDuty/Security Hub/Config/Macie/IAM Access Analyzer/Detective org-wide and auto-ingesting member findings. Aggregate logs (CloudTrail org trail, Config) into a dedicated log-archive account separated from production and WORM-protected. Apply networking/WAF policies org-wide via Firewall Manager. By defense-in-depth, layer SCPs (prevention) + Config/Security Hub (detection) + auto-remediation (correction) + dedicated-account isolation (contain blast radius). The key is that SCPs are ceilings (AND with IAM), Control Tower automates the foundation, the delegated administrator centralizes, and logs/security live in dedicated accounts.
| Goal | Means | Key point |
|---|---|---|
| Preventive guardrail | SCP | Ceiling; enforce via Deny; not a grant |
| Standardize/automate foundation | Control Tower | Landing zone; Account Factory |
| Org-wide security management | Delegated admin (dedicated account) | GuardDuty/Security Hub/Config |
| Log/network governance | Log-archive account / Firewall Manager | Separate from prod + WORM; org-wide rules |
Scenario: In a dozens-of-accounts org, (1) forbid all regions except Tokyo/Virginia company-wide, (2) centralize security findings, (3) protect logs from tampering. → Use an SCP to Deny requests whose aws:RequestedRegion is outside the allowed regions (preventive guardrail). Aggregate GuardDuty/Security Hub/Config to a delegated administrator (dedicated security account) to manage members centrally. Aggregate the CloudTrail org trail and Config into S3 in a dedicated log-archive account with Object Lock (WORM). Vend new accounts via Control Tower Account Factory with these applied automatically.
FAQ: Does an SCP guardrail automatically grant per-account permissions? No. An SCP is a permission ceiling (guardrail), not a grant. Actual access still needs a separate Allow in each account’s IAM/resource policies, and effective permission is "SCP ∩ IAM." The SCP’s purpose is to enforce "only up to here" company-wide. Foundation auto-deployment and new-account baselines are handled by Control Tower.
Exam trap: Believing "an SCP Allow grants permissions to member accounts" is wrong—SCPs are ceilings; grants come from IAM (effective = SCP ∩ IAM). Also, keeping security logs in the same account as production is inappropriate (an attacker can erase them on compromise)—isolate with a dedicated log-archive account + WORM. Operating security services per-account is inefficient—centralize with a delegated administrator.
6.1.2Section summary
- Governance = Organizations/SCP + Control Tower
- Centralize = delegated admin (dedicated security/log accounts) + Firewall Manager
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Impose a guardrail so all accounts can never use non-approved regions. What?
Q2. Manage GuardDuty/Security Hub org-wide from a dedicated security account. What?
Q3. Centrally apply/enforce WAF rules and SG policies across many accounts. What?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.