IAM Policies and Evaluation Logic – Complete Guide for AWS Security Specialty
Why IAM Policies and Evaluation Logic Matter
Identity and Access Management (IAM) policies are the backbone of security in AWS. Every single API call made against AWS services is evaluated against IAM policies to determine whether the action should be allowed or denied. Understanding how these policies work and how AWS evaluates them is not only critical for real-world security architecture but is also one of the most heavily tested topics on the AWS Security Specialty exam. A misconfigured policy can lead to privilege escalation, data breaches, or complete loss of access to resources. Mastering evaluation logic ensures you can design least-privilege architectures and troubleshoot access issues efficiently.
What Are IAM Policies?
IAM policies are JSON documents that define permissions. They specify who can do what on which resources under what conditions. There are several types of policies in AWS:
1. Identity-Based Policies
These are attached to IAM principals (users, groups, or roles).
- AWS Managed Policies: Created and maintained by AWS. They cover common use cases like ReadOnlyAccess or AdministratorAccess.
- Customer Managed Policies: Created and maintained by you. They offer more granular control and can be attached to multiple principals.
- Inline Policies: Embedded directly into a single user, group, or role. They have a strict one-to-one relationship with the principal.
2. Resource-Based Policies
These are attached directly to AWS resources such as S3 buckets, SQS queues, KMS keys, and Lambda functions. They include a Principal element that specifies who is granted or denied access. A key distinction: resource-based policies can grant cross-account access without requiring the caller to assume a role.
3. Permissions Boundaries
These are advanced features that set the maximum permissions an identity-based policy can grant to an IAM entity. They do not grant permissions themselves; they limit what permissions can be effective. Think of them as a ceiling on what a user or role can do.
4. Service Control Policies (SCPs)
Used with AWS Organizations, SCPs define the maximum permissions for member accounts. Like permissions boundaries, they do not grant permissions but restrict what is allowed. They apply to all principals in the account, including the root user (with some exceptions).
5. Session Policies
Passed as parameters when programmatically creating a temporary session (e.g., with AssumeRole or GetFederationToken). They limit the permissions for that session and act as an additional filter.
6. Access Control Lists (ACLs)
Legacy cross-account permission mechanisms used by services like S3 and some VPC configurations. They do not use JSON policy format.
Anatomy of a Policy Document
Every IAM policy consists of one or more statements. Each statement has:
- Effect: Either Allow or Deny.
- Action: The specific API actions (e.g., s3:GetObject, ec2:RunInstances).
- Resource: The ARN of the resource(s) the statement applies to.
- Condition (optional): Circumstances under which the statement is in effect (e.g., source IP, MFA present, time of day, tags).
- Principal (resource-based policies only): The account, user, role, or service that is allowed or denied access.
How IAM Policy Evaluation Logic Works
AWS uses a well-defined, deterministic evaluation process for every API request. Understanding this flow is essential:
Step 1: Gather All Applicable Policies
When a principal makes a request, AWS collects all relevant policies: identity-based policies, resource-based policies, permissions boundaries, SCPs, session policies, and any applicable VPC endpoint policies.
Step 2: Evaluate – The Default Deny
By default, all requests are implicitly denied. Unless an explicit Allow exists, the request will be denied.
Step 3: Check for Explicit Denies
AWS evaluates all policies and checks for any explicit Deny statements that match the request. An explicit Deny ALWAYS overrides any Allow. This is the single most important rule in IAM evaluation logic.
Step 4: Check for Allows
If no explicit Deny is found, AWS checks whether any policy grants an explicit Allow. The behavior differs based on the type of policy:
- For same-account requests: An Allow in either an identity-based policy or a resource-based policy is sufficient to grant access.
- For cross-account requests: An Allow must exist in both the identity-based policy of the calling account and the resource-based policy of the resource account (with one exception: resource-based policies that specify the IAM principal's ARN directly can grant access without the calling account's identity policy explicitly allowing it for some services).
- Permissions boundaries and SCPs act as filters. Even if an identity-based policy allows an action, the action is only permitted if the permissions boundary and applicable SCPs also allow it. They narrow the effective permissions through intersection.
- Session policies similarly filter the effective permissions of the session.
Step 5: Final Decision
If no explicit Allow is found after evaluating all applicable policies, the request is denied (implicit deny).
The Evaluation Order Summarized
1. Explicit Deny → Request DENIED (always wins)
2. SCP check → If SCP does not allow, request DENIED
3. Resource-based policy → If resource-based policy allows (same account), request ALLOWED (even if permissions boundary or identity policy would otherwise restrict it — this is a special case for resource-based policies in same-account scenarios)
4. Permissions boundary check → If permissions boundary does not allow, request DENIED
5. Session policy check → If session policy does not allow, request DENIED
6. Identity-based policy check → If identity-based policy allows, request ALLOWED
7. If none of the above grants access → Implicit DENIED
Important note on resource-based policies (same account): When a resource-based policy grants access to a specific IAM principal (using the full ARN), this grant is not limited by permissions boundaries or SCPs applied to that principal. This is a critical nuance tested in the exam.
Cross-Account Access Evaluation
For cross-account access, both sides must permit the action:
- The trusting account (resource owner) must have a resource-based policy allowing the external principal.
- The trusted account (caller's account) must have an identity-based policy allowing the principal to access the resource.
- SCPs in both accounts can restrict access.
- Exception: If the resource-based policy in the trusting account specifies the caller's role ARN directly, and the service supports resource-based policies, some services allow access without the trusted account's identity policy explicitly granting it — but the SCP in the trusted account must still allow it.
Condition Keys and Policy Variables
Conditions add fine-grained control. Common condition keys include:
- aws:SourceIp – Restrict by IP address
- aws:MultiFactorAuthPresent – Require MFA
- aws:MultiFactorAuthAge – Time since MFA authentication
- aws:PrincipalOrgID – Restrict to principals from a specific AWS Organization
- aws:PrincipalTag/key – Tag-based access control (ABAC)
- aws:RequestedRegion – Restrict actions to specific regions
- s3:prefix – Restrict S3 operations to specific prefixes
- kms:ViaService – Restrict KMS key usage to specific AWS services
- aws:SecureTransport – Require HTTPS
- ec2:ResourceTag/key – Restrict EC2 actions based on resource tags
Condition operators include StringEquals, StringLike, ArnLike, IpAddress, DateGreaterThan, Bool, NumericLessThan, and their negated counterparts (StringNotEquals, etc.).
Multiple conditions within the same block are ANDed. Multiple values for the same condition key are ORed.
The NotAction, NotResource, and NotPrincipal Elements
These are inverse matching elements that are frequently tested:
- NotAction: Matches every action EXCEPT those listed. Useful for creating policies like "Allow everything except IAM actions."
- NotResource: Matches every resource EXCEPT those listed.
- NotPrincipal: Matches every principal EXCEPT those listed. When used with Deny, it effectively means "Deny everyone except this principal." Be careful: NotPrincipal with Deny in a resource-based policy is a common pattern to restrict access to specific principals only.
Important: NotAction with Allow does not deny the excluded actions — it simply does not allow them. They remain implicitly denied unless another policy grants access.
Policy Evaluation with S3 (Special Case)
S3 has a unique evaluation model because it supports both bucket policies (resource-based), IAM policies (identity-based), and ACLs. The evaluation logic combines all three:
- For same-account access: A union of bucket policy and IAM policy is evaluated. An Allow in either is sufficient (unless there is an explicit Deny).
- For cross-account access: Both the bucket policy and the caller's IAM policy must allow the action.
- S3 ACLs are evaluated separately and can grant access independently, but AWS recommends disabling ACLs using S3 Object Ownership settings.
Policy Evaluation with KMS (Special Case)
KMS key policies are unique because they are required for access. Unlike most AWS services, the IAM policy alone is not sufficient — the KMS key policy must also grant access (or delegate to IAM policies via the key policy statement that allows the account root). If the key policy does not include the root account delegation statement, then only principals explicitly named in the key policy can use the key, regardless of their IAM permissions.
Common Patterns and Scenarios
Scenario 1: Explicit Deny Overrides Allow
A user has an IAM policy that allows s3:* on all resources. An SCP or another policy contains an explicit Deny for s3:DeleteBucket. Result: The user CANNOT delete buckets. Explicit Deny always wins.
Scenario 2: Permissions Boundary Limits Effective Permissions
A developer role has an identity policy allowing ec2:*, s3:*, and lambda:*. A permissions boundary is set that allows only s3:* and lambda:*. Effective permissions: s3:* and lambda:* only. EC2 actions are denied because the permissions boundary does not allow them.
Scenario 3: Cross-Account S3 Access
Account A's IAM role needs to access a bucket in Account B. Account B's bucket policy must Allow the role from Account A, AND Account A's IAM policy for the role must Allow s3 actions on Account B's bucket. If either is missing, access is denied.
Scenario 4: SCP Restricts Even Root User
An SCP on an OU denies ec2:RunInstances in us-west-2. Even if an IAM administrator in a member account has full EC2 permissions, they cannot launch instances in us-west-2. The SCP acts as a guardrail.
Scenario 5: Resource-Based Policy Bypassing Permissions Boundary
An S3 bucket policy in the same account grants s3:GetObject to a specific IAM user. Even if the user's permissions boundary does not include s3:GetObject, the user CAN access the object because resource-based policies (same account, specifying the principal's ARN) are not limited by the permissions boundary.
Troubleshooting Access Issues
When a request is unexpectedly denied, follow this checklist:
1. Is there an explicit Deny anywhere? (SCPs, identity policies, resource policies, VPC endpoint policies)
2. Is the action allowed by an identity-based or resource-based policy?
3. Are permissions boundaries in place that might restrict the effective permissions?
4. Are SCPs restricting the action at the organizational level?
5. Is a VPC endpoint policy restricting the action?
6. Is a session policy limiting the temporary credentials?
7. Use IAM Policy Simulator or CloudTrail logs (look for AccessDenied with error context) for debugging.
8. Use IAM Access Analyzer to validate policies and check for unintended access.
Exam Tips: Answering Questions on IAM Policies and Evaluation Logic
Tip 1: Remember the Golden Rule
Explicit Deny ALWAYS wins. If any applicable policy contains an explicit Deny that matches the request, the request is denied — no matter how many Allow statements exist elsewhere. When you see a question with conflicting Allow and Deny, the answer is always DENY.
Tip 2: Default is Implicit Deny
If no policy explicitly allows an action, it is denied. You do not need an explicit Deny to block access — the absence of an Allow is sufficient.
Tip 3: Understand the Intersection Model
Effective permissions = Identity Policy ∩ Permissions Boundary ∩ SCP ∩ Session Policy. All must allow the action for it to succeed. Resource-based policies (same account) are the exception — they can grant access even outside the intersection.
Tip 4: Cross-Account Requires Both Sides
For cross-account access, always verify that BOTH the caller's account policy AND the resource's policy grant access. If the question shows only one side allowing access, the answer is DENY.
Tip 5: Know KMS Key Policy Behavior
KMS is the most common exception to standard evaluation logic. If the key policy does not delegate to IAM (no root account statement), then IAM policies are ignored. Expect at least one or two questions on this.
Tip 6: Watch for NotAction and NotPrincipal Traps
NotAction with Allow does NOT deny the excluded actions. It simply does not allow them. Many questions try to trick you into thinking NotAction creates a Deny. Similarly, NotPrincipal with Deny can accidentally lock out unintended principals if not combined with conditions.
Tip 7: Pay Attention to Conditions
Read condition blocks carefully. Common tricks include: aws:MultiFactorAuthPresent being "false" vs not being present at all (they are different), StringEquals vs StringLike (wildcards only work with StringLike), and IpAddress conditions with CIDR blocks.
Tip 8: Resource-Based Policies and Permissions Boundaries
Remember the special case: in the same account, a resource-based policy that directly names a principal can bypass the permissions boundary. This is a frequently tested edge case.
Tip 9: SCPs Do Not Affect the Management Account
SCPs apply to member accounts only. The management (master) account is never affected by SCPs. If a question involves the management account, SCPs are irrelevant.
Tip 10: Use Process of Elimination
For complex policy evaluation questions, work through the evaluation logic step by step: check for explicit denies first, then SCPs, then resource-based policies, then permissions boundaries, then identity-based policies. This systematic approach will help you arrive at the correct answer even under time pressure.
Tip 11: VPC Endpoint Policies Are an Additional Filter
If traffic goes through a VPC endpoint, the endpoint policy is an additional layer that must allow the action. Questions might describe a scenario where IAM and resource policies are correct but access is denied — look for a restrictive VPC endpoint policy.
Tip 12: IAM Access Analyzer and Policy Simulator
Know that IAM Access Analyzer can identify resources shared externally, validate policies against best practices, and generate policies based on CloudTrail activity. The IAM Policy Simulator can test policies without actually making API calls. Questions about troubleshooting or auditing often reference these tools.
Tip 13: Read the Entire Policy Document
Exam questions often present full or partial JSON policies. Read every element carefully — the Effect, Action, Resource, and especially the Condition block. Missing a single element can lead to the wrong answer.
Final Summary
IAM policy evaluation logic follows a clear, deterministic path. Master the hierarchy: Explicit Deny → SCPs → Resource-based policies → Permissions boundaries → Session policies → Identity-based policies → Implicit Deny. Understand the special cases for KMS, S3, cross-account access, and resource-based policies bypassing permissions boundaries. Practice reading JSON policy documents and evaluating them systematically. This topic is fundamental to the AWS Security Specialty exam and appears across multiple question domains.
