AWS authorization is difficult when policy documents are treated as independent switches. An identity policy can allow an action and the request can still be denied because a permissions boundary, service control policy, session policy, resource policy, or explicit deny changes the effective result. The reliable way to reason about access is to ask which policy layers apply to the principal and request, then determine the permissions that survive all applicable limits. That policy-evaluation mindset is essential for AWS Certified Security – Specialty SCS-C03 and also appears in secure-architecture scenarios for AWS Solutions Architect – Associate SAA-C03.

Four controls are especially easy to confuse: identity-based policies, permissions boundaries, AWS Organizations service control policies, and session policies. They can all use IAM-style permission language, but they are attached at different scopes and do different jobs. The most important distinction is whether a policy grants permissions or only limits permissions that could otherwise be granted.

Identity-based policies are the normal permission grants for users and roles

Identity-based policies are attached to IAM users, groups, or roles. They are the familiar policies that say a principal may perform actions such as reading an S3 object, starting an EC2 instance, or invoking a Lambda function. Managed policies can be reused across identities, while inline policies are embedded directly in one identity.

An Allow in an identity policy is a candidate grant, not a guarantee. AWS still evaluates the rest of the applicable authorization context. An explicit Deny in an applicable policy overrides an Allow. A permissions boundary can reduce what the identity policy is allowed to grant. An SCP can reduce what principals in an organization member account are allowed to use. A session policy can reduce the privileges of temporary credentials.

This is why debugging IAM by opening only the role’s attached policies is incomplete. The role may appear to have AdministratorAccess and still be intentionally restricted by an organization guardrail or boundary. Effective access is the result of policy evaluation, not the most permissive document visible on the role.

Permissions boundaries cap an IAM entity without granting anything

A permissions boundary is a managed policy attached to an IAM user or role that defines the maximum permissions identity-based policies can grant to that entity. The boundary does not give the user or role permission by itself. If the identity policy allows s3:GetObject but the boundary does not allow it, the effective result is denied. If the boundary allows s3:GetObject but no applicable policy grants it, the action is still not granted merely because it appears in the boundary.

This makes boundaries valuable for delegated administration. A platform team can allow developers to create application roles while requiring every created role to stay inside a preapproved permission ceiling. The developer can decide which actions the application needs inside that ceiling, but cannot use an identity policy to escape the organizational limit imposed by the boundary.

Boundaries should not be described as organization-wide controls. They apply to the IAM entity on which they are configured. They also interact differently with resource-based policies, so a security review should not assume that every permission path is simply “identity policy intersected with boundary.” AWS policy evaluation distinguishes grants made directly to certain principals in resource policies from identity-policy grants. That nuance matters in advanced troubleshooting.

SCPs set organization guardrails for member accounts

A service control policy is an AWS Organizations policy that defines the maximum available permissions for IAM users and roles in affected member accounts. SCPs can be attached at organization, organizational-unit, or account scopes according to the organization’s structure. Like a permissions boundary, an SCP does not grant access. It limits what account-level IAM policies can effectively authorize.

Suppose a member account administrator attaches a broad administrator policy to a role, but an SCP denies disabling CloudTrail. The role cannot disable CloudTrail. The account administrator cannot override the organization-level guardrail with a more permissive identity policy. AWS Organizations documentation explicitly warns that SCPs are access-control limits, not permission grants.

SCPs are therefore best suited to coarse organizational invariants: disallowing unwanted Regions, blocking high-risk services, preventing security controls from being disabled, or reserving certain actions for central teams. They should be tested carefully because an overly broad SCP can affect every principal in the scoped member accounts. SCPs do not apply to IAM users and roles in the AWS Organizations management account, and they do not restrict service-linked roles.

Session policies reduce the privileges of temporary credentials

Session policies are associated with temporary sessions created through AWS Security Token Service operations. When a role is assumed or a federated session is created, the caller can sometimes pass a session policy that further restricts what the temporary credentials can do. The session cannot use permissions beyond those available to the underlying principal, and the session policy can make the session narrower.

