AWS SAA Study Guide

JSON documents with statements: Allow or Deny on specific Actions + Resources.

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

Version — the policy language version, always 2012-10-17 (the current/only version — don't overthink it). Statement — an array of one or more permission blocks, each with an Effect (Allow/Deny), one or more Action(s) (the API action(s) being granted, e.g. s3:PutObject), and one or more Resource(s) (the ARN(s) it applies to, wildcards allowed).

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

Same shape, just Effect: Deny — this blocks s3:DeleteObject on the bucket no matter what any other Allow statement says, on this policy or any other attached to the identity. This is the "Explicit Deny always wins" rule below in practice.

AWS recommends Customer Managed over Inline in most cases.

IAM Policy Simulator tests what a policy actually allows/denies before you attach it; IAM Access Analyzer continuously scans your account and flags unintended external/public access.

Advanced: A Permissions Boundary sets the maximum permissions an entity (User/Role) can have, no matter what its identity policies allow — Org SCPs work the same way but at the account/OU level. More relevant at Pro level, but good to recognize.

EC2 instance needs an Instance Profile containing exactly one Role.

App on the instance retrieves temporary credentials automatically from instance metadata — no keys to manage.

This is always preferred over storing a User's Access Keys on the instance.

Every action you take — console click, CLI command, SDK call — is an API call. The Console is just a UI wrapper around the same AWS APIs the CLI/SDK use directly. This is why IAM policies grant/deny specific Actions (e.g. s3:PutObject) rather than "console access" vs "CLI access" — the permission is on the underlying API action, not the interface used to trigger it. It's also why CloudTrail can log every single one, regardless of which interface made the call.