Multi Account Strategy Organizations Controltower

You got paged at 02:14: a developer account in your AWS organization is exfiltrating data to an external S3 bucket. Inside the next ten minutes you need to (a) revoke the compromised principal's permissions, (b) block any new sibling account from being abused the same way, (c) preserve forensic evidence in a tamper-proof place, and (d) prove to the compliance auditor on Monday that the rest of the fleet is still inside policy. None of that is achievable if your only tool is "log into one account at a time and click around". Multi-account strategy is the security engineer's lever to do all four of those things at once, across hundreds of accounts, before the attacker finishes their loop.

This SCS-C02 guide approaches AWS Organizations and AWS Control Tower from the security engineer's daily reality: detect, contain, remediate, and audit. We assume you already know how to write IAM policies and assume cross-account roles. The focus here is the organization-wide control plane that turns the whole fleet into a single security surface — SCPs as deny-by-default guardrails, Control Tower controls as opinionated baselines, delegated administrators that move security tooling out of the dangerous management account, the AWS Config aggregator as your org-wide evidence engine, and the root-user controls that auditors always ask about.

Why Multi-Account Strategy Matters on SCS-C02 Domain 6.1

Domain 6 is 14 percent of SCS-C02, and task statement 6.1 is explicit: "Develop a strategy to centrally deploy and manage AWS accounts." The exam guide enumerates the knowledge areas that show up in scenario questions — multi-account strategies, managed services that allow delegated administration, policy-defined guardrails, root account best practices, and cross-account roles. Every one of those is a containment or detection lever that a security engineer reaches for during an incident or an audit.

SCS-C02 questions in this area are almost never "what is an SCP?". They read like real on-call tickets: an account got compromised, a developer disabled CloudTrail, a regulator wants seven-year evidence retention, the security team is tired of logging into the management account. The right answer is usually a multi-account control — root-level deny SCP, delegated admin pattern, Control Tower guardrail, Config aggregator query — not an account-local fix. If your gut answer to a fleet-wide problem is to ssh into one EC2 instance, you will pick the wrong choice.

Plain-Language Explanation: Multi-Account Security Strategy

Three analogies that match how a security engineer actually thinks during an incident.

Analogy 1: The hospital ward system

Picture a large hospital. Each AWS account is a ward with its own patients, equipment, and staff. The management account is the hospital director's office — extreme privilege, signs the master contracts, but never sees patients directly. Organizational Units (OUs) are wings with a shared protocol — the ICU wing, the maternity wing, the outpatient wing — each subject to the same infection-control rules. SCPs are the infection-control bylaws posted on every door: "no outside food, no unwashed hands, no unauthorized prescriptions". They never give a doctor the right to prescribe (the IAM policy is the medical license); they only forbid certain actions no matter how senior you are. Control Tower is the hospital accreditation body that says "every ward must have functioning fire alarms (CloudTrail), oxygen sensors (GuardDuty), patient logs (Config), and an isolation room (Audit account)". When a contagious patient appears (compromised IAM principal), the delegated security administrator — the infection-control nurse working out of a dedicated office — can quarantine the ward, pull records, and brief the director, without needing the director's master keys to the entire hospital.

Analogy 2: The air-traffic control radar

Imagine you are an air-traffic controller. Each AWS account is an aircraft in your airspace. The management account is the tower itself — you protect it like a vault and you do not let routine traffic pass through it. OUs are flight corridors — domestic, international, freight, training. SCPs are the flight rules — "no aircraft may exit the corridor", "no aircraft may turn off its transponder", "no aircraft may climb above flight level 410 in this corridor". An aircraft turning off its transponder is the equivalent of a member account calling cloudtrail:StopLogging — the SCP simply rejects the radio signal at the source. The AWS Config aggregator is your radar console — every aircraft's position and heading is reported to one screen so you can see the whole airspace at once. A delegated administrator is the shift supervisor for the radar console: they have full visibility into every flight without holding the airport's master keys. Control Tower drift detection is what happens when an aircraft strays out of corridor — an alarm sounds, you investigate, you steer it back.

Analogy 3: The bank branch network

