To allow only creation/configuration of service-linked roles , you need a way to tightly scope what IAM actions the developer can perform. The most AWS-appropriate mechanism for “delegate limited IAM admin” is a role with a permissions boundary :

A permissions boundary sets the maximum permissions the role (and any roles it creates, depending on design) can ever have. This is a standard pattern to safely delegate IAM tasks without granting broad IAM administration.

You can define the role’s policy + boundary so the developer can call only the APIs required for service-linked roles (for example actions like creating service-linked roles and passing only allowed AWS service principals), while preventing general role/policy creation outside that scope.

Why the others don’t meet “service-linked roles only”:

A is vague (“common services”) and cross-account access doesn’t inherently restrict to only service-linked roles. It’s also more operational overhead than needed for a single dev account use case.

B PowerUserAccess is far too broad and does not restrict to service-linked roles.

C An SCP with Deny iam:* would block IAM entirely (including what the developer needs). Even if refined, SCPs set account-wide guardrails and are not the right tool to grant a single developer the precise ability to create only service-linked roles.