A company uses AWS Organizations to centrally manage multiple AWS accounts. The security team requires that no IAM users can be created in any member account. All access must use federated identities from the company's existing identity provider. The security team needs a single, centralized mechanism to enforce this restriction across all existing and future member accounts. Which AWS feature should the security team use to meet this requirement?
SCPs are a centralized policy mechanism within AWS Organizations that can deny the IAM:CreateUser action across all member accounts in an organization, OU, or specific account. SCPs apply to all principals, including the root user, and affect both existing and future accounts, making them the correct choice for enforcing this restriction.
Why this answer
AWS Organizations service control policies (SCPs) allow a central administrator to define maximum permissions for all accounts within an organization. By creating an SCP that explicitly denies the `iam:CreateUser` action, the security team can enforce that no IAM users can be created in any member account, including future accounts, because SCPs are inherited by all accounts in the organization. This provides a single, centralized mechanism that cannot be overridden by account-level IAM policies.
Exam trap
The trap here is that candidates often confuse SCPs with IAM policies, thinking IAM policies can centrally control all accounts, but SCPs are the only mechanism that can enforce restrictions across an entire AWS Organization, including preventing the creation of IAM users.
How to eliminate wrong answers
Option A is wrong because IAM policies are attached to IAM users, groups, or roles within a single account and cannot enforce restrictions across multiple accounts or prevent the creation of IAM users themselves; they only control permissions for existing identities. Option C is wrong because AWS Config managed rules can detect non-compliant resources (e.g., an IAM user being created) and trigger automatic remediation, but they are reactive and cannot prevent the creation of IAM users in the first place; they also require per-account setup and do not centrally block the action. Option D is wrong because IAM Access Analyzer analyzes resource-based policies to identify unintended cross-account access, but it does not enforce restrictions on IAM user creation or provide any preventive control.