A retail bank with 200 branches. The management account is head office, where the master vault is. Each AWS account is a branch office with its own till, customers, and CCTV. OUs are regional clusters ("North-East branches", "Online-only branches", "Decommissioned branches"). SCPs are the bank's anti-fraud bylaws — "no branch may open a foreign-currency account without head-office sign-off", "no branch may delete CCTV footage", "no branch teller may move more than $50K without dual approval". When a teller is suspected of fraud, the central fraud team (delegated admin in the Audit account) can pull every branch's transaction logs from one console (CloudTrail organization trail + Athena), freeze the teller's access via SCP at the OU level, and produce evidence for regulators — without ever issuing themselves the head-office master key. Control Tower mandatory controls are the non-negotiable security minimums the regulator imposes on every branch (working alarm, locked vault, signed audit trail); strongly-recommended controls are the bank's own hardening posture beyond the regulator's floor.

AWS Organizations from a Security Engineer's POV

You inherit, or design, an organization. Your security questions are: where do I put the dangerous accounts, where do I run the security tooling, and what API calls must never succeed anywhere?

The OU layout that makes incident response possible

The AWS Security Reference Architecture (SRA) and the "Organizing Your AWS Environment" whitepaper describe the same canonical OU pattern. From a SecOps angle, each OU exists because it has a distinct security posture:

• Security OU — non-workload accounts owned by the security org. Contains:
  • Log Archive account — write-only S3 buckets receiving the org's CloudTrail trail and AWS Config snapshots; tamper-proof via S3 Object Lock + SCP-blocked delete actions.
  • Audit (Security Tooling) account — delegated administrator for GuardDuty, Security Hub, Macie, Detective, Inspector, IAM Access Analyzer, Config aggregator. This is where you, the SecOps engineer, work daily.
  • Forensics account — quarantine destination for compromised EBS volume snapshots, memory dumps, and isolated EC2 AMIs (see also the incident-response-isolation-forensics topic).
• Infrastructure OU — Network account (Transit Gateway, AWS Network Firewall, Firewall Manager delegated admin) and Shared Services account.
• Workloads OU — split into Prod and Non-Prod sub-OUs; each application team gets its own account inside.
• Sandbox OU — experimental accounts behind an aggressive allow-list SCP and tight budget caps.
• Suspended OU — quarantine for compromised or decommissioned accounts behind a deny-all SCP. This is where you move an account during incident containment.
• Policy Staging OU — a transit zone for newly invited accounts (e.g., from acquisitions) before they pick up the full guardrail set.

The Suspended OU is the lever you reach for at 02:14: move the compromised account into it, the deny-all SCP takes effect immediately, the attacker's principals lose authorization on the next API call, and you keep the account intact for forensic acquisition rather than closing it.

Management account hygiene is non-negotiable

The management account is the single most dangerous account in the organization. SCS-C02 questions repeatedly probe whether you understand its quirks:

• SCPs do not apply to the management account. Even a deny-all SCP at the root cannot constrain it.
• Run zero workloads in the management account. Treat it like a hardware vault: you visit, you sign in for a specific operation, you leave.
• Lock the root user: hardware MFA, no access keys, credentials sealed, monitored by CloudTrail to a CloudWatch alarm on any root-user userIdentity.type == "Root" event.
• Use IAM Identity Center for human access to the management account; no IAM users.
• Move every security service out via delegated administrator (next section).

Service Control Policies as Security Guardrails

For a security engineer, SCPs are the strongest control AWS gives you because they evaluate before any IAM allow can fire. Master a small set of SCP patterns and you cover most of the SCS-C02 question surface.

How SCPs evaluate

Every API call from a member account must satisfy:

1. The action must be allowed by every SCP on the path from the org root through the OUs to the account (intersection of allows).
2. Any explicit deny on the path wins absolutely — single deny vetoes everything.
3. The principal's IAM identity-based policy in the member account must also allow the action.
4. Resource-based policies (S3 bucket, KMS key, etc.) and session policies still apply.
5. The management account is exempt; service-linked roles are exempt.

