AWS IAM Policies & Permissions

Authorization Definition

What is an IAM Policy?

An IAM policy is a JSON-based document that specifies what actions are allowed or denied on AWS resources, fine-tuning access permissions for principals.

Figure 1: IAM Policy structure, scope, and target attachments.

JSON Policy Scope

Policies are written in JSON and define specific boundaries for access:

Which Actions: What API operations (e.g. `s3:GetObject`, `ec2:RunInstances`) are governed.
Which Resources: Which specific AWS services or components (via ARNs) can be reached.
Permitted Results: Explicitly allowing or denying the mapped operations.

What are Principals?

A principal is the entity that submits an access request to AWS, including:

IAM Users: People or apps with permanent console/API credentials.
IAM Roles: Temporary security profiles assumed by services or identities.
AWS Services: AWS automated agents (e.g., Lambda executing code, EC2 scaling).

Policy Classification

Identity-Based and Resource-Based Policies

Comparing policies attached directly to an IAM user, group, or role against policies attached directly to an AWS resource.

Identity-Based vs Resource-Based Policies Diagram

Figure 2: Visual comparison of Identity-Based (attached to IAM users/groups) vs. Resource-Based (attached to S3 buckets).

1. Identity-Based Policy

Answers the question: "What resources can this identity access?"

These are attached directly to users, groups, or roles to dictate what actions the identity can perform on AWS:

Carlos: Policy allows GET, PUT, and LIST on Resource X.
Richard: Policy allows Read-Only (GET) on Resource Y and Resource Z.
Managers Group: Policy allows only LIST on Resource X, Y, and Z.

2. Resource-Based Policy

Answers the question: "Who can access this resource?"

These are attached directly to the AWS resource itself, specifying who can access it:

Resource X: S3 policy explicitly allows Ana and Akua to execute Read, Write, and List.
Resource Y: S3 policy allows Paulo full access, Nikki Read-Only, and Mateo Write/List.
Note (N/A): Means no permission is explicitly declared on the resource policy.

Key Differences Matrix

Property	Identity-Based Policy	Resource-Based Policy
Attachment Target	IAM User, IAM Group, or IAM Role	AWS Resource (e.g. S3 Buckets, KMS Keys, SQS Queues)
Core Purpose	Controls what actions an identity can perform	Controls which accounts or principals can enter the resource
Key Question	"What resources can this identity access?"	"Who is allowed to access this resource?"
Examples	IAM User Policy, IAM Group Policy	Amazon S3 Bucket Policy, KMS Key Policy

💡

Exam Common Use Cases

Identity-Based Policies: Granting developers permissions to launch EC2 instances or updating S3 access permissions for Sales groups.
Resource-Based Policies: Granting cross-account access (allowing users in Account B to access an S3 bucket or KMS key owned by Account A).

AWS Evaluation Logic

Determining Permissions (Policy Evaluation)

How AWS merges and processes multiple identity-based and resource-based JSON policies to make a final Allow or Deny decision.

Figure 3: Step-by-step logic applied by AWS IAM at the time of request.

Permission Evaluation Steps

When a principal submits a request, AWS follows this strict logical sequence:

1. Evaluate Policies: AWS gathers all identity-based, resource-based, and organization-level policies.
2. Check Explicit Deny: If there is an Explicit Deny anywhere, the request is immediately Denied. Deny takes absolute precedence.
3. Check Explicit Allow: If no Deny exists, AWS checks for an Explicit Allow. If found, the request is Allowed.
4. Implicit Deny (Default): If neither a Deny nor an Allow exists, the request defaults to an Implicit Deny.

Core Evaluation Rules

Default State is Deny: By default, all requests are implicitly denied. Security is secure-by-default.
Explicit Allow Overrides Default: Access is blocked unless you explicitly allow it.
Explicit Deny Overrides Allow: If there is an explicit Deny, it overrides all allows. Even if ten policies allow access, a single Deny blocks the user.
IAM Policy Simulator: A free AWS testing tool to verify and debug whether policies will allow or deny specific API calls before applying them to production systems.

Practical Examples

IAM Policy Evaluation Case Studies

Testing policy interaction using simulated S3 bucket access models for user Bob.

Example 1: Bob Accesses Bucket X

Figure 4: Permission evaluation for Bucket X where an Explicit Deny conflicts with an Allow.

Policy Definitions

Policies affecting Bob's access to Bucket X:

Identity-Based Policy (Bob): GET (Allow), PUT (Allow), LIST (Allow). Bob is granted full credentials by his user profile.
Resource-Based Policy (Bucket X): GET (N/A), PUT (Deny), LIST (Allow). The bucket explicitly denies Bob from uploading files.

Final Evaluation Results

Action	Identity Policy	Resource Policy	Final Access Result
GET (Read)	Allow	N/A	✅ Allowed
PUT (Upload)	Allow	Deny	❌ Denied (Deny wins)
LIST (View)	Allow	Allow	✅ Allowed

Example 2: Bob Accesses Bucket Y

Figure 5: Permission evaluation for Bucket Y highlighting Implicit Deny behavior.

Policy Definitions

Policies affecting Bob's access to Bucket Y:

Identity-Based Policy (Bob): GET (N/A), PUT (N/A), LIST (Allow). Bob's user profile only allows him to view bucket contents.
Resource-Based Policy (Bucket Y): GET (Allow), PUT (N/A), LIST (Allow). The S3 bucket policy grants Bob Read and List access.

Final Evaluation Results

Action	Identity Policy	Resource Policy	Final Access Result
GET (Read)	N/A	Allow	✅ Allowed (No Explicit Deny)
PUT (Upload)	N/A	N/A	❌ Denied (Implicit Deny)
LIST (View)	Allow	Allow	✅ Allowed

🧠

Evaluation Takeaways

In Example 1, Bob is blocked from PUT because the Explicit Deny on the S3 bucket policy overrides the Allow on his user policy.
In Example 2, Bob can execute GET even though it is N/A in his user policy, because the resource policy allows it, and there is no Explicit Deny. PUT is blocked because it has no explicit allow anywhere (Implicit Deny).

IAM Policies &
Permissions

What is an IAM Policy?

JSON Policy Scope

What are Principals?

Identity-Based and Resource-Based Policies

1. Identity-Based Policy

2. Resource-Based Policy

Key Differences Matrix

Exam Common Use Cases

Determining Permissions (Policy Evaluation)

Permission Evaluation Steps

Core Evaluation Rules

IAM Policy Evaluation Case Studies

Example 1: Bob Accesses Bucket X

Policy Definitions

Final Evaluation Results

Example 2: Bob Accesses Bucket Y

Policy Definitions

Final Evaluation Results

Evaluation Takeaways

Key Takeaways: Authorizing Users

Core Exam Keywords

IAM Policies &Permissions

What is an IAM Policy?

JSON Policy Scope

What are Principals?

Identity-Based and Resource-Based Policies

1. Identity-Based Policy

2. Resource-Based Policy

Key Differences Matrix

Exam Common Use Cases

Determining Permissions (Policy Evaluation)

Permission Evaluation Steps

Core Evaluation Rules

IAM Policy Evaluation Case Studies

Example 1: Bob Accesses Bucket X

Policy Definitions

Final Evaluation Results

Example 2: Bob Accesses Bucket Y

Policy Definitions

Final Evaluation Results

Evaluation Takeaways

Key Takeaways: Authorizing Users

Core Exam Keywords

IAM Policies &
Permissions