DEV Community

Cover image for AWS IAM POLICIES Deep Dive
Ntseze-Nelvis
Ntseze-Nelvis

Posted on

AWS IAM POLICIES Deep Dive

#aws #devops #security

AWS IAM POLICIES Deep Dive

iamgroups #iamusers #iamroles #iampolicies

📌 This article is part of the AWS IAM Deep Dive series.

PART 4: IAM POLICIES

aws #iam #devops #cloud

AWS IAM Policies Complete Guide

1. What is an IAM Policy?

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

  • Who can access (via users, groups, or roles)
  • What actions can be performed
  • On which resources (ARNs)
  • Under what conditions (e.g., IP, MFA, tags)

They are the building blocks of access control in AWS, attached to identities (IAM users, groups, roles) or directly to resources (S3 buckets, KMS keys, etc.).

2. Core Characteristics of IAM Policies

Policy Types

  • Managed Policies: AWS-managed or customer-managed, reusable across identities
  • Inline Policies: Embedded directly into a user/group/role (one-to-one relationship)

Policy Document Structure 

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow" | "Deny",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": ["arn:aws:s3:::my-bucket/*"],
      "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

  • Effect: Allow or Deny (explicit deny always wins)

  • Action: API operations (e.g., ec2:StartInstances)

  • Resource: Specific resources by ARN

  • Condition: Contextual restrictions

Policy Evaluation Logic
Start with default deny

Apply explicit denies

Apply explicit allows

  1. Common Problems With IAM Policies

🔴 Overly broad policies: Using Action:"" and Resource:""

🔴 Inline policies sprawl: Hard to manage since they are tied to a single identity

🔴 Policy size/limits: Limited to 6,144 characters; too many statements cause scaling issues

🔴 Lack of conditions: Granting access without MFA/IP conditions increases attack surface

🔴 Dependency confusion: Mixing AWS-managed and customer-managed policies without documentation

  1. Solutions and Best Practices Policy Management Use customer-managed policies instead of inline for reusability

Follow least privilege principle → grant only required actions on specific resources

Use IAM Access Analyzer to validate and detect broad access

Security Hardening
Add MFA requirements in conditions

Use tags & conditions for environment-based restrictions (e.g., Environment=Prod)

Avoid attaching AdministratorAccess except for break-glass scenarios

Lifecycle Management
Version and track policies with IaC (Terraform/CloudFormation)

Regularly run IAM Access Advisor to remove unused permissions

Review SCPs in AWS Organizations for org-wide boundaries

  1. Industry Examples Startup: Developers share a S3ReadWritePolicy (customer-managed) attached to a group; inline avoided

Enterprise: Hundreds of microservices → policies modularized per service; SCPs block public S3 buckets

Finance: MFA required for sensitive actions (ec2:TerminateInstances); quarterly compliance reviews

DevOps: Policies stored in Git, deployed via Terraform; CI/CD pipeline lints policies to prevent : mistakes

  1. Interview Questions on IAM Policies Basic Level What is an IAM Policy?

Difference between AWS-managed and customer-managed policies?

Inline policy vs. managed policy?

Intermediate Level
How does IAM policy evaluation logic work?

How would you enforce least privilege?

Why is Deny more powerful than Allow?

Advanced Level
How do you design scalable IAM policies across multiple AWS accounts?

How do SCPs and IAM policies interact?

How do you restrict actions to specific environments (dev vs. prod)?

  1. Hands-On Guide Pre-checks You must have IAM rights: iam:CreatePolicy, iam:AttachUserPolicy, etc.

Decide: inline or managed? AWS-managed or customer-managed?

Define scope: Actions, Resources, Conditions

Console Steps
Open IAM Console → Policies → Create policy

Choose Visual editor or JSON

s3 get
Define actions (e.g., s3:GetObject)
Select resources (specific bucket ARN)
Add optional conditions (MFA, IP, tags)

description of s3

Review and create

role created

CLI Examples

# Create a customer-managed policy
aws iam create-policy \
  --policy-name S3ReadOnlyPolicy \
  --policy-document file://s3readonly.json
Enter fullscreen mode Exit fullscreen mode 
# Attach policy to a user
aws iam attach-user-policy \
  --user-name dev-alice \
  --policy-arn arn:aws:iam::123456789012:policy/S3ReadOnlyPolicy
Enter fullscreen mode Exit fullscreen mode 
# List policies attached to a group
aws iam list-attached-group-policies --group-name Developers
Enter fullscreen mode Exit fullscreen mode 
# Detach policy
aws iam detach-role-policy \
  --role-name EC2AppRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
Enter fullscreen mode Exit fullscreen mode 
# Delete policy (cleanup)
aws iam delete-policy \
  --policy-arn arn:aws:iam::123456789012:policy/S3ReadOnlyPolicy
Automation & Reporting
Enter fullscreen mode Exit fullscreen mode 
# Validate policy with Access Analyzer
aws accessanalyzer validate-policy \
  --policy-document file://s3readonly.json \
  --policy-type IDENTITY_POLICY
Enter fullscreen mode Exit fullscreen mode 
# List unused policies
aws iam list-policies --scope Local --only-attached=false
Enter fullscreen mode Exit fullscreen mode

🙏 Wrapping Up
IAM Policies are the foundation of AWS security.
By writing clear, reusable, and least-privileged policies, you can build strong guardrails for your environment.

🔑 Remember:

Prefer managed over inline

Always validate with Access Analyzer

Automate with IaC for versioning and consistency

✅ Thanks for reading! If this helped, don’t forget to:

Leave a reaction and follow for more AWS/DevOps guides

Drop your questions or examples of policy misconfigurations

Share this with your team so everyone follows least privilege best practices

🚀 Stay tuned for the next deep dive in this series!

Top comments (0)