An AWS IAM role has the AWS managed policy AdministratorAccess attached as its identity policy and also has a permissions boundary that allows only s3:* and cloudwatch:*. What can the role actually do, and what could it do if the boundary were the only policy attached to it?

## What a permissions boundary is A permissions boundary is a **managed policy attached to an IAM user or role in a special slot** — not as one of its permission policies, but as a cap on them. AWS evaluates the same JSON document you would write for an identity policy, but in this slot the document answers a different question: not "what may this identity do?" but "what is this identity *ever* allowed to be given?" You set it when creating the entity (`aws iam create-role --permissions-boundary <policy-arn>`) or afterwards with `iam:PutRolePermissionsBoundary` / `iam:PutUserPermissionsBoundary`, and you remove it with `iam:DeleteRolePermissionsBoundary` / `iam:DeleteUserPermissionsBoundary`. Each entity has at most **one** boundary, and it must be a managed policy (AWS-managed or customer-managed) — an inline policy cannot serve as a boundary. Boundaries attach to users and roles only; there is no boundary slot on an IAM group. ## The intersection rule For an identity-based request, a permission survives only if **both** sides allow it: - the identity's policies (attached managed policies, inline policies, and for a user, its group policies) allow the action, **and** - the boundary allows the same action. So `AdministratorAccess` (`"Action": "*", "Resource": "*"`) intersected with a boundary of `s3:*` plus `cloudwatch:*` leaves precisely S3 and CloudWatch. A call to `ec2:RunInstances` is denied — not by an explicit `Deny`, but because the boundary contains no matching `Allow`, and IAM's default answer to "no applicable allow" is deny. ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:*", "cloudwatch:*"], "Resource": "*" } ] } ``` Attached as an identity policy, that document grants S3 and CloudWatch. Attached as a boundary, the identical document grants nothing — it only permits those services to be granted by something else. ## Why the reverse direction is the real teaching point Candidates who have only skimmed the feature often describe a boundary as "a policy that gives the role its maximum permissions", which quietly implies it grants them. It does not. A role carrying only a boundary and no identity policy is inert: every API call returns AccessDenied. This is exactly what makes the mechanism safe to delegate — an administrator can attach a boundary to a role *before* anyone writes its permissions, knowing that whatever policy is attached later cannot escape the cap. It also explains a common operational surprise: someone attaches a shiny new policy to a role to fix an AccessDenied, the policy is obviously correct, and the call still fails. The missing piece is usually a boundary that never mentioned that service. ## Boundaries and Deny A boundary changes only what can be *allowed*. It does not weaken denials anywhere else. An explicit `Deny` in the identity policy, in a resource policy, in a session policy, or in an organization-level control still wins outright — deny is never overridden by an allow, and the boundary has no power to re-permit something a deny has removed. Practically, this means a boundary is a *maximum*, and other controls can push the effective set lower, never higher. Equally, a boundary is not a substitute for the permissions on the target resource. Cross-account access, an S3 bucket policy, a KMS key policy — those are separate gates. A boundary that allows `s3:*` says nothing about whether some other account's bucket will accept the call. ## Reading a setup quickly When you see an entity with both, answer in two moves. First, list what the identity policies allow. Second, strike out everything the boundary does not also allow. What survives is the effective set. Then check for explicit denies, which remove more. Interviewers usually give the deliberately alarming version — an admin policy with a narrow boundary — because the intersection answer proves you know which document is the grant and which is the filter. ## A note on scope Boundaries live inside one account and cap one entity at a time. They are the right tool when you want a specific user or role to stay under a ceiling, and especially when you want to let someone else write that entity's policies. They are not an account-wide control and not a session-lifetime control; those are different mechanisms with different attachment points.