In an AWS Organizations environment, developers create IAM roles using an automation tool. The security team wants to guarantee that even if a developer attaches an overly permissive inline policy, the role cannot exceed a fixed set of allowed actions. The team already uses permission boundaries on each role. The tool’s role-creation API call succeeds, but one developer’s new role can still delete production S3 buckets. What is the most likely reason, and what should be corrected?

Permission boundaries do not affect permissions for resources created with role chaining; enable role chaining instead to apply the boundary.

Permission boundaries are evaluated to limit the maximum effective permissions for the IAM principal regardless of role chaining. The symptom (being able to perform an action beyond the intended maximum) most commonly indicates that the intended boundary was not applied or was applied incorrectly.

KMS key policies override permission boundaries for S3, so deletion permission comes from the KMS policy; restrict the KMS key policy instead.

S3 bucket deletion authorization is governed by IAM permissions (and, where applicable, S3 bucket policies/ACLs). KMS key policies control access to cryptographic operations for KMS-encrypted data, not whether the caller can delete an S3 bucket.

Permission boundaries apply only to managed policies, not to inline policies; move the overly permissive permissions to a managed policy type to keep it bounded.

Permission boundaries apply to the effective permissions of the principal, regardless of whether the allowed actions come from inline policies or managed policies. If the boundary is correctly attached, both inline and managed policies are constrained by the boundary; moving to a managed policy does not address an incorrect/missing boundary attachment.

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: The boundary policy was not actually attached during role creation, or the automation tool attached the wrong boundary ARN; correct the role-creation request to set the intended PermissionBoundary. — Permission boundaries limit an IAM principal’s effective permissions by intersecting: (1) what the principal’s attached identity policies allow, with (2) what the boundary policy allows. If a role created by automation can still delete production S3 buckets despite the expectation of boundaries, the most likely cause is that the intended permission boundary was not applied during role creation (or the automation tool used the wrong PermissionBoundary ARN). The correction is to ensure the role-creation request explicitly sets the correct PermissionBoundary ARN from the security-approved policy. Option A is incorrect because role chaining does not “bypass” permission boundaries in the way described. Option C misattributes control-plane authorization: KMS key policies do not grant S3 bucket deletion permissions. Option D is incorrect because permission boundaries constrain effective permissions even when the excessive permissions are in inline policies; the real issue is typically the boundary attachment rather than the policy type.

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.