AWS IAM provides the foundation for authentication and authorization in AWS. We learned about IAM Users, Groups, and Roles in previous articles, but one critical question remains:

How does AWS actually decide what actions a user is allowed to perform?

The answer is IAM Policies.

IAM Policies are the heart of AWS permission management. Every action performed in AWS is evaluated against policies. Whether you're launching an EC2 instance, reading an S3 bucket, creating a Lambda function, or managing databases, IAM Policies determine whether the action is allowed or denied.

Understanding IAM Policies is essential because they are used in virtually every AWS environment, from small personal projects to large enterprise cloud infrastructures.

In this guide, you'll learn:

• What IAM Policies are
• How policies work
• Policy structure
• JSON policy syntax
• Managed vs Inline Policies
• Permission evaluation logic
• Least Privilege implementation
• Real-world examples
• Best practices
• Interview questions

What Is an IAM Policy?

An IAM Policy is a JSON document that defines permissions in AWS.

Policies determine:

• What actions are allowed
• What actions are denied
• Which resources can be accessed
• Under what conditions access is granted

Think of a policy as a rulebook that AWS uses whenever someone attempts an action.

Real-World Analogy

Imagine a company building.

Employees have access cards.

The access card contains permissions such as:

✅ Enter Office

✅ Enter Meeting Room

❌ Enter Server Room

❌ Access Executive Floor

IAM Policies work similarly.

Instead of physical rooms:

They control AWS resources.

Why IAM Policies Are Important

Without policies:

• Users would have unrestricted access
• Security risks would increase
• Compliance requirements would fail
• Resource management would become chaotic

Policies provide:

• Security
• Control
• Accountability
• Compliance

Every AWS access decision ultimately depends on policies.

How IAM Policies Work

Consider the following scenario:

User:

John

Attempts:

Launch EC2 Instance

AWS performs:

Step 1

Authenticate user.

Step 2

Retrieve attached policies.

Step 3

Evaluate permissions.

Step 4

Return result.

Either:

✅ Allowed

or

❌ Denied

This process occurs automatically in milliseconds.

IAM Policy Structure

IAM Policies are written in JSON format.

A simple policy looks like:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "*"
}
]
}

Although this may appear intimidating initially, every policy follows the same structure.

Understanding Policy Components

Every IAM Policy contains several important elements.

Version

Example:

"Version": "2012-10-17"

Defines the policy language version.

Almost every modern policy uses:

2012-10-17

Statement

Contains one or more permission rules.

Example:

"Statement": [...]

A policy may contain multiple statements.

Effect

Determines whether access is:

"Allow"

or

"Deny"

Examples:

"Effect": "Allow"

"Effect": "Deny"

Action

Specifies what operation can be performed.

Examples:

"s3:GetObject"

"ec2:StartInstances"

"ec2:StopInstances"

Actions are service-specific.

Resource

Defines which AWS resources are affected.

Example:

"Resource": "*"

Meaning:

All resources.

More specific example:

"Resource":
"arn:aws:s3:::company-data"

Only one bucket.

Simple Policy Example

Allow viewing S3 buckets:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "*"
}
]
}

Result:

✅ Can view buckets

❌ Cannot delete buckets

❌ Cannot upload files

Multiple Actions Example

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:DescribeInstances"
],
"Resource": "*"
}
]
}

This allows:

• Start instances
• Stop instances
• View instances

Wildcards in Policies

AWS supports wildcards.

Example:

"Action": "s3:*"

Meaning:

All S3 actions.

Examples:

• GetObject
• PutObject
• DeleteObject
• ListBucket

All allowed.

Another example:

"Action": "*"

Means:

All AWS actions.

Equivalent to administrator-level permissions.

Use cautiously.

What Is an ARN?

Policies often use ARNs.

ARN stands for:

Amazon Resource Name

Example:

arn:aws:s3:::company-backups

An ARN uniquely identifies an AWS resource.

Format:

arn:partition:service:region:account-id:resource

AWS uses ARNs extensively within policies.

Managed Policies

AWS provides prebuilt policies called Managed Policies.

Examples:

AdministratorAccess

Full AWS access.

AmazonS3ReadOnlyAccess

