AWS IAM Policy Structure & Components

JSON Anatomy

IAM Policy Document Structure

IAM policies are declared as structured JSON files containing one or more statements that define explicit access rules.

Figure 1: Root structure of a JSON IAM policy document with multiple statements.

JSON Document Scope

IAM policies group permissions into logical statements:

Single Permission Statements: Each block in the `Statement` array controls a specific authorization set.
Multiple Statements: A single policy can declare multiple Statement blocks to manage complex access permissions.
Evaluation Logic: If multiple statements are present in a policy, AWS evaluates them using a logical OR. A request is allowed if any statement allows it and no statement denies it.

Core Policy Rules

Rules governing structural integrity and evaluation:

JSON syntax is case-sensitive for keys (e.g. `Effect`, `Action`).
The `Statement` container holds arrays of permissions.
Explicit Deny in *any* statement always overrides allows in other statements.

Statement Syntax

Core Policy Statement Elements

Understanding the specific keys inside a statement block that establish access results, resource scope, and conditions.

📄

Version

Specifies the version of the policy language. The standard recommended version is `2012-10-17`.

🛡️

Effect

Specifies whether the statement will Allow or Deny the request.

👤

Principal

Specifies the account, user, role, or service that receives permission. Used only in Resource-Based Policies.

⚡

Action

Specifies the specific AWS API operations that are allowed or denied (e.g., `s3:GetObject`).

📦

Resource

Specifies the AWS resources targets (using ARNs) to which the action applies. Mandatory in Identity-Based policies.

⚙️

Condition (Optional)

Specifies dynamic constraints (e.g., source IP, date, instance type) that must be met to grant access.

Resource-Based Security

Example: Resource-Based Policy & NotResource

Analyzing a resource-based policy that utilizes NotResource to explicitly lock down access to all S3 buckets and DynamoDB tables except the ones specified.

Figure 2: S3 bucket policy utilizing Allow and NotResource Deny statement to restrict access.

Allow Statement Details

This statement grants Bob access to specific resources:

Effect: Allow
Actions: All DynamoDB actions (`dynamodb:*`) and S3 actions (`s3:*`).
Resources: DynamoDB table `course-notes` and S3 bucket `course-notes-web` (plus all objects inside `course-notes-mp3`).

Deny Statement & NotResource

This statement explicitly blocks Bob from accessing everything else:

Effect: Deny
Actions: All DynamoDB and S3 actions.
NotResource: Excludes `course-notes` table, `course-notes-web` bucket, and `course-notes-mp3/*` objects from the Deny rule.
Result: Everything not listed in NotResource is explicitly denied. Even if another policy attempts to grant access to other databases or buckets, this Deny statement overrides it.

Identity Permissions

Example: Identity-Based Policy & Dynamic Variables

How identity-based policies use variables like `${aws:username}` to grant dynamic, personalized permissions to users.

Figure 3: Identity-based policy using variables to allow users to manage only their own credentials.

Dynamic Resource Scope

Rather than hardcoding static user ARNs, the policy employs standard variables:

Resource ARN: `arn:aws:iam:::user/${aws:username}`
Variable: `${aws:username}` dynamically resolves to the username of the currently authenticated principal requesting access.
Isolation: This ensures a user can edit and delete only their own passwords, access keys, or SSH keys, while blocking them from modifying other users' properties.

Permissions Granted Matrix

Credential Target	Allowed API Actions
Login Profile (Console Password)	Create, Delete, Get, Update
Access Keys (CLI/API Keys)	Create, Delete, List, Update
SSH Public Keys	Create, Delete, Get, List, Update

Multi-Account Governance

Example: Cross-Account Resource-Based Policy

Examining S3 bucket policies that authorize external AWS accounts to access internal S3 resources.

Figure 4: Cross-account S3 policy in Account A granting access to Account B.

Policy Elements Breakdown

Structure of the cross-account bucket policy in Account A:

Principal: Explicitly lists AWS Account B ID (`111122223333`).
Effect: Allow
Action: `s3:*` (allows all S3 operations).
Resource: Applies to the bucket (`arn:aws:s3:::DOC-EXAMPLE-BUCKET`) and all its contents (`arn:aws:s3:::DOC-EXAMPLE-BUCKET/*`).

Key Delegation Rule

Authorizing access to an external account does not automatically grant access to its users:

The bucket policy in Account A delegates access to Account B.
To perform actions, Account B must attach an Identity-Based Policy to its users, groups, or roles allowing S3 access to Account A's bucket.
Cross-account access requires **double authorization** (resource-based allow in target account + identity-based allow in origin account).

