A company has an organization with SCPs in AWS Organizations. The root SCP for the organization is as follows: The company's developers are members of a group that has an IAM policy that allows…

Question

Exhibit

Options

• AAdd a resource policy that allows each member of the group to access Amazon SES.
• BAdd a resource policy that allows "Principal": {"AWS": "arn:aws:iam::account-number:group/Dev"}.
• CRemove the AWS Control Tower control (guardrail) that restricts access to Amazon SES.
• DRemove Amazon SES from the root SCP.

• A
  11% (2)
• B
  11% (2)
• C
  6% (1)
• D
  72% (13)

Explanation

Option D is correct because SCPs form a hierarchical permission boundary - the root SCP sets the maximum permissions allowed across the entire organization. Even though the child OU SCP and the IAM group policy both permit SES, an SCP at the root that excludes SES acts as a hard ceiling, blocking access for all accounts beneath it. Effective permissions require alignment at every level: root SCP → OU SCP → IAM policy. Since the root SCP is the blocker, it must be fixed there.

Why the distractors are wrong:

• A & B are wrong because Amazon SES does not support resource-based policies in the way services like S3 or KMS do - you cannot attach a resource policy to SES. Even if you could, SCPs are a hard boundary that resource policies cannot override.
• C is wrong because AWS Control Tower guardrails are a separate concept. While some guardrails are implemented via SCPs, the question specifically describes an SCP issue at the root level, not a Control Tower guardrail.

Memory tip: Think of SCPs as a "security fence" stacked from the outside in - the root SCP is the outermost fence. No inner fence or key (IAM policy) can grant access through the outer fence. When access is denied despite valid IAM permissions, always audit the SCP chain from root downward first.

No community discussion yet for this question.