Multi-Account Governance — AWS DevOps Engineer (DOP-C02)
Policy Scope Determines Which Service Belongs Here
AWS Organizations SCPs deny actions at the account or OU level — they cap what even an account administrator can do. AWS Config rules evaluate resource configuration state against compliance rules, account by account. Control Tower combines both with a managed landing zone and guardrail framework. IAM Identity Center handles federated identity across accounts. Scenarios are precise about whether the requirement is preventive, detective, or identity-based. Applying a detective control to a preventive requirement, or vice versa, is the primary failure mode on multi-account governance questions.
What This Pattern Tests
The exam describes a multi-account environment and tests governance controls. AWS Organizations groups accounts into OUs. SCPs on OUs set maximum permission boundaries — they deny, never grant. CloudTrail organization trails aggregate audit logs. AWS Config aggregator collects compliance data across accounts. RAM (Resource Access Manager) shares resources across accounts without duplication. The trap is using SCPs to grant permissions (they only restrict) or creating cross-account IAM users instead of cross-account roles (roles use temporary credentials).
Decision Axis
Governance scope determines the tool: organization-wide restriction = SCP, account-specific permission = IAM, cross-account sharing = RAM/roles, compliance visibility = Config aggregator.
Associated Traps
Decision Rules
Select organizational-level preventive enforcement (SCP deny via AWS Organizations, enforced automatically at account enrollment by Control Tower) over account-level detective controls (Config rules with auto-remediation) when the requirement is to block a disallowed API call before it executes rather than detect and correct it afterward.
When a compliance constraint requires that member accounts cannot perform a specific action against a centralized resource, an SCP applied at the Organizations root or OU provides preventive, zero-per-account-overhead enforcement that is automatically inherited by every newly vended account, whereas per-account Config rules with Lambda auto-remediation introduce compounding deployment burden, Lambda failure modes, and only detective (post-violation) coverage.
When the requirement is to block a privileged action before it occurs across a defined set of accounts, a deny-based SCP scoped to the relevant OU is the correct control; any solution that adds landing-zone enrollment, conformance packs, or detective-remediation loops overreaches the stated constraint.
Whether to enforce the approved-region constraint via a targeted Deny SCP on the production OU in AWS Organizations — preventive, zero per-account deployment, and non-overridable by member accounts — versus implementing a broader solution such as a Control Tower landing zone rebuild, Account Factory customization pipeline, or per-account Config rule with Lambda auto-remediation.
Domain Coverage
Difficulty Breakdown