AWS / Basic: cloud scope and core boundaries / Lesson 2

IAM roles and policy evaluation

Trace principal, action, resource, and request context through applicable policy layers without confusing identity with effective permission.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain the assumptions, responsibilities, and trade-offs of iam roles and policy evaluation.
Interpret both examples and distinguish declared intent from verified evidence.
Diagnose the listed failures and justify the worked decisions without using a real AWS account, credential, or service.

Identify the principal and session

IAM describes identities and permissions for AWS requests. A role can be assumed through an authorized trust relationship and supplies temporary session credentials; the trust policy and the role’s permitted actions answer different questions. Prefer approved federation or workload roles over embedding long-lived access keys in code. Record the actual session and target context through authorized evidence rather than trusting a profile name. A successful authentication does not establish permission for an action, and a principal may have several policy constraints that are invisible in one identity policy document.

Read the complete request tuple

A policy decision depends on principal, action, resource, and context such as conditions. The first policy grants a synthetic report-read action for one object prefix using the standard policy language version 2012-10-17. That string is a policy-language identifier, not the publication date or a required runtime version. Bucket-level and object-level actions use different resource forms. A grant to s3:GetObject does not automatically grant s3:ListBucket, KMS decryption, or role assumption. The fictional bucket reference is never contacted and the policy is not attached to any principal.

json Illustrative narrow IAM identity policy

{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:GetObject","Resource":"arn:aws:s3:::course-lab-evidence-only/reports/*"}]}

The resource is a fictional object prefix in the commercial partition. This does not grant bucket listing, KMS use, or trust to assume a role and is never applied.

Combine policy layers with care

Identity and resource policies, permissions boundaries, session policies, organization policies, and service-specific controls can all matter. Explicit deny generally overrides an applicable allow, while a boundary or service control policy is a guardrail rather than a grant by itself. Cross-account and role-session cases have documented evaluation details that should not be reduced to one universal union formula. The second simulation models only a deliberately narrow allow-plus-explicit-deny decision and states its limits. Real diagnosis must inspect every applicable layer and the exact principal form, resource scope, and conditions.

python Harmless policy-priority model

def narrow_model(allow, explicit_deny):
    return allow and not explicit_deny
print(narrow_model(True, False))
print(narrow_model(True, True))
print("not a complete AWS policy evaluator")

Expected output

True
False
not a complete AWS policy evaluator

The outputs illustrate one denial rule only. Conditions, resource policies, boundaries, sessions, organizations, and service semantics are intentionally absent.

Constrain privilege and credential use

Grant the actions and resource scope needed for a task, protect privilege-escalation paths, and review who may pass or assume roles. A narrow read policy can still be undermined by permission to modify policies or launch a workload under a more powerful role. MFA, workforce federation, credential rotation, and root-user protection address different risks and need an organization-specific operating process. Never log secret access keys, session tokens, or signed request details to diagnose AccessDenied. Safe action names, resource references, error class, and approved audit evidence usually provide a better starting point.

Verify allowance and denial without broad repair

A useful permission review tests the intended allowed operation and neighboring prohibited operations in an authorized isolated environment. An IAM simulator or static review has limitations and is not proof of every service policy or runtime condition. This course performs no AWS request or policy simulation service call. Its local arithmetic uses synthetic booleans only. When a real denial occurs, preserve context and inspect the violated contract rather than attaching administrator permissions as a shortcut. Effective least privilege is maintained as responsibilities change; it is not guaranteed forever by choosing a role name that sounds restricted.

Common errors and fixes

An allow statement is assumed sufficient

Why it happens: Applicable denies or guardrails were not reviewed.
How to fix it: Inspect the exact request and all relevant policy layers.
Prevent it next time: Maintain an effective-permission matrix with negative cases.

Role trust is confused with service permission

Why it happens: Assumption authorization and action authorization were merged.
How to fix it: Review trust, caller permission, session, and resource access separately.
Prevent it next time: Document the complete identity path.

Administrator access becomes the denial fix

Why it happens: The missing contract was bypassed rather than diagnosed.
How to fix it: Identify the narrow missing or denied action with an owner.
Prevent it next time: Review escalation and revoke temporary exceptions.

Check your understanding

1. A policy permits GetObject on reports. Does that allow listing the bucket?

Show worked solution

No. Listing uses a different action and bucket resource contract. Also check encryption and other applicable controls for the actual read. Avoid widening the policy to every S3 action when the application requires one documented operation.

2. Why does a permissions boundary not create access by itself?