Cargando...
Cargando...
Master AWS policy evaluation logic and never fail a permissions question again
IAM policies are JSON documents that define permissions in AWS, and understanding how they are evaluated — across identity-based, resource-based, permission boundaries, SCPs, and session policies — is the single most tested security concept across all AWS certifications. The policy evaluation logic follows a strict order of precedence where an explicit Deny always wins, and access is denied by default unless an explicit Allow exists at every applicable layer. Mastering the 'who allows what, where, and when' of IAM policy types separates passing candidates from failing ones.
To correctly answer authorization scenario questions, you must know which policy type applies, how multiple policies combine, and the exact evaluation order — especially in cross-account, SCP, and permission boundary scenarios.
Identity-Based Policy (Inline & Managed)
Policies attached directly to IAM principals (users, groups, roles). AWS Managed policies are maintained by AWS, Customer Managed policies are created and controlled by you, and Inline policies are embedded directly into a single principal and deleted with it. They define what the principal is allowed or denied to do.
Use AWS Managed policies for broad, standard permissions. Use Customer Managed policies when you need reusable, version-controlled, fine-grained permissions across multiple principals. Use Inline policies only when you need a strict 1:1 relationship between a policy and a principal that must be deleted together.
Inline policies cannot be reused, are harder to audit at scale, and do not appear in the policy library. AWS Managed policies may grant more permissions than needed (violating least privilege). Customer Managed policies require lifecycle management but offer the best balance of reuse and control.
Resource-Based Policy
JSON policies attached directly to a resource (e.g., S3 bucket policy, KMS key policy, SQS queue policy, Lambda resource policy). They specify a Principal element identifying who can access the resource. Unlike identity-based policies, resource-based policies can grant cross-account access directly without requiring the target account to also create a role.
Use when you need to grant cross-account access to a specific resource without requiring the external principal to assume a role, or when the resource itself must control who can access it (e.g., S3 bucket policies for public access, KMS key policies for cross-account encryption). Also required for Lambda, SNS, SQS, and ECR cross-account scenarios.
Not all AWS services support resource-based policies — only a subset do. KMS key policies are unique: if no key policy exists granting IAM access, even the root user cannot manage the key via IAM policies alone. Resource-based policies add a second layer to audit and manage.
Permission Boundaries
An advanced IAM feature that sets the maximum permissions an IAM entity (user or role) can have. A permission boundary does NOT grant permissions on its own — it only limits them. The effective permissions are the intersection of the identity-based policy AND the permission boundary. Even if an identity-based policy allows an action, if the boundary does not allow it, access is denied.
Use when you need to delegate IAM administration to developers or teams while preventing privilege escalation. For example, allow a developer to create IAM roles for their Lambda functions, but only roles that cannot exceed a defined boundary (e.g., cannot create admin roles).
Adds operational complexity. Does not apply to resource-based policies — a principal with a permission boundary can still be granted access via a resource-based policy if the action is allowed there. Boundaries only constrain identity-based policies.
Service Control Policies (SCPs)
Organization-level guardrails applied to OUs or accounts within AWS Organizations. SCPs define the maximum available permissions for all principals in affected accounts — including the root user of member accounts. SCPs do NOT grant permissions; they only restrict what can be granted. The management account is NOT affected by SCPs.
Use to enforce organization-wide security guardrails: prevent disabling CloudTrail, restrict regions, block purchasing of certain services, or enforce encryption requirements across all accounts in an OU. Essential for multi-account governance.
SCPs do not affect the management (master) account. SCPs do not affect service-linked roles. If a FullAWSAccess SCP is not explicitly attached, all permissions are denied by default in an OU. Requires AWS Organizations to be enabled.
Session Policies
Policies passed programmatically when assuming a role via STS (AssumeRole, AssumeRoleWithWebIdentity, AssumeRoleWithSAML, GetFederationToken). They further limit — never expand — the permissions of the assumed role for that specific session. The effective permissions are the intersection of the role's identity-based policies and the session policy.
Use when you need to grant a caller a scoped-down subset of a role's permissions for a specific task or time period. Common in federated access scenarios where different users assume the same role but need different scoped permissions per session.
Session policies can only restrict, never expand, the role's permissions. They are not stored in IAM and apply only for the duration of the session. Resource-based policies that explicitly name the session ARN as principal can grant permissions beyond the session policy — an important edge case.
Policy Conditions
Optional elements within a policy statement that make permissions conditional on context keys such as aws:RequestedRegion, aws:SourceIp, aws:MultiFactorAuthPresent, aws:PrincipalOrgID, s3:prefix, and many others. Conditions use operators (StringEquals, ArnLike, Bool, IpAddress, DateGreaterThan, etc.) and support single-value and multi-value context keys.
Use to implement fine-grained, context-aware access control: require MFA for sensitive actions, restrict access to specific IP ranges, enforce that requests originate from within your Organization (aws:PrincipalOrgID), or limit S3 access to specific prefixes. Essential for least-privilege at scale.
Conditions are evaluated as AND within a single Condition block (all must be true). Multiple Condition blocks are also AND. Multiple values within the same condition key are OR. Misunderstanding this AND/OR logic is a very common exam trap.
• STEP 1 — Is there an applicable SCP (AWS Organizations)? If YES and SCP denies the action → ACCESS DENIED (stop). If SCP does not allow the action → ACCESS DENIED (stop). If SCP allows → proceed to Step 2. If no Organizations → skip to Step 2.
• STEP 2 — Is there a resource-based policy on the target resource? If YES and it explicitly DENIES the principal → ACCESS DENIED (stop). If YES and it explicitly ALLOWS the principal AND the request is same-account → ACCESS GRANTED (for that resource-based policy grant). If cross-account, identity-based policy must ALSO allow → proceed to Step 3.
• STEP 3 — Is there a Permission Boundary on the principal? If YES, the boundary must ALLOW the action, otherwise → ACCESS DENIED. Proceed to Step 4.
• STEP 4 — Is there a Session Policy (assumed role with inline session policy)? If YES, the session policy must ALLOW the action, otherwise → ACCESS DENIED. Proceed to Step 5.
• STEP 5 — Does the identity-based policy (user/role/group policy) EXPLICITLY ALLOW the action? If YES → ACCESS GRANTED. If NO → ACCESS DENIED (implicit deny).
Additional Notes:
• GOLDEN RULE: An explicit DENY at ANY layer immediately overrides all allows. Default (implicit) deny applies unless an explicit allow exists at every required layer.
An explicit Deny in ANY policy type (identity-based, resource-based, SCP, permission boundary, or session policy) ALWAYS overrides any Allow — there are no exceptions. When a question asks why access is denied despite an Allow existing, look for a hidden Deny elsewhere.
SCPs do NOT grant permissions — they only restrict the maximum available permissions. Even if an SCP allows an action, the IAM principal still needs an identity-based or resource-based policy that explicitly allows it. A FullAWSAccess SCP on its own does not give anyone any permissions.
For SAME-ACCOUNT access: either an identity-based policy OR a resource-based policy can independently grant access (union). For CROSS-ACCOUNT access: BOTH the identity-based policy on the caller AND the resource-based policy on the target resource must allow the action (intersection). This is one of the most tested distinctions.
Permission boundaries apply ONLY to IAM users and roles — they do NOT apply to SCPs, resource-based policies, or session policies. A resource-based policy can still grant access to a principal even if that action is outside the principal's permission boundary.
The KMS key policy is unique: if the key policy does not explicitly allow IAM to manage the key (via the 'Enable IAM User Permissions' statement granting the account root), then IAM identity-based policies CANNOT grant access to that key — even for the account root user. Always check the key policy first for KMS access issues.
Explicit Deny at ANY layer (SCP, resource-based, permission boundary, session policy, or identity-based) immediately overrides ALL Allows — no exceptions, no workarounds.
Same-account access = identity-based OR resource-based policy can independently grant access (union). Cross-account access = BOTH must allow (intersection). This distinction drives most cross-account scenario questions.
SCPs and permission boundaries NEVER grant permissions — they only restrict. A principal still needs explicit Allows in identity-based or resource-based policies to actually do anything.
The NotAction element is NOT a Deny — it is an Allow (or Deny) that applies to everything EXCEPT the listed actions. A policy with Effect:Allow and NotAction:[iam:*] allows ALL actions except IAM. This is commonly confused with an explicit Deny of those actions.
aws:PrincipalOrgID is a condition key that restricts access to principals that belong to your AWS Organization. It is far simpler than listing every account ID and automatically includes new accounts. Use it in resource-based policies (e.g., S3 bucket policies) to enforce org-wide access control.
The management (master) account in AWS Organizations is NOT subject to SCPs — even if you attach a restrictive SCP to the root OU. This is a deliberate design choice and a common exam trap. Always manage the management account with extreme care.
When using AssumeRole for cross-account access, the trust policy on the ROLE (in the target account) must allow the calling principal to assume it, AND the calling principal's identity-based policy must allow sts:AssumeRole. Both are required — missing either one breaks access.
Policy variables like ${aws:username} allow you to write a single policy that dynamically adapts per user. For example, an S3 policy granting each user access only to a prefix matching their IAM username. This is the recommended approach for per-user S3 home directory patterns.
Common Mistake
An explicit Allow in an identity-based policy always grants access, regardless of other policies.
Correct
An Allow in an identity-based policy can be overridden by: an explicit Deny anywhere, an SCP that doesn't allow the action, a permission boundary that doesn't allow the action, or a session policy that doesn't allow the action. All applicable layers must permit the action.
This is the #1 reason candidates fail policy evaluation questions. Always think in layers: SCP → Resource-Based Policy → Permission Boundary → Session Policy → Identity-Based Policy. An Allow at one layer means nothing if another layer denies or doesn't allow.
Common Mistake
SCPs grant permissions to accounts in AWS Organizations, similar to how IAM policies grant permissions to users.
Correct
SCPs NEVER grant permissions. They only define the maximum ceiling of permissions available. IAM policies (identity-based or resource-based) within the account must still explicitly grant the permissions. An account with only a FullAWSAccess SCP and no IAM policies has no usable permissions.
Candidates confuse SCPs as a permission-granting mechanism. Remember: SCPs = guardrails (maximum allowed), IAM policies = actual grants. You need BOTH to function.
Common Mistake
The root user of an AWS account cannot be restricted by any policy.
Correct
The root user of a MEMBER account in AWS Organizations CAN be restricted by SCPs. An SCP denying an action will prevent even the member account root user from performing it. Only the management account root user is immune to SCPs.
This is a critical security concept for Organizations. SCPs are the mechanism to restrict even root-level actions in member accounts (e.g., preventing root from disabling CloudTrail). The management account root remains unrestricted by SCPs.
Common Mistake
A permission boundary grants the permissions listed in it to the IAM principal.
Correct
A permission boundary does NOT grant any permissions on its own. It only sets the maximum permissions an identity-based policy can effectively grant. The principal still needs an identity-based policy that explicitly allows the action — the boundary just caps what that policy can grant.
Many candidates think attaching a boundary with AdministratorAccess makes a user an admin. It does not. The user's own identity-based policies must also grant those permissions. Think of the boundary as a ceiling, not a floor.
Common Mistake
NotAction with Effect:Deny is the same as explicitly denying those specific actions.
Correct
Effect:Deny with NotAction:[action-list] DENIES everything EXCEPT the listed actions. It is an inverted deny — the listed actions are NOT denied; everything else IS denied. This is commonly used in SCPs to deny all actions except a whitelist (e.g., allow only specific services in a region).
The NotAction element inverts the scope of the statement. Deny + NotAction = 'deny everything except this list.' Allow + NotAction = 'allow everything except this list.' Getting this backwards leads to catastrophically wrong access control decisions.
Common Mistake
In a cross-account scenario, if the target resource's resource-based policy allows the external principal, no further IAM configuration is needed in the source account.
Correct
For cross-account access via role assumption, the calling principal's identity-based policy must also allow sts:AssumeRole. For direct resource-based policy grants (e.g., S3), the source account's IAM policy must also allow the action — unless the resource-based policy grants access directly to the external account root, in which case the account can delegate via IAM policies.
Cross-account access requires trust from BOTH sides. The resource/role must trust the external principal (resource-based/trust policy), AND the external principal must have permission to perform the action or assume the role (identity-based policy). One side alone is insufficient.
DENY WINS: 'D-REPS-I' = Deny explicit → Resource-based → Permission boundary → SCP → Identity-based. Evaluation order from outermost guardrail to innermost grant.
For cross-account: 'BOTH HANDS MUST SHAKE' — the target resource AND the calling principal must both agree to the access. One handshake is not enough.
SCPs = CEILING, Boundaries = WALLS, IAM Policies = DOORS. You need the ceiling to be high enough, the walls to not block you, AND the door to be open — all three must align.
NotAction is NOT a Deny list — it is an 'everything ELSE' list. Effect + NotAction = 'apply this effect to everything EXCEPT what I listed.'
Candidates see an explicit Allow in an IAM policy and assume access is granted, ignoring that an SCP, permission boundary, or resource-based Deny elsewhere in the evaluation chain is blocking it. Always evaluate ALL applicable policy layers — the evaluation chain is: SCP → Resource-Based Policy (explicit Deny check) → Permission Boundary → Session Policy → Identity-Based Policy, and an explicit Deny at any layer is final.
CertAI Tutor · · 2026-02-22
Key Services
Comparisons
Guides & Patterns