A company uses IAM permission boundaries to prevent developers from escalating privileges. The security team created a permission boundary that allows only read-only actions on most AWS services, but teams can still manage their own resources. A developer can create an IAM role with broad permissions, and the boundary does not appear to be restricting it. Which corrective action best aligns with how permission boundaries work?

Rely on an AWS-managed policy attached to the developer’s IAM user; permission boundaries only apply to users.

Permission boundaries apply to roles and users, but relying on an attached AWS-managed policy does not enforce the boundary limit. Also, the issue is that boundaries are not being applied or enforced correctly, not missing general policy attachments.

Attach the permission boundary policy as an SCP in AWS Organizations so it automatically applies to all roles.

SCPs work at the organization level and can restrict maximum permissions, but they are not the same mechanism as permission boundaries. The scenario explicitly mentions permission boundaries and that they do not appear to restrict roles, so the fix should ensure boundary attachment on the created IAM identity.

Grant the developer IAM permissions to add a “deny” statement to the boundary policy so the boundary blocks escalation.

A permission boundary does not get modified by granting the creator special permissions arbitrarily. The primary issue is likely that the boundary is not associated with the created role, so escalation is not constrained. Allowing boundary edits would often weaken security.

What does this SAA-C03 question test?

Authentication checks who the user is.

What is the correct answer to this question?

The correct answer is: Ensure the role creation process sets the permission boundary on the new role, using the boundary’s ARN in the CreateRole call or role template. — Permission boundaries constrain the maximum effective permissions for the specific IAM identity or role where the boundary is attached. If developers can create roles that are not restricted, it usually means the permission boundary was not applied to the new role at creation time (or via an automation/template). The best corrective action is to enforce attaching the permission boundary ARN whenever roles are created—through an approved role template, CI/CD validation, or required parameters—so boundary evaluation consistently limits permissions regardless of the role’s own attached policies. Why others are wrong: Option A is incorrect because permission boundaries are not fulfilled merely by attaching another policy to a user, and they are not limited to users only. Option C changes the control plane from permission boundaries to SCPs, which may not solve the role-specific enforcement gap described. Option D is dangerous: allowing boundary modifications defeats the control’s purpose and does not address boundary attachment.

What should I do if I get this SAA-C03 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.