Most AWS security questions on the SCS-C02 exam ask you to secure one account. The Management and Security Governance domain asks something harder: how do you enforce security consistently across dozens of accounts owned by teams you don’t control, without becoming the bottleneck for every change?
This is the domain that separates engineers who can secure a single VPC from architects who can secure an organization. It’s roughly 14% of the exam, but its concepts — Service Control Policies, delegated administration, centralized aggregation — thread through the detection, logging, and data-protection domains too. Get governance right and a surprising number of “which service?” questions answer themselves.
This deep dive is written from a practitioner’s perspective. We’ll cover AWS Organizations, Service Control Policies (SCPs), AWS Control Tower, delegated administration, AWS Config aggregators, and AWS Firewall Manager — how they fit together, the AWS CLI commands that make them concrete, and the exact distinctions the exam rewards. If you want the full exam picture first, start with the AWS Security Specialty Exam Guide 2026 and the domains breakdown, then come back here.
Why Multi-Account Governance Exists
A single AWS account is a blast radius. Everything in it shares one billing boundary, one set of service quotas, and — unless you’re careful — one set of blast-prone IAM permissions. As organizations grow, they split workloads into many accounts to isolate environments (prod vs. dev), limit blast radius, separate billing, and delegate autonomy to teams.
But isolation creates a new problem: consistency. If every team runs its own account, how do you guarantee that none of them can disable CloudTrail, launch resources in an unapproved Region, or turn off encryption? You can’t do it with IAM policies alone, because account admins can edit their own IAM. You need a control that sits above the account. That control is AWS Organizations, and the guardrails it enforces are Service Control Policies.
| Concept | Scope | Who can override it |
|---|---|---|
| IAM policy | Within one account | The account’s own admins |
| Permission boundary | An IAM principal in one account | Account admins (who set the boundary) |
| Service Control Policy (SCP) | Every principal in a member account | No one in the member account — only the management account |
| Resource policy | A specific resource | The resource owner |
That third row is the whole point. An SCP is the only control in the list that a member-account root user cannot escape.
AWS Organizations: The Foundation
AWS Organizations gives you a management account (the one that creates the organization) and any number of member accounts, arranged into a tree of Organizational Units (OUs).
# Create an organization (run from the future management account)
aws organizations create-organization --feature-set ALL
# Create an OU under the root
aws organizations create-organizational-unit \
--parent-id r-abcd \
--name "Production"
# Invite or create a member account
aws organizations create-account \
--email [email protected] \
--account-name "prod-workloads"Two feature sets exist. Consolidated billing only gives you a single payer but no policy controls. All features unlocks SCPs, tag policies, and integration with services like Control Tower and Firewall Manager. The exam expects ALL for any security scenario — if a question says SCPs aren’t taking effect, “the organization is in consolidated-billing mode” is a classic distractor answer.
The management account is special — and dangerous
Two facts the exam loves to test:
- SCPs do not apply to the management account. Even if you attach a deny-everything SCP to the root, the management account ignores it. This is why best practice — and Control Tower’s default — is to run no workloads in the management account and use it only for organization administration.
- The management account cannot be restricted by SCPs, so protect it separately. Lock down its root user with hardware MFA, minimize who can access it, and never deploy production resources there.
Trusted access and delegated administration
Organizations lets you enable trusted access for services like GuardDuty, Security Hub, AWS Config, IAM Access Analyzer, Macie, and Firewall Manager. Once trusted access is on, you can delegate administration of that service to a member account — typically a dedicated security/audit account — so your security team operates the service organization-wide without logging into the management account.
# Delegate GuardDuty administration to the security account
aws organizations register-delegated-administrator \
--account-id 222222222222 \
--service-principal guardduty.amazonaws.comThis is the pattern behind almost every “how should the security team manage X across all accounts?” question: enable trusted access, then register a delegated administrator in the security account. You almost never want the answer that runs everything from the management account.
Service Control Policies: Guardrails, Not Grants
An SCP defines the maximum set of permissions available to principals in the accounts it’s attached to. This is the single most misunderstood point on the exam, so say it out loud:
An SCP never grants a permission. It only sets a ceiling. The effective permission is the intersection of the SCP and the identity’s IAM policy.
If the SCP allows s3:* but the user’s IAM policy allows nothing, the user can do nothing. If the IAM policy allows s3:DeleteBucket but an SCP denies it, the delete is blocked. Both must allow.
The two SCP strategies
Deny lists (the common approach): start from the default FullAWSAccess policy that allows everything, then attach SCPs that explicitly Deny the dangerous actions. This is additive and easy to reason about.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyLeavingOrg",
"Effect": "Deny",
"Action": [
"organizations:LeaveOrganization",
"account:CloseAccount"
],
"Resource": "*"
},
{
"Sid": "DenyDisablingGuardrails",
"Effect": "Deny",
"Action": [
"cloudtrail:StopLogging",
"cloudtrail:DeleteTrail",
"config:DeleteConfigurationRecorder",
"guardduty:DeleteDetector"
],
"Resource": "*"
}
]
}Allow lists (stricter, higher-maintenance): remove FullAWSAccess and explicitly Allow only the services you sanction. Every new service must be whitelisted before anyone can use it. The exam frames allow lists as the choice when a compliance regime demands that only an approved service catalog be usable.
SCP patterns the exam expects you to recognize
| Requirement | SCP pattern |
|---|---|
| Prevent use of Regions outside eu-west-1 | Deny with aws:RequestedRegion condition (allow-list global services) |
| Stop anyone disabling CloudTrail/Config/GuardDuty | Deny on the relevant Stop/Delete actions |
| Require encryption on new EBS volumes | Deny ec2:CreateVolume when ec2:Encrypted is false |
| Block root-user actions in member accounts | Deny with aws:PrincipalArn matching the root ARN |
| Force resources to be created only with a required tag | Deny create actions unless aws:RequestTag/... is present |
A subtle one: an SCP with a Region restriction should not block global services (IAM, CloudFront, Route 53, Organizations, Support). The idiomatic solution uses a Deny on aws:RequestedRegion combined with a NotAction list of those global services, so you don’t accidentally break IAM.
For the identity-side counterpart to SCPs — permission boundaries, cross-account roles, and policy evaluation order — pair this with the AWS IAM deep dive for SCS-C02.
AWS Control Tower: Governance as a Managed Service
Setting all of this up by hand — Organizations, OUs, a log-archive account, a security account, baseline SCPs, Config, centralized CloudTrail — is exactly the “landing zone” that AWS Control Tower automates.
Control Tower stands up a prescriptive, well-architected multi-account environment and keeps it compliant. Its key pieces:
- Landing zone: the baseline environment, including a Log Archive account (centralized, immutable log storage) and an Audit (security) account for cross-account access and notifications.
- Account Factory: a provisioning workflow (backed by Service Catalog) that vends new accounts pre-configured with your baseline. This is the answer to “how do teams get new accounts that are secure by default?”
- Controls (guardrails): pre-packaged rules, each implemented as one of three types.
| Control type | Mechanism | Example |
|---|---|---|
| Preventive | Service Control Policy | ”Disallow deletion of log archive S3 buckets” |
| Detective | AWS Config rule | ”Detect whether EBS volumes are unencrypted” |
| Proactive | CloudFormation Hook | ”Block a stack that would create a public RDS instance before it deploys” |
Memorize that mapping. A very common SCS-C02 question describes a desired outcome (“prevent,” “detect,” or “block before creation”) and asks which control type applies. Preventive = SCP, detective = Config, proactive = CloudFormation hook.
Controls also come as mandatory (always on), strongly recommended, and elective. And Control Tower’s drift detection tells you when someone has manually changed something outside the governed baseline — the answer to “how do you know if an account has drifted from its landing-zone configuration?”
Centralized Detection and Aggregation
Governance isn’t only about prevention; it’s about seeing the whole estate from one place. Three services do the aggregation, and the exam wants you to know which one aggregates what.
AWS Config aggregators
AWS Config records resource configuration and compliance per account, per Region. A configuration aggregator rolls that data up into a single account and Region so you can answer “show me every non-compliant resource across the organization.” Pair it with conformance packs — packaged collections of Config rules and remediations — deployed organization-wide, and organization Config rules for centrally managed rules.
# Create an organization-wide aggregator in the security account
aws configservice put-configuration-aggregator \
--configuration-aggregator-name org-aggregator \
--organization-aggregation-source \
RoleArn=arn:aws:iam::222222222222:role/AWSConfigRole,AllAwsRegions=trueSecurity Hub central configuration
Security Hub aggregates findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, and dozens of partner sources into the normalized AWS Security Finding Format (ASFF). With a delegated administrator and central configuration, you enable standards (like the AWS Foundational Security Best Practices and CIS benchmarks) and policies across all accounts and Regions from one place, and use a cross-Region aggregation Region to see everything in a single dashboard. This is the connective tissue that links governance to the threat detection and incident response domain.
The division of labor
| Question the exam asks | Service |
|---|---|
| ”Aggregate resource configuration and compliance across accounts” | AWS Config aggregator |
| ”Aggregate security findings across accounts and Regions” | Security Hub |
| ”Aggregate CloudTrail and Config events into a queryable store” | CloudTrail Lake / centralized S3 (see logging & monitoring) |
AWS Firewall Manager: Centralized Network Protection
Once you have many accounts, you also have many places for network protections to drift. AWS Firewall Manager centrally configures and enforces protection policies across the organization. It requires AWS Organizations (all features) and a designated Firewall Manager administrator account.
Firewall Manager can centrally manage:
- AWS WAF rule groups on ALB, API Gateway, CloudFront, and App Runner
- AWS Shield Advanced protections for DDoS
- Security groups — audit for overly permissive rules and enforce a common baseline
- AWS Network Firewall policies across VPCs
- Route 53 Resolver DNS Firewall rules
The killer feature for the exam: Firewall Manager automatically applies the policy to new resources as accounts and resources are created. So the answer to “how do you ensure every new ALB in every account automatically gets the corporate WAF rules?” is Firewall Manager — not a manual WAF association, and not a Config remediation.
| Scenario | Right answer |
|---|---|
| Enforce one WAF rule set on all current and future ALBs org-wide | AWS Firewall Manager |
| Attach a WAF web ACL to a single ALB you own | AWS WAF directly |
Audit security groups across accounts for 0.0.0.0/0 on port 22 | Firewall Manager (SG audit policy) or Config rule |
| Central DDoS protection with cost protection | Shield Advanced, managed via Firewall Manager |
Sharing Resources Safely: RAM and IAM Identity Center
Two more governance building blocks round out the domain:
AWS Resource Access Manager (RAM) shares specific resources — subnets, Transit Gateways, Route 53 Resolver rules, License Manager configs — across accounts without copying them or creating cross-account roles. When a question asks how to let a networking account own a Transit Gateway that workload accounts attach to, RAM is the answer.
IAM Identity Center (formerly AWS SSO) centralizes human access. You define permission sets once and assign them to users/groups across all accounts, integrated with your existing identity provider. This is the workforce-access counterpart to SCPs: SCPs cap what’s possible in an account; Identity Center controls who gets in and with what role.
Putting It Together: A Reference Multi-Account Model
Here’s the mental model to carry into the exam. A well-governed organization typically has:
- A management account — organization admin only, no workloads, root locked down.
- A security/audit account — delegated administrator for GuardDuty, Security Hub, Config aggregator, Macie, Access Analyzer, and Firewall Manager.
- A log archive account — centralized, immutable CloudTrail and Config logs (often with S3 Object Lock).
- Workload OUs (prod, non-prod, sandbox) — governed by SCPs and Control Tower controls, provisioned through Account Factory.
Root
├── Security OU
│ ├── Log Archive account (immutable logs)
│ └── Audit account (delegated admin: GuardDuty, Security Hub, Config)
├── Infrastructure OU
│ └── Network account (Transit Gateway shared via RAM)
└── Workloads OU
├── Production OU (strict SCPs, Firewall Manager WAF baseline)
└── Non-Production OU (relaxed SCPs, sandbox controls)If you can draw this from memory and explain why each account exists, you’ll recognize the correct answer to most governance questions on sight.
Exam-Day Distinctions to Memorize
- SCP vs. IAM policy: SCP sets the ceiling, IAM grants within it. Effective permission = intersection. SCPs never grant.
- SCPs don’t apply to the management account — ever.
- Preventive control = SCP, detective = Config rule, proactive = CloudFormation hook (Control Tower terminology).
- Delegated administrator lives in the security account; the management account should not run detection services day-to-day.
- Config aggregator = configuration/compliance rollup. Security Hub = findings rollup. Don’t swap them.
- Firewall Manager auto-applies protections to new resources; plain WAF/Shield do not.
- RAM shares resources; Identity Center shares human access; Organizations/SCPs enforce guardrails.
- Region-restriction SCPs must exclude global services or they break IAM.
Frequently Asked Questions
Do Service Control Policies grant permissions?
No. SCPs only define the maximum available permissions (a ceiling). A principal can perform an action only if both an SCP and an IAM policy allow it. If either denies, the action is blocked. This intersection model is one of the most tested ideas in the domain.
Why don’t my SCPs affect the management account?
By design. The management account is never restricted by SCPs, even ones attached to the root. That’s precisely why best practice is to keep it workload-free and use a separate security account for day-to-day operations. Expect at least one question that hinges on this fact.
What’s the difference between AWS Control Tower and AWS Organizations?
Organizations is the underlying multi-account and SCP service. Control Tower is a managed, prescriptive layer on top of Organizations that automates a secure landing zone — log archive and audit accounts, baseline guardrails, Account Factory, and drift detection. You can build the same thing manually with Organizations, but Control Tower does it in a well-architected, repeatable way.
When should I use AWS Firewall Manager instead of AWS WAF directly?
Use WAF directly to protect a single resource you own. Use Firewall Manager when you need to enforce WAF, Shield, security-group, or Network Firewall policies consistently across many accounts and automatically onto new resources. The “current and future resources, org-wide” phrasing is the tell for Firewall Manager.
How does the security team manage GuardDuty across all accounts without using the management account?
Enable trusted access in Organizations, then register the security account as the delegated administrator for GuardDuty. The security team then manages detectors, members, and findings org-wide from that account. The same pattern applies to Security Hub, Config, Macie, and Access Analyzer.
Is this domain worth deep study if it’s only ~14% of the exam?
Yes. Governance concepts reappear inside the logging, detection, and data-protection questions, so mastering them lifts your score across domains. See the full domains breakdown for how the weighting works.
Conclusion and Next Steps
Multi-account governance is where AWS security stops being about individual resources and becomes about systems — enforcing consistent guardrails, centralizing visibility, and vending secure accounts at scale. Master the intersection model of SCPs, the preventive/detective/proactive control mapping in Control Tower, the delegated-administrator pattern, and the aggregation split between Config and Security Hub, and you’ll have the mental scaffolding that the rest of the exam quietly depends on.
The fastest way to turn this knowledge into exam-day reflexes is realistic practice. Sailor.sh’s AWS Certified Security - Specialty (SCS-C02) Mock Exam Bundle gives you exam-style questions that mirror the real format and difficulty — including the multi-account governance, SCP, and Control Tower scenarios covered here — with detailed explanations that surface the exact distinctions the exam tests. Working through realistic questions is the surest way to find your gaps before they cost you points.
Pair the practice with structured study using the AWS Security Specialty study plan, review the full exam topics list, go deep on the related IAM policy evaluation, and connect governance to detection with the Threat Detection & Incident Response domain and logging & monitoring.