Which solution will meet these requirements?
Create an IAM user for the developer in the organization’s management account. Configure a cross-account role in the development account for the developer to use. Limit the scope of the cross-account role to common services.
Add the developer to an IAM group. Attach the PowerUserAccess managed policy to the IAM group. Enforce multi-factor authentication (MFA) on the user account.
Add an SCP to the development account in Organizations. Configure the SCP with a Deny rule for iam:* to limit the developer’s access.
Create an IAM role that has the necessary IAM access to allow the developer to create policies and roles. Create and attach a permissions boundary to the role. Grant the developer access to assume the role.
Explanations:
This option involves creating a cross-account role in the management account, which is unnecessary since the developer is working within the same development account. Service-linked roles can be created directly in the development account without needing cross-account access.
The PowerUserAccess policy grants extensive permissions to the developer, allowing them to perform almost any action except for IAM role and policy management. This does not restrict the developer to only create service-linked roles and could lead to security risks.
Adding an SCP with a Deny rule foriam:*would effectively block all IAM actions, including the creation of service-linked roles, which contradicts the requirement for the developer to have the ability to create and configure these roles.
This option allows for the creation of a specific IAM role that grants the necessary permissions to create service-linked roles. By using a permissions boundary, the scope of actions can be further limited, ensuring that the developer can only perform the desired actions without broader IAM access.