The default FullAWSAccess managed SCP attached to every new OU and account allows everything. To run an allow-list posture you detach FullAWSAccess and attach a narrow allow SCP. Most production orgs run a deny-list posture (allow everything except enumerated risks) at the root and OU level, with an allow-list layered onto Sandbox and Suspended OUs.

Pattern A: The audit-tamper deny SCP (root-level, must-have)

This SCP attached to the org root protects the security telemetry from any member-account admin:

• Deny cloudtrail:StopLogging, cloudtrail:DeleteTrail, cloudtrail:UpdateTrail, cloudtrail:PutEventSelectors against the org trail.
• Deny config:DeleteConfigurationRecorder, config:StopConfigurationRecorder, config:DeleteDeliveryChannel.
• Deny guardduty:DeleteDetector, guardduty:DisassociateFromMasterAccount, guardduty:StopMonitoringMembers.
• Deny securityhub:DisableSecurityHub, securityhub:DisassociateFromMasterAccount.
• Deny macie2:DisableMacie, inspector2:Disable.
• Deny iam:DeleteRole and iam:DeletePolicy against AWSControlTowerExecution.
• Deny s3:DeleteBucket, s3:DeleteBucketPolicy, s3:PutBucketPolicy against the centralized log archive bucket via tag condition.
• Deny kms:ScheduleKeyDeletion, kms:DisableKey on tag-filtered audit-critical KMS keys.

This is the single most exam-relevant SCP pattern. Cross-link it with the centralized-logging-cloudtrail-vpcflow topic — the centralized log architecture is only tamper-proof if the SCP backstops it.

Pattern B: Region restriction SCP

Most security teams shrink the attack surface by allowing only approved regions. Use aws:RequestedRegion with a Deny+NotAction excluding global services that look regional but aren't:

"Effect": "Deny",
"NotAction": [
  "iam:*", "organizations:*", "route53:*",
  "cloudfront:*", "waf:*", "waf-regional:*",
  "sts:*", "support:*", "globalaccelerator:*",
  "budgets:*", "ce:*", "health:*", "tag:*"
],
"Resource": "*",
"Condition": { "StringNotEquals": { "aws:RequestedRegion": ["us-east-1","eu-west-1"] } }

Forget any global service in NotAction and you brick IAM, KMS, or CloudTrail across the org — the most common SCP mistake. This is the one legitimate use of Deny+NotAction; it works because it is paired with a region condition.

Pattern C: Root-user lockdown SCP

To enforce root-user MFA and prevent root from being used at all, attach this at the root or all-OUs level:

• "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" } }.

That single SCP statement turns every root-user API call into AccessDenied across the organization (except, again, in the management account, where you must control root operationally). Pair with the Control Tower strongly-recommended control "Require MFA for the root user" so any console login attempt fails without MFA — see the next section on Control Tower control categories.

Pattern D: Data perimeter SCP (identity side)

A data perimeter ensures only trusted identities can access trusted resources from trusted networks. The identity side belongs in SCPs:

• Deny s3:*, kms:*, secretsmanager:* when aws:PrincipalOrgID does not match your org ID — blocks confused-deputy exfiltration via a cross-account principal.
• Deny when aws:PrincipalIsAWSService is false and aws:SourceVpc/aws:SourceVpce is absent — narrows the network side.

The resource side (bucket policies, KMS key policies) uses the same condition keys; together they form the perimeter. This pattern is heavily tested.

AWS Control Tower for Security Engineers — Landing Zone and Control Categories

Control Tower is the opinionated wrapper around Organizations that provisions and maintains a best-practice landing zone. For a security engineer the value is mostly in the controls catalog — preventive, detective, and proactive policies grouped by business category — and in the standard Log Archive + Audit account topology that the rest of your tooling assumes.

What Control Tower provisions for you

Launching Control Tower in a new management account stands up, in roughly an hour:

• Security OU containing the Log Archive and Audit accounts.
• Sandbox OU as a starter container.
• Organization-wide CloudTrail trail delivering to the Log Archive bucket.
• AWS Config recorder in every enrolled account, with deliveries to the Log Archive bucket.
• AWS Config aggregator in the Audit account.
• IAM Identity Center with default permission sets per OU.
• AWS KMS CMKs for log and Config encryption (optionally customer-managed).
• The mandatory controls baseline applied to every OU.

