An SCP attached to your AWS organization root denies `s3:DeleteBucket`, yet an administrator in the management account deletes a bucket successfully. Why, and what does that imply for how the management account should be used?
answer
- the governor is not governed
- otherwise you could lock yourself out
- service-linked roles are exempt too
- empty control plane, break-glass only
- delegate org tooling to a security account
basics
~20 sService control policies never restrict principals in the management account, no matter where the policy is attached. Because the organization's own guardrails do not apply there, the management account should hold no workloads and very few principals.
solid answer
~50 sSCPs govern member accounts only. The management account is exempt by design, so a Deny attached to the organization root silently does not apply to it — and there is no setting that changes this. Two consequences follow. First, any workload you run in the management account is running outside every guardrail your organization has: no region lock, no protected trail, no protected roles. Second, the account that can attach and detach SCPs is the same account that ignores them, so a compromised principal there is an organization-level compromise, not an account-level one. The standard response is to treat it as an empty control plane: no applications, no data, no CI roles, no day-to-day human logins. Governance duties that others need — audit tooling, security services — get delegated to purpose-built member accounts using delegated administration, so people work there instead. Service-linked roles are similarly exempt everywhere, which is worth knowing before you conclude a Deny has failed.
go deeper
Remember the fact itself: SCPs apply to member accounts, never to the management account, and there is no setting that changes it.
Explain why — the account that attaches and detaches SCPs must stay outside them or a bad policy would be unrecoverable — and know that service-linked roles are exempt everywhere too.
Draw the operational conclusion: no workloads, no CI roles and almost no humans in the management account, organization trails delivered to a separate log archive account, and org-wide tooling moved out via delegated administration.
Own the threat model. Management-account credentials are organization-ending rather than account-ending, so access to it is a governance decision — who may hold it, under what process, and how any use is detected — not an IAM detail.
## The rule **SCPs do not affect principals in the management account.** Not when attached to the root, not when attached to an OU, not when attached to the management account itself. This is documented behaviour, not a bug and not a misconfiguration, and there is no toggle to turn it on. The reasoning is a lockout guard. The management account is where SCPs are created, attached and detached. If the ceiling could apply there, a badly written Deny would be unrecoverable: you would have denied yourself the ability to remove the Deny. AWS resolves that by putting the account that governs the organization outside its own governance. ## What else is exempt The management account is the big one, but it is not alone: - **Service-linked roles.** Roles that an AWS service creates and controls to act on your behalf are never restricted by SCPs, so services can perform their own internal work regardless of what you deny. This is a frequent source of "my Deny doesn't work" confusion — the caller was a service-linked role. - **Principals outside your organization.** A role in another company's account accessing your resources is bounded by their organization, not yours. Bounding what external principals can do to *your* resources requires a resource-side control instead. ## The practical conclusion: keep it empty If the guardrails do not apply, then everything you rely on them for is absent: - A region-lock SCP does not stop resources being created anywhere in the management account. - An SCP protecting CloudTrail, GuardDuty or Config from being disabled does not protect them there. - An SCP protecting your landing zone's roles does not protect them there. So the management account gets treated as a control plane, not a workload account: 1. **No applications, no data, no queues, no databases.** If it holds nothing of value, compromising it yields organization control but no direct data. 2. **Almost no principals.** No CI/CD roles, no developer access, no long-lived IAM users with access keys. Human access is break-glass, with strong MFA, and every use is expected to be noticed. 3. **Nothing depends on it at runtime.** If a production service needs a role in the management account to work, you have just made that account load-bearing and given yourself a reason to loosen it. 4. **Its own activity is logged elsewhere.** The organization's trail should deliver to a separate, locked-down log archive account, so that someone with power in the management account cannot quietly erase the record of what they did. ## Delegated administration is how you keep it empty Many org-aware services — audit and detection services, IAM analysis tooling, backup, and others — support registering a **delegated administrator**: a member account allowed to run the organization-wide view of that service. Doing this for each service is what makes the "empty management account" practical rather than aspirational, because the people who need to *use* org-wide tooling can then do it from a security account that *is* subject to SCPs and *is* safe to grant access to. The usual landing-zone shape reflects this: a Security OU containing a log archive account and an audit/security-tooling account, both member accounts, with the management account doing nothing but owning the organization and the bill. ## Reasoning about the blast radius When you interview on this, the point to land is not the trivia that the management account is exempt. It is what that exemption does to your threat model. Credentials that are powerful in a member account cost you that account. Credentials in the management account cost you the ability to constrain any account — attach an SCP, detach one, create a new account outside your controls, or move the organization's accounts elsewhere. Recovery is not "restore a backup"; it is a rebuild. That asymmetry is why the management account should have fewer humans with access than any production database, and why the answer to "can we just run this one small tool there?" is no.
- Why did AWS design the management account to be exempt rather than let you opt in?Because SCPs are attached and detached from the management account. If a Deny applied there, one bad policy could remove your ability to remove the policy, and the organization would be unrecoverable without AWS support. Exempting the account that governs the organization is the lockout guard. The cost is that the exemption is permanent, which is exactly why the account is kept empty.
- If SCPs cannot constrain the management account, what actually limits what happens there?Only IAM inside that account, plus whatever process you wrap around it. That means very few principals, no long-lived access keys, mandatory MFA, break-glass procedures, and detective controls rather than preventive ones — its CloudTrail events delivered into a separate log archive account that management-account principals cannot alter, with alerting on any use at all.
- An SCP denies an action, but you see the action succeeding in a member account. What non-obvious cause should you check?Whether the caller was a service-linked role, which SCPs never restrict, so an AWS service performing its own internal work is unaffected. Also check whether the caller is external to your organization, since SCPs bound your principals rather than access to your resources, and confirm the account really sits under the OU you attached the policy to.
saying these in an interview costs you the question
- Assumes attaching the SCP to the management account itself will work
- Runs shared tooling or CI in the management account
- Thinks a service-linked role obeys SCPs
- Gives developers day-to-day access to the management account
- Keeps the organization trail only in the management account