Anatomy of an IAM Policy Document
Read the effect, action, resource, and condition of a policy.
Anatomy of an IAM Policy Document is a free AWS Security Academy lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the AWS Security Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Policies Define Permissions
In AWS, permissions are expressed as policies: JSON documents that grant or deny access to actions on resources. Reading a policy fluently is a core SCS-C02 skill, because almost every access question comes down to what a policy allows, denies, or fails to cover. This lesson dissects the structure piece by piece.
The Statement Array
A policy contains a Version field (use "2012-10-17") and a Statement element, which is one statement or an array of them. Each statement is an independent rule. AWS evaluates every statement, so a single document can both allow some actions and explicitly deny others.
Effect: Allow or Deny
Every statement has an Effect of either Allow or Deny. AWS is deny-by-default: with no matching Allow, a request is denied. A matching Deny always wins over any Allow. Recognizing the Effect of each statement is the first thing to check when reasoning about access.
Action and NotAction
The Action element lists the API operations the statement applies to, written as service:operation, for example s3:GetObject. Wildcards are allowed, like s3:* or s3:Get*. The inverse, NotAction, matches every action except those listed, and is easy to misuse, so the exam tests it carefully.
Resource and NotResource
The Resource element names which resources the actions apply to, using ARNs (Amazon Resource Names). For example a specific bucket and its objects. A value of "*" means all resources. NotResource matches everything except the listed ARNs. Scoping resources tightly is central to least privilege.
A Sample Policy
This identity policy allows reading objects from one bucket only. Notice the action, the specific object-level ARN, and the explicit Allow effect.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::reports/*"
}]
}The Condition Block
An optional Condition block restricts when a statement applies, using context keys and operators. For example, allow only if the request uses TLS (aws:SecureTransport) or comes from a known IP. Conditions are how you add fine-grained, context-aware control beyond just action and resource.
Principal in Resource Policies
Identity-based policies omit the Principal element because they are attached to a principal already. Resource-based policies (like an S3 bucket policy) include Principal to name who the rule applies to. Spotting whether a policy has a Principal tells you which type you are reading.
Wildcards Are Risky
Wildcards such as "Action": "*" and "Resource": "*" together grant full administrative access. The exam frequently shows an over-permissive policy and asks you to tighten it. The fix is to replace wildcards with specific actions and ARNs, applying least privilege.
ARNs Decoded
An ARN has the form arn:partition:service:region:account:resource. Some services omit region or account (S3 omits both for the bucket portion). Reading ARNs precisely lets you tell whether a policy targets one resource, one account, or everything, which directly affects how much access is granted.
Reading Policies Fast
To analyze any policy: check the Effect, read the Action (watch for NotAction and wildcards), scope the Resource (watch for "*"), and inspect any Condition. Remember explicit deny beats allow and deny is the default. With practice you can judge a policy's real reach in seconds, exactly what the exam demands.
Quick Check
Test your policy-reading skill.
Recap
An IAM policy is JSON with a Version and Statement array. Each statement has an Effect (Allow/Deny), Action (or NotAction), Resource via ARNs (or NotResource), and optional Condition. Resource-based policies add a Principal. Deny is the default, explicit deny always wins, and wildcards signal over-permissioning to tighten.
Frequently asked questions
Is the “Anatomy of an IAM Policy Document” lesson free?
Yes — the full text of “Anatomy of an IAM Policy Document” is free to read here on the web, and the AWS Security Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the AWS Security Academy course, upgrade to CoddyKit PRO.
What will I learn in “Anatomy of an IAM Policy Document”?
Read the effect, action, resource, and condition of a policy. You practise AWS Security Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start AWS Security Academy?
No prior experience is required. AWS Security Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Anatomy of an IAM Policy Document” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this AWS Security Academy lesson?
Yes. Every AWS Security Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Anatomy of an IAM Policy Document
- Identity-Based versus Resource-Based Policies
- The Policy Evaluation Decision Flow
- Conditions, Wildcards, and Policy Variables