A new account was created and left in the organization root, outside the production OU. The production OU's SCP denies a Region, and the new account can still use that Region. Why was the guardrail missed?
Select an answer to reveal the explanation.
Short Explanation
You can think of the OU as a room with a guardrail at its door; this account was left outside it. Move the account into the production OU, and age, launching an instance, or S3 versioning won’t determine whether the SCP applies.
Full Explanation
An SCP attached to an OU applies to accounts in that OU and its child OUs. Because the new account was left in the organization root, outside the production OU, it did not inherit that OU’s Region deny; moving it into the production OU brings it under the guardrail without requiring the SCP to be rewritten. The account’s age does not determine SCP inheritance, and launching a first instance is not required for an SCP to apply. S3 versioning also has no bearing on whether the Region deny is enforced. Caveat: an SCP attached to the organization root would apply across the organization, but this SCP is attached to the production OU, so account placement matters. Practical check: after moving the account, confirm that it appears in the production OU and try to create a resource in the denied Region; the request should be denied. If it succeeds, verify that the account has actually been moved into the OU. The guardrail was missed because the account was outside the scope of the OU policy, not because it was new, had not launched an instance, or lacked S3 versioning.