Organization-wide security controls

A guardrail nobody monitors drifts silently, and a finding you can never prevent recurs forever, which is why org-wide security at the professional level is always two cooperating layers and never one. Preventive controls stop a disallowed action before it happens; detective controls find what slipped through. Almost every SAP-C02 security scenario is really asking which layer (and which service in it) the requirement maps to, and an answer that leans on only one layer is a recurring distractor.

Preventive: the ceiling is a filter, never a grant

The preventive primitives in AWS Organizations are service control policies (SCPs)^[1], which cap what principals in member accounts may do, and resource control policies (RCPs)^[2], which cap what may be done to resources in member accounts. The single most-tested fact about both: they only filter the maximum permissions; neither one ever grants anything. Effective access is the logical intersection^[4] of every policy type that applies: the SCP AND the RCP AND the identity-based policy AND (where present) the resource-based policy AND the permissions boundary must all allow the action, and an explicit Deny at any one layer is terminal. Remove the IAM Allow and no SCP can resurrect access.

Both SCPs and RCPs skip the management account and service-linked roles, so they cannot constrain root in the management account, which is exactly why workloads and day-to-day administration belong in member accounts. RCPs additionally require all-features mode^[2] and apply only to a subset of services^[2]: the supported list includes Amazon S3, AWS STS, AWS KMS, Amazon SQS, AWS Secrets Manager, Amazon Cognito, CloudWatch Logs, and Amazon DynamoDB, among others. RCPs do not affect AWS managed KMS keys.

A third instrument: the permissions boundary

When the requirement is to cap one IAM identity rather than a whole OU (a delegated-admin user, a CI role, a developer who must be allowed to create roles but not escalate) the right tool is a permissions boundary^[4], the IAM-level ceiling attached to a single user or role. Like an SCP it only filters: the boundary, any SCP in scope, and the identity-based policy must all allow the action. Reaching for an org-wide SCP to constrain a single principal, or a permissions boundary to govern an entire OU, is the classic wrong-instrument trap.

Detective: aggregate signal into dedicated accounts

The detective layer is Amazon GuardDuty^[5] (threat detection from logs and telemetry), AWS Security Hub^[11] (posture aggregation and standards scoring), Amazon Macie (sensitive-data discovery in S3), AWS Config^[8] (configuration compliance and change history), IAM Access Analyzer^[9] (external and unused access), and Amazon Detective^[12] (investigation and root-cause analysis). The architectural rule is to centralize: aggregate every account's findings, logs, and compliance state into purpose-built Security/Audit and Log Archive accounts so an analyst reasons over the whole organization in one place. The account-vending and OU structure that hosts those accounts is governance plumbing covered by multi-account-environment; this subtopic prescribes the controls layered on top.

Every org-integrated security service supports registering a delegated administrator: a dedicated member account (commonly a Security or Audit account) from which you operate the service instead of the management account. This is not merely tidy; it is a least-privilege control. Because SCPs and RCPs skip the management account^[1] but do apply to member accounts, a delegated-admin account is itself constrained by your guardrails, whereas administration done from the management account would be exempt. The management-account best practice^[13] is to keep as few humans in it as possible. The diagram captures that hierarchy: the management account sits above the guardrails, the delegated Security or Audit account runs the services in the middle, and the member accounts it governs sit beneath.

GuardDuty: Regional, with NEW vs ALL auto-enable

GuardDuty is a Regional service. You must designate the same member account as delegated administrator in every Region^[5] you want governed; there is no single global switch. From that account you set organization auto-enable to NEW (new accounts only) or ALL (new and existing); choose ALL so every current and future member gets continuous threat detection. A single GuardDuty delegated administrator can manage a maximum of 50,000 member accounts per Region^[5]; an organization can hold more than 50,000 accounts, but one delegated admin still cannot exceed that ceiling in a single Region (you receive a CloudWatch, Health Dashboard, and email notification when you approach it).

Security Hub: central configuration

Security Hub aggregates findings in the AWS Security Finding Format (ASFF) from GuardDuty, Amazon Inspector, Macie, and IAM Access Analyzer, giving one pane of glass, and scores accounts against standards including AWS Foundational Security Best Practices (FSBP), the CIS AWS Foundations Benchmark, NIST SP 800-53 Rev 5, NIST SP 800-171, and PCI DSS. Its central configuration^[11] lets the delegated admin define configuration policies (enable or disable Security Hub, standards, and individual controls) that apply to OUs, accounts, and the root as centrally managed, while designated targets stay self-managed. Central configuration takes effect in the home Region plus linked Regions and covers new and existing accounts, eliminating per-account, per-Region drift.

