Delegating Role Creation Safely

Teams move faster when they can create their own IAM roles and policies, but unrestricted IAM access is dangerous: a developer could grant themselves administrator rights. The challenge is letting teams build roles while guaranteeing those roles stay within safe limits. Permission boundaries make this possible, a frequently tested exam scenario.

Without guardrails, giving someone iam:CreateRole and iam:AttachRolePolicy is effectively giving them admin. They could create a role with AdministratorAccess and assume it. This privilege-escalation path is exactly what safe delegation must close while still allowing legitimate role creation.

The solution: require that any role a delegated user creates must have a specific permission boundary attached. Even if they attach AdministratorAccess to the new role, the boundary caps its effective permissions. The created role can never exceed what the boundary allows, neutralizing the escalation risk.

A safe delegation policy uses two condition checks: one ensures the new role has the required boundary (via iam:PermissionsBoundary), and another restricts the user from modifying or deleting the boundary itself. Both are needed, or a clever developer could simply remove the boundary afterward.

This condition forces every CreateRole call to attach the named boundary. Without it, the create action is denied.

You must also deny the delegated user from editing the boundary policy or detaching it from roles. Add explicit Deny statements on actions like iam:DeleteRolePermissionsBoundary and iam:CreatePolicyVersion against the boundary ARN. Otherwise the guardrail can be quietly removed, defeating the whole design.

Delegation policies often restrict the path or naming of roles a user can create, for example only under /developers/. This contains their roles in a known namespace, making them easy to audit and preventing interference with privileged roles elsewhere in the account.

Even with a boundary, watch the new role's trust policy. A developer could create a role trusted by an external account. Restrict who they can set as trusted principals, or combine delegation with SCPs and Access Analyzer so unexpected external trust is caught and blocked.

Done correctly, delegation gives teams genuine self-service: they create and manage roles freely within the boundary, while the security team sleeps soundly knowing no role can exceed the cap. This balance of speed and safety is precisely what the SCS-C02 exam wants you to design.

For multi-account environments, pair per-identity boundaries with account-wide SCPs. The SCP sets a ceiling for the whole account, and boundaries refine limits per delegated user. Layering both gives defense in depth, so a gap in one control is caught by the other.

Safe role-creation delegation requires: require a permission boundary on every created role, protect the boundary from modification or removal with explicit denies, scope paths/names, and restrict trust on new roles. Layer with SCPs for account-wide ceilings. This closes privilege-escalation paths while preserving team self-service.

Test safe delegation.

Delegating IAM role creation safely means requiring a permission boundary on every created role via the iam:PermissionsBoundary condition, denying changes to that boundary, scoping role paths/names, and restricting trust policies on new roles. Pair with SCPs for account-wide ceilings to close privilege-escalation paths while enabling self-service.