AWS Services
IAM Policy Types And Evaluation Traps
Understand AWS IAM policy types, evaluation order, explicit deny, identity policies, resource policies, permission boundaries, SCPs, ACLs, session policies, and SAA-C03 traps.
After this, you will understand
IAM stops feeling random once learners see access as permission math: default deny, explicit deny, allows, and guardrail intersections.
AWS starts with deny, checks for explicit denies, then allows access only when the right policy layers allow the request.
Learners add another allow policy and miss the SCP, permission boundary, session policy, resource policy, or KMS key policy that is still blocking the request.
For every access question, list principal, action, resource, account boundary, identity policy, resource policy, guardrails, session scope, and explicit denies.
Think before readingWhy can an IAM role with an allow policy still be denied?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- IAM policy evaluation
- Implicit deny and explicit deny
- Identity-based policies
- Resource-based policies
- Permission boundaries
- Service control policies
- Session policies
- Access control lists
- Cross-account evaluation
- SAA-C03 authorization traps
1. Plain-English Mental Model
AWS authorization is permission math.
The simple version is:
default = deny
explicit deny = always deny
allow = works only if no applicable guardrail blocks it
An identity policy can say a role is allowed to call s3:GetObject. A bucket policy can still deny that request. A service control policy can block the action for the whole account. A permission boundary can cap what the role can do. A session policy can narrow the role session. A KMS key policy can deny decrypt even when S3 allows the object read.
The exam trap is thinking IAM is one policy attached to one role. Real AWS access is the result of multiple policy surfaces.
2. Why This Service Exists
AWS accounts are API-driven environments. Every useful action is an API request: create an instance, read an object, decrypt a key, assume a role, publish to a topic, update a route table, or delete a log trail.
IAM and related policy systems exist because cloud access needs more than one question:
- Who is making the request?
- What are they trying to do?
- Which resource is involved?
- Which account owns the principal?
- Which account owns the resource?
- Which guardrails apply?
- Are there contextual conditions, such as MFA, VPC endpoint, tags, or Region?
For SAA-C03, this is the backbone of secure architecture. Many questions that look like S3, KMS, Organizations, Lambda, SQS, SNS, or CloudTrail questions are actually IAM policy evaluation questions.
3. The Naive Approach And Where It Breaks
The naive troubleshooting move is:
AccessDenied -> add Allow to the role
Sometimes that works. Often it does not.
If the bucket policy has an explicit deny, another allow on the role will not help. If an SCP blocks a service in a member account, an account administrator cannot bypass it with AdministratorAccess. If a role has a permission boundary, identity policies cannot exceed that boundary. If a session policy narrows a federated session, the session cannot use permissions outside that intersection.
Another naive approach is to trust a single successful policy simulator result without checking the resource owner account, KMS key policy, VPC endpoint policy, or service-specific resource policy.
Good AWS troubleshooting starts by drawing the whole access path.
4. Core Primitives
An identity-based policy attaches to a user, group, or role. It grants permissions to that identity.
A resource-based policy attaches to a resource and includes a Principal because the resource declares who can access it.
A permission boundary is a managed policy that sets the maximum permissions identity-based policies can grant to an IAM user or role. It does not grant permissions by itself.
An SCP is an AWS Organizations guardrail that sets maximum available permissions for IAM users and roles in member accounts. It does not grant permissions by itself.
A session policy is passed when creating a temporary session, such as with STS. It narrows the permissions of that session and does not grant permissions by itself.
An ACL is a service-specific access-control mechanism, most visible historically in S3. Modern S3 designs usually keep ACLs disabled and use policies.
An explicit deny in any applicable policy layer wins.
5. Architecture Use Cases
Use identity policies to grant workload roles the actions they need:
Lambda execution role -> dynamodb:PutItem on one table
EC2 instance role -> s3:GetObject on one bucket prefix
Use resource policies when the resource must grant access directly:
S3 bucket policy -> allow central logging delivery
SQS queue policy -> allow SNS topic to send messages
Lambda resource policy -> allow S3 to invoke function
KMS key policy -> allow approved roles to use key
Use SCPs for organization-wide non-negotiables:
deny disabling CloudTrail
deny unapproved Regions
deny leaving the organization
Use permission boundaries when delegated IAM administrators can create roles but must not create roles beyond an approved ceiling.
Use session policies when a temporary session should be narrower than the base role.
7. Security Model
The security model is layered.
Start with the request:
principal -> action -> resource -> context
Then evaluate the surfaces:
- identity policies attached to the caller
- resource policy attached to the target resource
- permission boundary on the caller, if any
- SCPs or organization controls, if applicable
- session policies, if using temporary credentials
- VPC endpoint policies, if using endpoint paths
- service-specific controls such as S3 Block Public Access or KMS grants
An allow must survive every applicable maximum-permission boundary. Any matching explicit deny ends the conversation.
The useful design habit is to separate grants from guardrails. IAM policies grant. SCPs, permission boundaries, and session policies usually constrain. Resource policies may grant or deny from the resource side.
8. Reliability And Resilience
Authorization changes can be production changes.
A tightened SCP can break deployments across many accounts. A changed key policy can make encrypted data unreadable. A changed bucket policy can stop log delivery. A changed permission boundary can stop newly created roles from working. A changed session policy can make federated access unexpectedly narrower.
Use staged rollout for broad guardrails. Test in a sandbox OU before attaching to production OUs.
Use CloudTrail for denied API calls and policy-change audit trails. Use IAM Access Analyzer where appropriate to validate policies and detect unintended external access.
Keep break-glass roles controlled, monitored, and tested. A break-glass role that is blocked by the same mistaken policy layer may not help during an incident.
9. Performance And Scaling
Policy evaluation is not usually an application performance bottleneck.
The scaling problem is human understanding. Large organizations can accumulate thousands of roles, policies, resource policies, permission sets, SCPs, and exceptions.
Use consistent naming, managed policies for reusable patterns, tags for ownership, least-privilege generation from access activity, and clear OU structures.
Avoid one-off inline policies unless there is a reason the policy must live with one identity. Customer managed policies are easier to reuse and audit.
Keep cross-account access patterns boring. Boring access patterns are easier to troubleshoot at 2 a.m.
10. Cost Model
IAM policies, permission boundaries, and SCPs do not have direct usage charges.
The cost is operational risk. Overly broad permissions can cause security incidents or expensive resources. Overly restrictive guardrails can block delivery and create support load.
Access Analyzer, CloudTrail storage, Security Hub, Config, and related audit services can add cost, but they also reduce the cost of blind policy drift.
Least privilege is not only a security principle. It is also a cost control principle because fewer principals can create expensive or risky infrastructure.
12. SAA-C03 Exam Signals
"No explicit allow" means denied by default.
"Explicit deny" wins over any allow.
"Centrally restrict member accounts" points to SCPs.
"Maximum permissions for a role created by delegated admins" points to permission boundaries.
"Temporary credentials should be further restricted" points to session policies.
"Policy includes Principal" usually points to a resource-based policy.
"Cross-account resource access" usually requires both caller-side permission and resource-owner permission.
"S3 access allowed but encrypted object fails" often points to KMS key policy or KMS permission.
13. Common Exam Traps
Do not assume one allow policy is enough.
Do not forget SCPs do not grant permissions.
Do not forget permission boundaries do not grant permissions.
Do not confuse role trust policies with role permission policies.
Do not assume same-account and cross-account access evaluate the same way.
Do not ignore KMS key policies when encrypted data is involved.
Do not use ACLs as the default answer for modern S3 access control.
Do not forget that session policies can narrow a role session.
15. Related Topics
Review IAM Foundations, Identity Policies vs Resource Policies, Service Control Policies, KMS Key Policies vs IAM Policies, and S3 Bucket Policies vs ACLs vs Access Points.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.