The three control categories — exam-critical

Control Tower labels each control by business category. SCS-C02 expects you to know the difference because the exam frequently asks "is this control automatic or opt-in?".

• Mandatory controls — applied automatically to every OU at landing-zone creation, cannot be removed. They guard the landing zone itself: deny deletion of the Log Archive bucket, deny disabling CloudTrail, deny modifying CloudTrail trail in the Log Archive account, deny configuration changes to the audit role. Treat them as the floor below which the org cannot fall.
• Strongly recommended controls — opt-in but AWS recommends turning them on for nearly every org. Examples: "Require MFA for the root user", "Disallow public read access to log archive S3 buckets", "Enable encryption at rest for Amazon EBS by default", "Disallow Internet connection through SSH". A SecOps team in a regulated industry typically enables all of them.
• Elective controls — opt-in for specific compliance frameworks. Examples: "Disallow Amazon S3 buckets without versioning", "Require an Amazon S3 bucket to have replication enabled", "Disallow Amazon EC2 instances from creating an Elastic IP".

Beyond Control Tower's own catalog, the unified Controls Catalog also exposes Security Hub framework controls (NIST 800-53, PCI-DSS, CIS) which you enable per OU. SCS-C02 questions about "applying NIST 800-53 controls organization-wide via Control Tower" point at this unified catalog.

Preventive vs detective vs proactive — implementation under the hood

Each Control Tower control is also classified by how it enforces. This is the bit candidates miss most:

• Preventive controls are SCPs attached by Control Tower to the OU. They block non-compliant API calls outright. Example: "Disallow deletion of log archive" is implemented as a deny SCP on s3:DeleteBucket against the log bucket.
• Detective controls are AWS Config rules that flag non-compliant resources after creation. Example: "Detect whether public read access to S3 buckets is allowed" is a Config managed rule that emits non-compliant findings into the Config aggregator and Security Hub.
• Proactive controls are CloudFormation Hooks that evaluate templates during CREATE/UPDATE before resources actually exist. Example: "Require encryption on new RDS DB instances" is a proactive hook that fails the stack operation if encryption is not set.

Drift is an incident signal

Drift in Control Tower means somebody changed the landing zone state out from under it: SCP detached, OU membership altered, Log Archive bucket policy modified, Config recorder stopped. From a SecOps perspective drift is itself a possible IoC — an attacker with stolen admin credentials trying to weaken the controls before the data theft.

The architectural pattern is:

1. The root-level audit-tamper deny SCP (Pattern A above) prevents the most damaging drift outright.
2. Control Tower drift detection runs continuously and surfaces drift findings.
3. An EventBridge rule on aws.controltower drift events routes to SNS / Slack / PagerDuty for SecOps alerting.
4. Systems Manager Automation runbooks re-enroll the OU or restore the configuration once you have determined drift was unauthorized.

Delegated Administrators — Get Security Tooling Out of the Management Account

The single most important SCS-C02 multi-account-strategy concept after SCPs is delegated administrator. AWS Organizations lets a member account take over administration of an integrated AWS service on the org's behalf. The Audit (Security Tooling) account becomes the operational seat for the SecOps team without anyone holding management-account credentials.

Services with delegated admin (must-know list)

The exam expects you to recognize that all of these support delegated admin:

• Amazon GuardDuty — central detector administration, member account auto-enrollment, threat finding aggregation.
• AWS Security Hub — org-wide finding aggregation, framework standards enablement, cross-region finding aggregation.
• Amazon Macie — org-wide S3 sensitive-data discovery, allow-list and custom data identifier management.
• Amazon Detective — graph database aggregating CloudTrail, VPC Flow Logs, GuardDuty findings across the org.
• Amazon Inspector — org-wide EC2/ECR/Lambda vulnerability scanning.
• AWS IAM Access Analyzer — org-wide external-access analyzer plus unused-access analysis.
• AWS Config — org aggregator for multi-account multi-region compliance evidence.
• AWS Audit Manager — central evidence collection across the org.
• AWS Firewall Manager — org-wide WAF, Shield Advanced, Network Firewall, security group rules.
• AWS Backup — org-wide backup plans and Vault Lock.
• AWS CloudFormation StackSets (service-managed) — org-wide infrastructure deployment.
• AWS Systems Manager (Quick Setup) — org-wide patching baselines.

