Question

Difficulty: HardMulti-Account Management and Governance

A company is transitioning to a multi-account environment managed by AWS Organizations. The solutions architect is designing a centralized identity and governance strategy. The company plans to federate its corporate identity provider with AWS IAM Identity Center. The security team requires that no local IAM users or programmatic access keys be created within any member accounts, except for a pre-authorized emergency break-glass role. The management account must remain unaffected to ensure emergency access is not locked out. Which strategy should the solutions architect recommend to meet these requirements with the least operational overhead?

  1. Create a Service Control Policy (SCP) that denies the iam:CreateUser and iam:CreateAccessKey actions unless the caller is the emergency break-glass role, and attach this SCP to the Organizational Units containing the member accounts.Answer
  2. B
    Manually create IAM users in each member account corresponding to corporate identity provider groups, and attach an IAM policy to each user denying the iam:CreateUser and iam:CreateAccessKey actions.
  3. C
    Configure the root user of each member account to enforce local policies restricting IAM user creation, and perform daily administrative activities in the member accounts using these root credentials.
  4. D
    Create an IAM group in each member account with policies denying credential creation, and require administrators to log in using the management account's root user credentials to perform all member account administrative actions.

Answer

Create a Service Control Policy (SCP) that denies the iam:CreateUser and iam:CreateAccessKey actions unless the caller is the emergency break-glass role, and attach this SCP to the Organizational Units containing the member accounts.
The correct strategy uses AWS Organizations Service Control Policies (SCPs) to establish permission guardrails across Organizational Units (OUs) containing member accounts. By applying a condition that excludes the emergency break-glass role, the exception is maintained. Because SCPs do not restrict the management account, it remains unaffected by design, ensuring emergency access is preserved.

Step-by-Step Solution

1
Identify the governance requirement to restrict local IAM user and credential creation across member accounts while leaving the management account unaffected.
Realized that Service Control Policies (SCPs) applied at the Organizational Unit (OU) level are the standard mechanism to restrict permissions globally across target accounts without impacting the management account.
SCPs cannot restrict the management account itself, making them ideal to enforce policies on member accounts while leaving the management account unrestricted.
2
Formulate the policy rule to deny the specific IAM actions (iam:CreateUser and iam:CreateAccessKey).
Created a deny statement targeting the specific creation APIs.
This directly prevents the creation of local IAM users and long-term credentials.
3
Apply a condition to allow an exception for the emergency break-glass role.
Added a StringNotLike or StringNotEquals condition checking the caller's ARN against the break-glass role ARN.
This ensures the emergency recovery path remains functional even when the policy is active.

Key Concept

Enforcing security guardrails across multiple AWS accounts in an organization using Service Control Policies (SCPs) combined with AWS IAM Identity Center for centralized federation.
Rate this question