Macie, Config, and Access Analyzer org-wide

Amazon Macie^[10] runs automated sensitive-data discovery across Amazon S3 (classifying PII, credentials, and financial data, and reporting bucket-level public-access and encryption posture) and is enabled org-wide from a delegated admin. AWS Config^[8] records configuration and change history; an organization aggregator plus organization Config rules and conformance packs give org-wide compliance evaluation, but the Config recorder must be on in each account, and Config flags non-compliant resources rather than blocking them. IAM Access Analyzer^[9] set with the AWS Organization as its zone of trust flags resources shared outside the org. Its pricing split is a frequent exam detail: external-access analysis is free^[14] while a separate unused-access analyzer (dormant roles, permissions, and credentials) is billed per IAM role or user analyzed per month.

Detective: investigate, do not detect

Amazon Detective^[12] is the investigation layer, not another detector. It automatically extracts time-based events from AWS CloudTrail and Amazon VPC Flow Logs and ingests GuardDuty findings, then uses machine learning and graph theory to build a behavior graph for root-cause analysis across up to a year of history. It is integrated with AWS Organizations: the management account designates a Detective administrator account that enables members into the organization behavior graph, and you pivot directly from a GuardDuty or Security Hub finding into Detective. Choosing Detective when a scenario asks to detect (rather than investigate) a threat is a trap; that is GuardDuty's job.

IAM Identity Center delegation is narrower

Workforce access via IAM Identity Center^[15] also supports a delegated administrator, but with an important asymmetry: the Identity Center instance must always reside in the management account, and a delegated admin cannot modify permission sets that grant access to the management account. Delegating Identity Center reduces who needs management-account access without surrendering control of management-account access itself.

Once the guardrails and detective services are in place, the remaining controls protect the data those layers generate and consume: centralizing the audit trail, governing the encryption keys, and gating cross-account access. This section walks those three in order.

Organization CloudTrail to one log-archive account

A single organization trail^[7] in AWS CloudTrail captures every member account's management events (and, optionally, data events) into one S3 log-archive bucket in a dedicated account. Created from the management account or a CloudTrail delegated administrator, it applies to all members, including accounts that join later, and members cannot remove or alter it, giving tamper-resistant central audit logs that pair with Security Hub and Config. The bucket policy must allow each member account's delivery, which the organization-trail flow configures for you.

KMS: key policy, IAM, and grants

Every customer-managed KMS key has a key policy (a resource policy on the key itself) that is the root of trust for that key. For cross-account use, the key policy in the owner account AND an IAM policy in the external account must both allow the operation; neither alone is sufficient^[16]. The key policy decides who can be given access; the IAM policy decides who does. The diagram renders this two-key requirement as a single gate: only when both the owner-account key policy and the external-account IAM policy allow does the cross-account operation succeed. AWS managed KMS keys cannot be shared cross-account this way.

A grant^[17] is the third KMS access instrument and the one purpose-built for temporary, programmatic, granular delegation, exactly how AWS services that integrate with KMS encrypt your data at rest. Grant facts the exam leans on:

• A grant can allow access to a KMS key but cannot deny^[17]; it is purely additive, like an SCP/RCP is purely subtractive.
• Each grant allows access to exactly one KMS key^[17], and you can create a grant for a key in a different account.
• The grantee can be an IAM identity or a service principal, but not an AWS organization or IAM group^[17]; grants do not target an org the way an SCP does.
• Grant changes follow an eventual-consistency^[17] model; use a grant token to exercise a new grant's permissions immediately.
• KMS limits each key to 50,000 grants^[17].

Scheduling deletion of a customer-managed key enforces a mandatory 7-to-30-day waiting period (default 30 days)^[18]; deletion is never immediate and is cancellable until the window ends.

Secrets, certificates, and the perimeter

