📜 IAM Policies

• JSON documents that define permissions.

• Answer: Who can do What on Which resources

• Types:

  • Managed Policies (AWS or customer-managed)

  • Inline Policies (attached directly to one user, group, or role)

• Attached to:

  • IAM Users

  • IAM Groups

  • IAM Roles

• Use the least privilege principle: only give what’s needed

---

📜 IAM Policies: Managed vs Inline

✅ Managed Policies

• Standalone policies you can reuse across multiple identities

• Types:

  • AWS Managed → Predefined by AWS (e.g. AmazonS3ReadOnlyAccess)

  • Customer Managed → Created and controlled by you

  • Easy to update centrally and apply to many users/groups/roles

🔒 Inline Policies

• Embedded directly into a specific user, group, or role

• One-to-one relationship (cannot be reused)

• Use when:

  • A policy is unique to a single identity

  • You want tight control or specific tracking

✍️ Quick Tip for Exam

• Prefer Managed Policies for scalability

• Use Inline Policies for tightly scoped or unique needs

---

IAM Policy Structure

{
  "Version": "2012-10-17",
  "Id": "OptionalPolicyIdentifier",
  "Statement": [
    {
      "Sid": "OptionalStatementID",
      "Effect": "Allow" | "Deny",
      "Principal": "Who the policy applies to",
      "Action": "service:operation",
      "Resource": "ARN of the target resource",
      "Condition": {
        "OptionalConditions": "Based on context"
      }
    }
  ]
}

// Sample Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-example-bucket",
        "arn:aws:s3:::my-example-bucket/*"
      ]
    }
  ]
}

🔍 Key Elements to Understand:

• Version: Always use "2012-10-17"

• Statement: Main permission block

• Sid: Optional statement ID (good for clarity)

• Effect: "Allow" or "Deny"

• Principal: Who/what the policy applies to (used mostly in resource-based policies)

• Action: What can be done (e.g. s3:PutObject)

• Resource: Where actions can be done

• Condition (Optional): Adds extra logic (e.g., IP-based rules)

---

Key Elements in detail

🗓️ Version

• Tells AWS which version of the policy language you’re using.

• Always use: "2012-10-17" (most up-to-date)

---

🆔 Id (optional)

• A name/identifier for the whole policy.

• Useful for tracking or referencing the policy.

---

📜 Statement

• The heart of the policy — what it allows or denies.

• Can be one or many blocks inside a policy.

---

🧩 Sid (optional)

• Statement ID — like a label for each rule inside your policy.

• Helpful for organizing if your policy has multiple statements.

---

✅ Effect

• Says what happens:

  • "Allow" → Grants permission

  • "Deny" → Explicitly blocks permission

⚠️ Deny always wins, even if another policy says "Allow".

---

👤 Principal

• Who the policy applies to (user, account, service, etc.)

• Mostly used in resource-based policies (like S3 bucket policies).

• Example: "Principal": { "AWS": "arn:aws:iam::123456789012:user/Alice" }

---

⚙️ Action

• What the principal is allowed (or denied) to do.

• Format: service:operation

  • e.g., s3:PutObject, ec2:StartInstances, dynamodb:*

---

📦 Resource

• The specific resource the action applies to.

• Format: ARN (Amazon Resource Name)

  • e.g., arn:aws:s3:::my-bucket/*

  • Can be "*" to mean “all resources” (be careful with this!)

---

🎯 Condition (optional)

• Adds extra rules or filters.

  • e.g., allow access only from a specific IP address

  • e.g., allow access only if MFA is used

• Very powerful for fine-grained control

---

More AWS SAA Articles

• AWS IAM User, Root User and Groups

Follow me for more such content

• My YouTube Channel

• My Site

• My Blogs

• LinkedIn

• Instagram

• Twitter

• Stackoverflow

• Github

• Dev

• Medium