In AWS, compare a permissions boundary, a service control policy (SCP) and a session policy: what does each attach to, who controls it, and can any of them grant a permission?

## Three caps, one shared property AWS has several documents that look like IAM policies but behave as ceilings rather than grants. Confusing them is one of the most common IAM interview stumbles, because the JSON is identical — a `Version`, `Statement`, `Effect`, `Action`, `Resource`, `Condition` — and only the attachment point tells you what the document means. The shared property comes first: **none of the three grants a permission.** An `Allow` inside any of them merely means "this may be allowed if something else grants it." Grants come only from identity-based policies attached to a user or role, and from resource-based policies attached to a resource such as an S3 bucket or a KMS key. Everything else narrows. ## Permissions boundary - **Attaches to:** exactly one IAM user or role, in a dedicated slot, as a single managed policy. - **Controlled by:** an IAM administrator in that account. - **Lifetime:** until someone changes or removes it (`iam:PutRolePermissionsBoundary`, `iam:DeleteRolePermissionsBoundary`). - **Scope of effect:** the identity-based permissions of that one entity. Its purpose is delegation *inside* an account. You want a team to author its own roles and policies; you do not want them to author an administrator. Attaching a boundary — and requiring that any role they create carries it — bounds whatever they write, without you reviewing each policy. ## Service control policy - **Attaches to:** an AWS Organizations root, an organizational unit, or an individual account. - **Controlled by:** the organization's management account. - **Lifetime:** as long as the account stays under that OU with the policy attached. - **Scope of effect:** every principal in the affected member accounts — including that account's own administrators and root user. The key structural difference from a boundary is *blast radius and who holds the pen*. An account admin can detach a permissions boundary in their own account; they cannot remove an SCP applied to them from above. That is precisely why SCPs are the tool for guardrails you never want a team to be able to lift — "no one may disable CloudTrail", "no resources outside these Regions". Note that SCPs govern member accounts; the organization's management account is not constrained the same way, which is one reason workloads do not belong there. ## Session policy - **Attaches to:** nothing persistent — it is passed as a parameter to `sts:AssumeRole`, `sts:AssumeRoleWithWebIdentity` or `sts:AssumeRoleWithSAML`, either as inline JSON in `Policy` or as up to a small number of managed policy ARNs in `PolicyArns`. - **Controlled by:** whichever code performs the AssumeRole call. - **Lifetime:** the credentials it produced, and nothing beyond them. - **Scope of effect:** that single session. ```bash aws sts assume-role \ --role-arn arn:aws:iam::111122223333:role/TenantAccess \ --role-session-name tenant-42 \ --policy '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:GetObject","Resource":"arn:aws:s3:::data/tenant-42/*"}]}' ``` This is the classic credential-broker shape. One role is defined broadly enough to serve every tenant, and the broker scopes each minted session down to one tenant's prefix. The role itself never changes; the narrowing travels with the credentials. If the broker's session policy allowed something the role does not, it would still be denied — again, the session policy only intersects. ## How to answer the comparison crisply An interviewer usually wants three axes back: **attachment point, controller, and lifetime**, plus the shared "none of them grants". A useful one-line mapping: - Boundary — *per identity*, set by the account's IAM admin, for safe delegation of policy authorship. - SCP — *per account or OU*, set by the organization, for guardrails teams cannot lift. - Session policy — *per credential set*, set by the caller at assume time, for scoping down what you hand out. ## Why the distinction matters in design Choosing the wrong one produces a control that looks right and is not. A boundary meant as an org guardrail can be detached by the very admin it was supposed to restrain. An SCP used where per-role tailoring was needed becomes a document everyone must edit for every team. A session policy used as a durable control disappears the moment someone assumes the role without passing it. Match the control's lifetime and controller to the threat you actually have: a mistake by a delegated team member (boundary), a team deliberately or accidentally lifting a guardrail (SCP), or credentials leaving your process (session policy).