The canonical assignment, also reflected in the AWS Security Reference Architecture (SRA):

• Audit / Security Tooling account — delegated admin for GuardDuty, Security Hub, Macie, Detective, Inspector, IAM Access Analyzer, Audit Manager, Config aggregator.
• Network account — delegated admin for Firewall Manager.
• Log Archive account — receives CloudTrail org trail and Config snapshots; not itself a delegated admin.

Why this matters during incident response

When you get paged at 02:14, you log into the Audit account (via IAM Identity Center, with MFA). From there:

• You read all GuardDuty findings across the org in one console.
• You query Security Hub for the highest-severity active findings.
• You jump into Detective to follow the principal's behavior across the past 30 days.
• You query the Config aggregator to find every account that has the same vulnerable configuration.
• You optionally trigger a Lambda runbook (deployed via StackSets to every account) that isolates the compromised resource.

None of that requires touching the management account. None of it requires you to have administrator IAM in every member account either — the delegated-admin pattern grants the Audit account principals the necessary cross-account read/write surface through the integration's service-linked roles.

AWS Config Aggregator as Org-Wide Compliance Evidence

The AWS Config aggregator is the single tool that turns a multi-account org into a queryable inventory. It runs in the Audit account (delegated admin), pulls configuration items and rule compliance status from every account in every governed region, and exposes them via the aggregator's queries, advanced query SQL, and the Security Hub Insights it powers.

Setup pattern

1. From the management account, register the Audit account as Config delegated administrator.
2. In the Audit account, create a Config aggregator with AWS Organizations as the source (single click — it auto-discovers every account in every region).
3. Enable Config recorders in every member account at scale via CloudFormation StackSets with service-managed permissions (the Control Tower mandatory baseline already does this if Control Tower is in play).
4. Define organization Config rules centrally; they propagate to every account.
5. Wire Config rule non-compliance events through EventBridge to Security Hub (or directly to your SIEM) for alerting.

Use cases that show up on SCS-C02

• "Find every S3 bucket without encryption across the org" — single Config advanced query against the aggregator.
• "Prove to the auditor that 100 percent of EC2 instances in us-east-1 have IMDSv2 enforced" — aggregator query plus CSV export.
• "Detect any Security Group allowing 0.0.0.0/0 on port 22 anywhere in the fleet" — Config managed rule restricted-ssh evaluated org-wide.
• "Continuous evidence for a SOC 2 audit" — Config aggregator + Audit Manager assessment using Config evidence sources.

The aggregator pairs with Security Hub (findings) and Audit Manager (evidence packs) to form the org-wide compliance triangle. See the compliance-evaluation-config-auditmanager topic for the deeper coverage.

Root-User Hardening Across the Org

SCS-C02 task 6.1 explicitly lists "Securing AWS account root user credentials" as a skill. Every member account has a root user that, by default, has full unconditional power. The security engineer's job is to make root effectively unusable except for the handful of operations only root can perform (closing the account, changing the account email, restoring a deleted KMS-encrypted S3 bucket).

The three-layer defense for root

1. Preventive — root-user deny SCP (Pattern C above). Any root API call from a member account returns AccessDenied. The management account's root remains operationally controlled.
2. Preventive — Control Tower strongly-recommended control "Require MFA for the root user". The console login page rejects any attempt without MFA configured. Pair with a hardware security key for the management account root.
3. Detective — CloudTrail event filter on userIdentity.type == "Root". Forward any matching event from the org trail (CloudWatch Logs subscription filter) to a CloudWatch alarm, EventBridge rule, and SNS topic so the SOC sees every root-user usage in real time.

For new accounts, AWS Organizations centrally managed root user credentials (introduced in late 2024) lets the management account remove the root user's password and IAM credentials from every member account altogether, leaving root reachable only via password recovery on the registered email. SCS-C02 questions framed as "how do we eliminate the per-account root credentials problem at the org level?" point at this feature.