For credential hygiene, AWS Secrets Manager managed rotation^[19] (no Lambda required) covers Aurora, RDS, DocumentDB, and Redshift; custom secrets still need a rotation Lambda implementing the four-step contract. For data in transit, AWS Certificate Manager^[20] issues and auto-renews free public certificates whose private key never leaves AWS, but note the Region rule: an ALB certificate must be in the same Region as the load balancer, while a CloudFront certificate must be in us-east-1 regardless of where the distribution serves. To enforce an organization data perimeter at the resource edge, an RCP^[2] using aws:PrincipalOrgID (with a carve-out for aws:PrincipalIsAWSService) denies any principal outside the org from reaching supported resources such as S3 buckets and KMS keys.

SAP-C02 security questions almost always describe a multi-account organization and ask for the one control that satisfies a precise requirement at the lowest operational overhead. Match the stem's verb and object to the layer first, then to the service.

Pattern 1: "prevent ... across all accounts"

Stem: "A company must ensure no member account can launch resources outside two approved Regions, including accounts added later." Correct: an SCP^[1] with a Deny on aws:RequestedRegion (carving out global services like IAM, STS, CloudFront, Route 53, Support via NotAction), attached at the root or a parent OU so inheritance covers future accounts. Why distractors fail: an IAM policy in each account does not stop a future account and is per-account toil; an SCP that grants the two Regions is wrong by construction (SCPs never grant); AWS Config can report out-of-Region resources but cannot prevent them.

Pattern 2: "block anyone outside the organization from reaching our resources"

Stem: "Prevent any principal not in the organization from accessing our S3 buckets and KMS keys, org-wide." Correct: an RCP^[2] denying access when aws:PrincipalOrgID does not match, with an aws:PrincipalIsAWSService carve-out, attached high in the OU tree. Why distractors fail: an SCP constrains your principals, not external ones touching your resources; bucket policies on every bucket are per-resource sprawl that misses new buckets; RCPs additionally require all-features mode, so a billing-only org is a setup trap.

Pattern 3: "cap one privileged identity"

Stem: "The DevOps team has admin in their account and must be allowed to create IAM roles, but must not be able to grant those roles permissions beyond an approved set." Correct: a permissions boundary^[4] attached to the team's roles, plus a condition requiring the boundary on any role they create. Why distractors fail: an org-wide SCP would constrain the whole account, not just that team; the SCP-only answer cannot express 'roles you create must also carry this boundary'.

Pattern 4: "detect / one pane of glass / investigate"

Stem A ("continuously detect crypto-mining and credential exfiltration across every account and Region") → Amazon GuardDuty^[5] from a delegated admin with auto-enable ALL, per Region. Stem B ("a single place to triage all findings and benchmark accounts against CIS and PCI DSS") → AWS Security Hub^[11] with central configuration. Stem C ("after a GuardDuty alert, determine the root cause and full blast radius from CloudTrail and VPC flow history") → Amazon Detective^[12]. Why distractors fail: Security Hub aggregates but does not itself detect threats; Detective investigates but does not generate the original findings; Config tracks configuration drift, not threat telemetry.

Pattern 5: "least privilege / unused access / external sharing"

Stem: "Identify IAM roles, users, and credentials that have not been used so the team can prune them, AND flag any resource shared outside the org." Correct: IAM Access Analyzer^[9] at the organization zone of trust. External-access findings (free^[14]) plus a separate unused-access analyzer (paid per role/user). Why distractors fail: Macie finds sensitive data in S3, not unused IAM permissions; GuardDuty finds active threats, not dormant entitlements; reading CloudTrail by hand is the brute-force non-answer.

Pattern 6: "mandate WAF / firewall rules on every account"

Stem: "Ensure AWS WAF is attached to every ALB across 200 accounts and auto-remediate new ones." Correct: AWS Firewall Manager^[3] policies (WAF, Shield Advanced, security-group, Network Firewall, Route 53 Resolver DNS Firewall) from a Firewall Manager admin account. Trap: Firewall Manager has a hard prerequisite. AWS Config must be enabled^[21] in every account and Region a policy scopes, plus an Organization with all features; an option that skips enabling Config is wrong.

Pattern 7: "share central infrastructure, encrypt cross-account"

Stem: "Workload accounts must use a central KMS key / a central VPC's subnets without each rebuilding them." Correct: for KMS, a key policy in the owner account plus IAM in the consumer account (or a grant^[17] for temporary service-driven use); for networking, share subnets via AWS Resource Access Manager. Why distractors fail: an IAM policy alone cannot reach a cross-account key without the key policy allowing it^[16]; copying the key into each account defeats centralized key management and rotation.