Read-only S3 permissions.

AmazonEC2ReadOnlyAccess

Read-only EC2 permissions.

Benefits:

• Easy to use
• AWS maintained
• Frequently updated

Good for beginners.

Customer Managed Policies

Organizations can create custom policies.

Example:

Allow:
- Start EC2
- Stop EC2

Deny:
- Terminate EC2

Benefits:

• Fine-grained control
• Business-specific permissions

Common in production environments.

Inline Policies

Inline Policies are attached directly to:

• Users
• Groups
• Roles

Unlike managed policies:

They cannot be reused elsewhere.

Best for:

• Unique permissions
• One-off configurations

Most organizations prefer managed policies for scalability.

Managed vs Inline Policies

Generally:

Use managed policies whenever possible.

IAM Policy Evaluation Logic

One of the most important AWS security concepts.

AWS follows these rules:

Rule 1

Default = Deny

Everything starts denied.

Rule 2

Explicit Allow = Allow

If policy allows action:

Access granted.

Rule 3

Explicit Deny Overrides Everything

Even if another policy allows access:

An explicit deny always wins.

Example:

Policy A:

Allow S3 Access

Policy B:

Deny DeleteObject

Result:

User can use S3.

User cannot delete objects.

Explicit deny wins.

Least Privilege and Policies

Policies enable the Principle of Least Privilege.

Meaning:

Grant only necessary permissions.

Bad example:

"Action": "*"

Good example:

"Action":
[
"ec2:StartInstances",
"ec2:StopInstances"
]

Benefits:

• Improved security
• Reduced risk
• Better compliance

Real-World Example

Developer Team:

Needs:

• Start EC2
• Stop EC2
• View CloudWatch Logs

Does NOT need:

• IAM Administration
• Billing Access
• Database Management

Custom policy grants only required permissions.

This is least privilege in practice.

Common Beginner Mistakes

Using AdministratorAccess Everywhere

Convenient but dangerous.

Using Resource *

Creates overly broad permissions.

Ignoring Explicit Deny

Can cause unexpected access issues.

Hardcoding Permissions Without Planning

Leads to permission sprawl.

Not Reviewing Policies

Old permissions often accumulate.

Best Practices

Follow Least Privilege

Grant minimum required permissions.

Use Managed Policies

Simplify administration.

Avoid Wildcards

Use specific actions whenever possible.

Review Permissions Regularly

Audit access periodically.

Use Roles Instead of Long-Term Credentials

Improves security posture.

Document Custom Policies

Helps future maintenance.

Common Policy Examples

Read-Only S3 Access

{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": "*"
}

EC2 Read Access

{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*"
}

Deny Bucket Deletion

{
"Effect": "Deny",
"Action": "s3:DeleteBucket",
"Resource": "*"
}

Interview Questions

What is an IAM Policy?

A JSON document that defines permissions in AWS.

What are the main components of a policy?

• Version
• Statement
• Effect
• Action
• Resource

What does Effect control?

Whether access is allowed or denied.

What is an ARN?

Amazon Resource Name used to uniquely identify AWS resources.

What happens if Allow and Deny both exist?

Explicit Deny always wins.

What is the difference between Managed and Inline Policies?

Managed policies are reusable; Inline policies are attached directly to a single identity.

What is the Principle of Least Privilege?

Grant only the permissions necessary to perform required tasks.

Key Takeaways

• IAM Policies define AWS permissions.
• Policies are written in JSON.
• Core elements include Version, Statement, Effect, Action, and Resource.
• Managed Policies are reusable and AWS-recommended.
• Explicit Deny always overrides Allow.
• Least Privilege should guide all policy design.
• Policies are central to AWS security and access control.

Conclusion

IAM Policies are the engine that powers authorization in AWS. They determine exactly what users, groups, and roles can do within your AWS environment and provide the fine-grained control needed to secure cloud resources effectively.

A strong understanding of IAM Policies is essential because every AWS service relies on policy evaluation to make access decisions. Mastering policies will enable you to build secure, scalable, and compliant AWS environments.

In the next article, we'll explore Multi-Factor Authentication (MFA) in AWS and learn how to add an additional layer of protection to AWS accounts and IAM users.