Cross-Account Roles for SecOps and Forensics

Cross-account roles are the bread and butter of multi-account security operations. The exam guide knowledge bullet "cross-account roles" is not asking about Associate-tier sts:AssumeRole; it is asking about the patterns SecOps engineers use:

• Read-only auditor role in every account, trusted by the Audit account, used by Security Hub custom integrations and Athena cross-account queries.
• Incident-response role in every account, trusted by the Audit account's responder principals, with a permissions boundary capping it to isolation actions (modify Security Group, snapshot EBS, replace IAM role policies on a compromised instance).
• Forensic acquisition role trusted by the dedicated Forensics account, with permissions to copy EBS snapshots cross-account into the Forensics account's encrypted Snapshot store and to copy CloudTrail/VPC Flow Logs from Log Archive S3 into the Forensics S3 bucket.
• Break-glass role in the management account, trusted by hardware-MFA-protected security principals, used only for organization-wide emergency operations (registering a new delegated admin, modifying a root-level SCP). Every assumption of this role triggers a SOC alert.

Deploy these roles uniformly via CloudFormation StackSets with service-managed permissions targeting the org root, so newly created accounts inherit them automatically. This is the multi-account analog of "every server has the same SSH key configuration" and it is what makes cross-account forensics actually feasible at 02:14. Cross-link with the secure-deployment-iac-firewallmanager topic for the IaC deployment patterns.

Containing a Compromised Account — The Multi-Account Levers

Putting the pieces together. Suppose the page is real: account 123456789012 has a compromised IAM role exfiltrating S3 objects. From the Audit account you have these multi-account levers in priority order:

