A platform team lets developers create their own IAM roles for application workloads using a self-service pipeline. The team must guarantee that no role a developer creates can ever grant more than a fixed set of services, even though developers attach their own permissions policies. Which AWS mechanism enforces this maximum without the team reviewing each policy?
- AApply a service control policy at the developer account that denies the disallowed services, relying on it to cap the permissions of every workload role the developers create.
- BAdd a resource-based policy to each workload service that lists the allowed roles, so any role outside that list is automatically prevented from calling the disallowed services.
- CConfigure an IAM access analyzer policy that flags any developer role exceeding the allowed services, so the pipeline can reject it before the role becomes active in the account.
- DAttach a permission boundary to each developer-created role that defines the maximum services allowed, so the role's effective permissions are the intersection of its policies and the boundary. Correct
Why A is wrong: An SCP caps an entire account or organisational unit, so it cannot target only developer-created workload roles while leaving the team's own roles unaffected.
Why B is wrong: Resource-based policies are attached to resources, not identities, and would require editing every resource rather than capping what a created role can do.
Why C is wrong: Access Analyzer detects and reports excessive access but does not enforce a hard ceiling, so a role could still be created and used before review.
Why D is correct: A permission boundary sets the maximum permissions an identity can have; effective access is the intersection of the boundary and attached policies, so extra permissions never take effect.