A company uses AWS Organizations to manage a set of AWS accounts. The company has set up organizational units (OUs) in the organization. An application OU supports various applications. A SysOps…

Question

Options

• ACreate an IAM group that has a policy that allows the ec2:RunInstances action when the
• BCreate a service control policy (SCP) that denies the ec2:RunInstances action when the
• CCreate an IAM role that has a policy that allows the ec2:RunInstances action when the
• DCreate a service control policy (SCP) that denies the ec2:RunInstances action when the

• A
  3% (1)
• B
  77% (27)
• C
  6% (2)
• D
  14% (5)

Explanation

Option B is correct because Service Control Policies (SCPs) are the only mechanism that can enforce guardrails across all accounts within a specific OU - attaching a deny SCP to the application OU that blocks ec2:RunInstances when the CostCenter-Project tag is absent ensures no account in that OU can bypass the requirement, regardless of what IAM policies individual accounts have.

Options A and C are wrong because IAM groups and roles are account-scoped constructs - they must be configured individually in each account and cannot be deployed organization-wide at the OU level, making them unscalable and unreliable for this requirement.

Option D is wrong because it likely attaches the SCP to the organization root rather than the application OU - this would apply the restriction to all accounts in the organization, violating the requirement that it apply only to the application OU.

Memory tip: Think of SCPs as a "permission ceiling" set by the organization - IAM policies work within that ceiling but can never exceed it. Whenever you see "must apply to all accounts in an OU," SCPs are the answer; whenever you see "must apply only to accounts in a specific OU," attach the SCP to that OU, not the root.

No community discussion yet for this question.