1. Move the account to the Suspended OU (or a dedicated Quarantine OU). The deny-all SCP attached there causes every API call from the account's principals to start failing within seconds. This is the highest-leverage first action.
2. Invoke the IR role into the account to apply a quarantine IAM role policy that explicitly denies s3:*, kms:*, iam:CreateAccessKey, and sts:AssumeRole to the suspect principal — defense in depth in case the SCP move is delayed.
3. From the delegated-admin GuardDuty console in the Audit account, review the past 24 hours of findings on the account and on associated principals.
4. From Detective, pivot from the principal to the resources it accessed and the IPs it called from.
5. From the Forensics account, snapshot the relevant EBS volumes and copy the S3 access logs from Log Archive (the org trail's S3 bucket).
6. From the Config aggregator, query for every other account that has the same risky configuration (e.g., the same OIDC trust policy that got abused) so you can preemptively patch siblings.
7. Update the audit-tamper deny SCP if you discovered a new abuse path during the incident.

Steps 1, 3, 4, 5, 6 are only possible because of the multi-account control plane this topic covers. Without it, you would be doing all seven serially via management-account credentials, which is both slower and a fresh source of risk.

Common Traps — Multi-Account Strategy on SCS-C02

Trap 1: Running security tooling from the management account

The exam will offer answers like "create an IAM role in the management account for the security team to assume". Wrong. Use delegated administrator and operate from the Audit account.

Trap 2: Believing SCPs alone protect against external access

SCPs constrain principals inside member accounts. They do not constrain a third-party AWS account that gets allowed by an S3 bucket policy in your account. To close that hole, the resource policy needs an aws:PrincipalOrgID condition. Same idea, two policy locations.

Trap 3: Deny+NotAction as an allow-list

{"Effect":"Deny","NotAction":["s3:*"]} denies everything that is not S3 — including IAM, KMS, CloudTrail. The safe allow-list is {"Effect":"Allow","Action":[approved actions]} with FullAWSAccess detached. Use Deny+NotAction only when paired with a condition (region, principal-org-id) that scopes the deny.

Trap 4: Conflating Control Tower control categories

Mandatory ≠ strongly-recommended ≠ elective. Exam choices that say "all Control Tower mandatory controls cover NIST 800-53" are wrong: NIST 800-53 mapping is in the unified Controls Catalog, layered on top, and uses Security Hub framework controls.

Trap 5: Assuming Control Tower covers application-resource drift

Control Tower drift detection covers the landing zone's own state. Application-resource drift (a developer manually editing a Security Group, a workload S3 bucket made public) is AWS Config's job, not Control Tower's. Wire them both.

Trap 6: Self-managed StackSets in an org

If the accounts are in an Organizations-enabled org, service-managed permissions plus auto-deployment is the right answer. Self-managed is only correct for cross-org or non-org targets.

Trap 7: Assuming you can re-home the Control Tower landing zone region

The Control Tower home region is set at landing-zone creation and cannot be changed. You can add or remove governed regions but the Log Archive and Audit accounts stay anchored to home.

Trap 8: Forgetting that the management account ignores SCPs

We said it twice already because the exam tests it three times.

Decision Matrix — Multi-Account Security Goals to Controls

FAQ — Multi-Account Strategy for SCS-C02

Q1: An account in our org is suspected to be compromised. What is the fastest containment action that affects the entire account, not just one resource?

Move the account to a dedicated Quarantine or Suspended OU that has a deny-all SCP attached. SCPs evaluate before IAM policies, so within seconds every API call from every principal in that account starts failing AccessDenied. This stops further data exfiltration, stops the attacker from creating new IAM access keys, stops them from modifying CloudTrail. Then, with the account effectively frozen, you triage in detail: pull EBS snapshots into the Forensics account, query Detective for the principal's behavior, query the Log Archive bucket via Athena for historical activity, and only re-enable specific actions through SCP exceptions as the IR plan requires. Cross-link: incident-response-isolation-forensics.

Q2: Why is "centralize security tooling in the Audit account via delegated admin" almost always the right answer on SCS-C02?

Three reasons. First, blast radius: if SecOps engineers had IAM in the management account, any phished credential could destroy the org. Delegated admin keeps the management account empty of routine human activity. Second, least privilege: the integration's service-linked roles grant exactly the cross-account scopes needed (read GuardDuty findings, write Security Hub config) and no more. Third, scale: enabling Security Hub or GuardDuty for the org from a delegated admin is a single click that cascades to every member account, including future ones; doing it per-account does not scale past a handful of accounts. The exam's answer choices that route SecOps work through the management account are testing whether you know to avoid this anti-pattern.

Q3: How do Control Tower mandatory controls relate to compliance frameworks like PCI-DSS or NIST 800-53?

Mandatory controls protect the landing zone itself — they are not designed against any external compliance framework. Strongly-recommended controls cover the broad-strokes hygiene (no public log buckets, MFA on root, encryption at rest defaults). To map to specific frameworks, you enable the framework's Security Hub standards (PCI-DSS, NIST 800-53 Rev 5, CIS AWS Foundations Benchmark, AWS Foundational Security Best Practices) at the OU level via the unified Controls Catalog in Control Tower. Audit Manager then collects the evidence those Security Hub controls produce. So the layering is: Control Tower mandatory + strongly-recommended (your floor) → Security Hub framework standards (your compliance posture) → Audit Manager assessments (your evidence packs for the auditor).

Q4: We have 50 accounts and the auditor wants proof that every S3 bucket has Block Public Access enabled. How do I produce that evidence?

Use the AWS Config aggregator in the Audit account (delegated admin). Either query the managed Config rule s3-bucket-level-public-access-prohibited across the aggregator (SELECT accountId, resourceId, configuration.publicAccessBlockConfiguration FROM aws:s3:bucket WHERE ...), or pull the rule's compliance status report directly. The aggregator returns one row per bucket per account with compliance state. Export to CSV, attach as audit evidence. For continuous evidence collection across multiple buckets and frameworks, an Audit Manager assessment using AWS Config as an evidence source automates the same query on a schedule and packages results into framework-specific reports. SCPs and Control Tower elective controls add the preventive backstop that stops developers from disabling Block Public Access in the first place.

Q5: A developer in a Sandbox account opened a support case complaining that they cannot launch a g5.12xlarge GPU instance for a quick test. The IAM policy explicitly allows ec2:RunInstances. Why is the call failing?

The Sandbox OU likely has an allow-list SCP that detaches FullAWSAccess and lists only cheap services, or a deny SCP that blocks expensive instance families using ec2:InstanceType conditions. SCPs evaluate before the IAM policy, so even a permissive identity-based allow does not unlock the action. Confirm by walking the evaluation chain in CloudTrail: a DENIED decision with AccessDenied and a reason code referring to an SCP shows up in the failed RunInstances event. The right response depends on policy: either run the experiment in an account where the allow-list permits GPU, update the Sandbox SCP carefully (with a tag-based condition like Experiment: GPU and a matching budget alarm), or refuse the request because Sandbox is not where GPU experiments belong. The general lesson: when an exam scenario says "IAM allows X but the call fails", suspect SCP first, then permissions boundary, then resource policy or session policy. Cross-link: every multi-account auth-failure question on SCS-C02 reduces to walking this ladder.

Q6: Can I use AWS Organizations and SCPs without AWS Control Tower?

Yes. AWS Organizations is the underlying service; Control Tower sits on top with opinions. Many security-mature orgs run a Terraform-managed landing zone via AWS Control Tower Account Factory for Terraform (AFT) or a custom IaC pipeline, and use Organizations directly for SCPs, delegated admins, and the Config aggregator. Those orgs still get the full SCP, tag-policy, backup-policy, AI-opt-out, chatbot-policy, and delegated-admin surface — those are Organizations features. They just hand-roll the Log Archive / Audit account topology and the controls catalog instead of accepting Control Tower's defaults. For SCS-C02, when a scenario says "the security team wants the fastest path to a managed best-practice baseline" the answer is Control Tower; when it says "the security team wants Terraform-driven infrastructure with no AWS-managed opinion" the answer is Organizations with AFT or custom IaC.

Q7: How do I prevent a privileged user in a member account from disabling GuardDuty or Security Hub during an attack?

Two layers. First, an audit-tamper deny SCP at the org root denying guardduty:DeleteDetector, guardduty:DisassociateFromMasterAccount, securityhub:DisableSecurityHub, securityhub:DisassociateFromMasterAccount, plus the analogous Macie, Detective, and Inspector disable actions. Even a member-account administrator cannot bypass this because SCPs are evaluated above IAM. Second, since these services are configured under delegated admin from the Audit account, only principals in the Audit account (with the necessary IAM permissions) can disable them at the org level — the member-account admin literally has no delegation surface to call. Pair both layers with a Control Tower drift detection alarm and a CloudTrail metric filter on the disable API names so any attempt (even a denied one) generates a SOC alert. Cross-link: threat-detection-guardduty-securityhub.

Q8: What is the difference between a Control Tower preventive control and a deny SCP I write myself?

Mechanically nothing — Control Tower preventive controls are SCPs. The differences are operational. A Control Tower control is named, versioned, and AWS-maintained in the Controls Catalog: it shows up in the Control Tower console with its description, intent, and compliance evidence, and AWS updates it as the threat landscape changes. A hand-written SCP is yours to maintain — you author the JSON, attach it, version-control it, and the auditor must take your word for what it does. For broadly applicable controls (deny disabling CloudTrail, deny public S3 buckets), prefer the Control Tower control because it gives you free maintenance and audit-mapping. For org-specific risks (deny our specific KMS key from being deleted, deny unapproved instance families) write your own SCP. Most organizations end up with a mix of both, and Control Tower's catalog plus your custom SCPs together form the full preventive layer.

Further Reading

• AWS Organizations User Guide
• Service Control Policies
• SCP Evaluation Logic
• SCP Strategies and Examples
• AWS Control Tower User Guide
• Control Tower Controls (Guardrails) Reference
• Control Tower Drift Detection
• AWS Services that Integrate with Organizations (delegated admin list)
• Managing GuardDuty Multi-Account
• Managing Security Hub Multi-Account
• Managing Macie Multi-Account
• Managing Detective Multi-Account
• Config Multi-Account Multi-Region Aggregation
• AWS Account Root User
• Organizing Your AWS Environment Using Multiple Accounts (Whitepaper)
• AWS Security Reference Architecture (SRA)
• AWS SCS-C02 Exam Guide