Exam-Style Practice

Activity: IAM Policy Analysis

Analyzing and breaking down three common IAM policies to determine their allowed and denied access states.

Activity 1: Read-Only IAM Permissions

Figure 5: IAM policy providing read-only metadata access to the IAM service.

Actions Allowed

The policy permits any Action matching `iam:Get*` and `iam:List*` on all resources (`"*"`):

Get Operations: `GetGroup`, `GetPolicy`, `GetRole`, `GetUser`, etc.
List Operations: `ListUsers`, `ListGroups`, `ListRoles`, `ListPolicies`.

Blocked Actions

This policy provides metadata view access only. It does not allow:

Creating new users, groups, roles, or policies.
Updating, modifying, or rotating access keys.
Deleting any IAM users or security groups.

Activity 2: Conditional EC2 Termination by IP

Figure 6: EC2 termination policy conditional on source IP address ranges.

Policy Evaluation Logic

This policy contains two statement blocks:

Statement 1: Explicitly allows `ec2:TerminateInstances` on all resources (`*`).
Statement 2: Explicitly denies `ec2:TerminateInstances` if the source IP address is **not** in the ranges `192.0.2.0/24` or `203.0.113.0/24` (using `NotIpAddress`).

Access Outcomes

Inside the IP Ranges: Allowed. The Deny statement does not trigger, and Statement 1 allows termination (e.g. source IP `192.0.2.243` is Allowed).
Outside the IP Ranges: Denied. The Deny statement triggers, overriding Statement 1 and blocking access.

Activity 3: EC2 Instance Type Restrictions

Figure 7: Policy denying EC2 run/start actions for non-standard instance types.

Policy Scope

How this Deny-only policy functions:

Effect: Deny
Actions: `ec2:RunInstances` (launching) and `ec2:StartInstances` (starting).
Condition: `StringNotEquals` on `ec2:InstanceType` for `t2.micro` and `t2.small`.
Outcome: Explicitly denies running or starting instances if the requested type is not `t2.micro` or `t2.small`.

Adding an Allow Statement

Since a Deny statement alone grants zero access, an Allow statement (e.g. `ec2:*` on `*`) must be attached to the user:

Resulting permissions: The user can execute all EC2 actions (e.g., listing, describing, terminating instances).
Termination: Terminating an instance (like `m3.xlarge`) is Allowed, because the Deny statement only applies to RunInstances and StartInstances.
Running/Starting: Running or starting any instance type other than `t2.micro` or `t2.small` is Denied.

IAM Policy Structure
& Elements

IAM Policy Document Structure

JSON Document Scope

Core Policy Rules

Core Policy Statement Elements

Version

Effect

Principal

Action

Resource

Condition (Optional)

Example: Resource-Based Policy & NotResource

Allow Statement Details

Deny Statement & NotResource

Example: Identity-Based Policy & Dynamic Variables

Dynamic Resource Scope

Permissions Granted Matrix

Example: Cross-Account Resource-Based Policy

Policy Elements Breakdown

Key Delegation Rule

Activity: IAM Policy Analysis

Activity 1: Read-Only IAM Permissions

Actions Allowed

Blocked Actions

Activity 2: Conditional EC2 Termination by IP

Policy Evaluation Logic

Access Outcomes

Activity 3: EC2 Instance Type Restrictions

Policy Scope

Adding an Allow Statement

Key Takeaways: Parts of an IAM Policy

Core Exam Keywords

IAM Policy Structure& Elements

IAM Policy Document Structure

JSON Document Scope

Core Policy Rules

Core Policy Statement Elements

Version

Effect

Principal

Action

Resource

Condition (Optional)

Example: Resource-Based Policy & NotResource

Allow Statement Details

Deny Statement & NotResource

Example: Identity-Based Policy & Dynamic Variables

Dynamic Resource Scope

Permissions Granted Matrix

Example: Cross-Account Resource-Based Policy

Policy Elements Breakdown

Key Delegation Rule

Activity: IAM Policy Analysis

Activity 1: Read-Only IAM Permissions

Actions Allowed

Blocked Actions

Activity 2: Conditional EC2 Termination by IP

Policy Evaluation Logic

Access Outcomes

Activity 3: EC2 Instance Type Restrictions

Policy Scope

Adding an Allow Statement

Key Takeaways: Parts of an IAM Policy

Core Exam Keywords

IAM Policy Structure
& Elements