Reading and Writing IAM Policies

An IAM policy is a JSON document containing one or more Statement blocks. Each statement has: an Effect ("Allow" or "Deny"), an Action (one or more API actions, e.g. "s3:GetObject", or a wildcard like "s3:"), a Resource (the ARN(s) this applies to, e.g. "arn:aws:s3:::my-bucket/" for every object in one bucket, or "*" for all resources of that type — used sparingly), and optionally a Condition block restricting when the statement applies (e.g. only if the request comes from a specific IP range, or only if MFA was used in the last hour).

Evaluation logic matters: AWS evaluates every policy attached to the calling identity — directly attached, inherited from group membership, and from any assumed role — and combines them. If ANY statement anywhere has an explicit Deny matching the request, the request is denied, full stop, regardless of any Allow elsewhere. If there's no explicit Deny, the request is allowed only if at least one statement explicitly allows it; the default, with no matching statement at all, is deny. This 'explicit deny always wins, default deny otherwise' logic is the single most important mental model for debugging IAM permission issues.

AWS provides Managed Policies (pre-written by AWS for common use cases, like "AmazonS3ReadOnlyAccess") that you can attach directly without writing JSON, which is the recommended starting point before reaching for custom policies.

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