This is useful when one role is intentionally reusable across several contexts. The base role can define the broad set of work the role is ever permitted to do, while a particular session is constrained to the subset needed for one job. A deployment system, for example, might assume a role but pass a session policy that limits the session to one application stack or a constrained set of actions.

Session policies do not permanently modify the role. A new session can receive a different restriction, subject to the role and organization limits that already exist. This makes them a runtime scoping mechanism rather than a substitute for designing a least-privilege role.

Effective permissions are an intersection of grants and guardrails

A useful simplified model for an IAM role in a member account is to start with what its identity policy allows, then intersect that set with what its permissions boundary allows and what the applicable SCP permits. If the request is made using a session that has a restrictive session policy, the session must also be allowed by that policy. Any applicable explicit Deny wins over an Allow.

That simplified model is excellent for many architecture and exam questions, but engineers should remember that resource-based policies add important evaluation paths. S3 bucket policies, KMS key policies, role trust policies, and other resource policies can grant access to specified principals. Their interaction with boundaries and sessions depends on whether the grant is made to an IAM user ARN, role ARN, role session ARN, federated session, or another principal type. Advanced access problems should therefore be validated with the exact principal and policy types rather than with a slogan.

The current AWS Organizations policy landscape also includes resource control policies in addition to SCPs. RCPs constrain permissions available to resources, whereas SCPs constrain permissions available to principals in member accounts. For the policy types in this discussion, the key principle remains the same: organization controls establish ceilings; they do not become permission grants by themselves.

Explicit denies and missing allows solve different security problems

IAM uses both implicit and explicit denial. If no applicable policy grants an action, the request is implicitly denied. An explicit Deny goes further: it wins even when another applicable policy contains an Allow. This makes explicit denies powerful guardrails, but also makes them a common source of confusing troubleshooting when engineers inspect only the policy that appears to grant access.

An allow-list SCP design, for example, can restrict member accounts by permitting only an approved set of services or actions at each hierarchy level. A deny-list approach can allow broad AWS usage while explicitly blocking dangerous or unwanted operations. Both designs require careful inheritance analysis across organization roots, OUs, and accounts.

Permissions boundaries commonly use an allow-list model: the boundary names the maximum actions a delegated role may receive. Session policies often narrow one operation or automation run. The right policy type depends on where the control should live and who must be unable to override it.

Use policy layers to create delegation without privilege escalation

A mature IAM design often uses several layers intentionally. A central security team uses SCPs to establish organization-wide guardrails. A platform team uses permissions boundaries when delegating role creation to application teams. Application owners attach least-privilege identity policies within those boundaries. Automation assumes roles with short-lived sessions and can add session restrictions for one deployment or workflow.

That layered model lets teams delegate meaningful control without giving every administrator the ability to expand privileges indefinitely. It also keeps responsibilities clear. The security team owns the outer organization limits, platform teams own safe delegation, and application teams own the minimum runtime permissions their software needs.

Tools such as Access Analyzer, CloudTrail, service last accessed data, policy simulation, and security posture services can help validate the result. The first troubleshooting step is still to understand every policy layer that applies to the request, because a useful tool cannot compensate for an incorrect mental model of identity policy evaluation.

Read IAM scenarios by scope: identity, entity ceiling, organization, or session

For SCS-C03 and real-world design reviews, scope is the fastest clue. If the requirement is to grant a role permissions, think identity policy. If delegated administrators may create roles but those roles must never exceed a defined ceiling, think permissions boundary. If every principal in a group of member accounts must be prevented from performing an action, think SCP. If temporary credentials should be more restrictive than the role they came from, think session policy.

Do not assume that an Allow in the most visible policy ends the analysis. Check boundaries, organization policies, session restrictions, resource policies, and explicit denies. Also confirm the exact principal type, because resource-based grants to a role session can be evaluated differently from identity-based grants to the role itself.

AWS IAM is predictable once the policies are treated as layers in one authorization decision. The core habit is to distinguish grants from guardrails. Identity policies normally grant; boundaries, SCPs, and session policies constrain. That mental model prevents both accidental privilege escalation and hours of troubleshooting policies that look correct in isolation.