IAM building blocks and the policy language

How AWS checks every request

Every call to AWS, whether from the console, the CLI or an SDK, goes through two checks. Authentication proves who is calling. Authorization decides whether that caller may perform this action on this resource. AWS bundles the details of the call into a request context, and your policies are evaluated against it.

{ "Effect": "Deny",
  "Action": "cloudtrail:StopLogging",
  "Resource": "*" }

Two separate questions are asked, in order. First “Are you really who you say you are?” AWS checks the signature on the request (made with a password session, access keys or temporary STS credentials). If that fails, AWS never even looks at your policies. Only after that does it ask “Are you allowed to do this?”

Because the two checks are separate, their errors look different. Learning to tell them apart is a real exam skill (Skill 4.1.3 and 4.2.4).

$ aws sts get-caller-identity
An error occurred (InvalidClientTokenId) when calling the
GetCallerIdentity operation: The security token included
in the request is invalid.

$ aws s3 cp report.csv s3://finance-data/
An error occurred (AccessDenied) when calling the PutObject
operation: User: arn:aws:sts::111122223333:assumed-role/AppRole/i-0abc
is not authorized to perform: s3:PutObject on resource:
"arn:aws:s3:::finance-data/report.csv"
with an explicit deny in a service control policy

Who can make requests

A principal is a human or workload that can make a request. Inside one AWS account you will meet the following.

AWS best practice: "Require human users to use federation with an identity provider to access AWS using temporary credentials" and "Require workloads to use temporary credentials with IAM roles to access AWS."

Identity vs principal: an identity is something you create in IAM (user, group, role). A principal is something that can actually make a request. Users and roles are both. A group is only a convenient way to attach the same policies to many users, so it is an identity but never a principal.

Long-term vs temporary credentials is the idea the exam returns to most. An IAM user's access key works until someone deletes it, so if it leaks it can be abused for months. A role gives credentials that expire on their own, from 15 minutes up to 12 hours. That is why “use a role” is almost always the most secure answer.

// Trust policy on role "AppServerRole"
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ec2.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

$ aws iam create-instance-profile --instance-profile-name AppServer
$ aws iam add-role-to-instance-profile \
    --instance-profile-name AppServer --role-name AppServerRole
$ aws ec2 associate-iam-instance-profile \
    --instance-id i-0abc123 --iam-instance-profile Name=AppServer

The root user

The root user is the identity created with the account. It has full access, and you cannot attach identity-based policies or a permissions boundary to it. The only policies that can limit root are those from AWS Organizations: an SCP or RCP limits the root user of a member account.

Centralized root access management

In AWS Organizations, the management account or a delegated administrator can remove root credentials from member accounts (password, access keys, signing certificates, MFA). New member accounts can be created with no root credentials. The few privileged root tasks, such as unlocking a misconfigured bucket policy, are then done centrally with a short-lived root session (STS AssumeRoot).

Root is special because it sits outside IAM's control. You can't attach a policy to it or put a boundary on it. So the only ways to protect it are: strong MFA, no access keys, monitoring, and in an organization, SCPs and RCPs or removing the credentials completely.

// EventBridge rule: alert on root console sign-in
{
  "detail-type": ["AWS Console Sign In via CloudTrail"],
  "detail": { "userIdentity": { "type": ["Root"] } }
}

// Centralized root access: unlock a bucket in member account
$ aws sts assume-root \
    --target-principal 444455556666 \
    --task-policy-arn arn=arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy \
    --duration-seconds 900
# then, with those credentials:
$ aws s3api delete-bucket-policy --bucket locked-bucket

Policy types: does it grant, or only limit?

The IAM User Guide lists these policy types. The single most important column is whether a policy type can grant permissions or can only set a maximum.

Managed vs inline

AWS managed policies are written and updated by AWS and are broad. Customer managed policies are reusable, and IAM keeps up to five versions so you can roll back. Inline policies live inside one identity and are deleted with it. AWS recommends customer managed policies for least privilege, and inline only when a policy must stay strictly one-to-one with an identity.

Think of every policy as answering one of two questions. Grant policies answer “what is this person allowed to do?” Limit policies answer “what is the most this person could ever be allowed?” A limit policy on its own gives nothing, and a grant policy is cut back by every limit that applies.

This explains a pattern that shows up in many exam scenarios. If an action is allowed by the identity policy but missing from the boundary or SCP, it is denied. If it is allowed by the SCP but missing from the identity policy, it is also denied. You need the Allow in both places.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CreateRolesOnlyWithBoundary",
      "Effect": "Allow",
      "Action": ["iam:CreateRole", "iam:AttachRolePolicy", "iam:PutRolePolicy"],
      "Resource": "arn:aws:iam::111122223333:role/app/*",
      "Condition": {
        "StringEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::111122223333:policy/DevBoundary"
        }
      }
    },
    {
      "Sid": "ProtectTheBoundary",
      "Effect": "Deny",
      "Action": ["iam:DeleteRolePermissionsBoundary",
                 "iam:CreatePolicyVersion", "iam:DeletePolicy"],
      "Resource": "*",
      "Condition": { "ArnLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/Developer*" } }
    }
  ]
}

SCPs protect your principals, RCPs protect your resources

Both are AWS Organizations guardrails, but they face in opposite directions. An SCP limits what your identities can do, wherever the resource is. An RCP limits what anyone, including outsiders, can do to your resources.

The easiest way to tell them apart is to ask whose rule is being written. An SCP is written about your people: wherever they go, they carry the SCP with them. An RCP is written about your things: whoever comes to them, the RCP is waiting at the door.

So if the risk is “my staff copying data out to their personal account”, the SCP side is the answer. If the risk is “an outsider getting into my bucket because someone wrote a bad bucket policy”, only the RCP can stop it, because your SCPs never apply to someone else's identities.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "EnforceOrgIdentities",
    "Effect": "Deny",
    "Principal": "*",
    "Action": ["s3:*", "sqs:*", "kms:*", "secretsmanager:*", "sts:AssumeRole"],
    "Resource": "*",
    "Condition": {
      "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "o-abc123xyz" },
      "BoolIfExists": { "aws:PrincipalIsAWSService": "false" }
    }
  }]
}

Anatomy of a policy

Every JSON policy has the same parts. Read it as a sentence: Effect the Action on the Resource, for the Principal, when the Condition is true.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ReadReportsFromOfficeWithMFA",
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:ListBucket"
    ],
    "Resource": [
      "arn:aws:s3:::reports",
      "arn:aws:s3:::reports/*"
    ],
    "Condition": {
      "IpAddress": {
        "aws:SourceIp": "203.0.113.0/24"
      },
      "Bool": {
        "aws:MultiFactorAuthPresent": "true"
      }
    }
  }]
}

Read every statement as an English sentence with five parts. Effect is the verb of permission (allow or deny). Principal is the subject (who). Action is the verb (what they do). Resource is the object (on what). Condition is the “only if” clause. Once you read policies this way, long policies stop being scary.

A policy can have many statements. AWS evaluates all of them; the order of statements in the file does not matter.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "PartnerRead",
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::444455556666:root" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::shared-reports/*"
  }]
}

Reading an ARN

An Amazon Resource Name identifies one resource. Its fields are separated by colons, and some services leave fields empty.

arn:aws:iam::111122223333:role/app/OrdersFn
                                 └─path─┘

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::111122223333:role/app/*",
  "Condition": {
    "StringEquals": { "iam:PassedToService": "lambda.amazonaws.com" }
  }
}

Conditions and condition keys

A condition is "Operator": { "key": "value" }. How several conditions combine is a favourite exam detail.

"Condition": {
  "StringEquals": { "aws:PrincipalOrgID": "o-abc123xyz" }
}

Operators to recognise

StringEquals, StringLike (with * and ?), StringNotEquals, ArnLike, IpAddress / NotIpAddress, Bool, NumericLessThan, DateGreaterThan, and Null (is the key present?). Add IfExists to apply the test only when the key exists. For keys with several values, such as aws:TagKeys, use ForAllValues: or ForAnyValue:.

Global condition keys the exam uses most

Two traps, illustrated

Policy variables

One policy can give each user their own folder: "Resource": "arn:aws:s3:::home/${aws:username}/*". You can also use tags, such as ${aws:PrincipalTag/team}. Variables only work with "Version": "2012-10-17".

Conditions are where most exam questions hide their tricks, because one word (IfExists, ForAllValues, Not) can flip the meaning.

IfExists means: “If the key is in the request, test it. If the key is missing, treat the condition as true.” In an Allow that makes the rule looser. In a Deny that makes the rule stricter, which is exactly what you want for MFA.

ForAllValues means every value in the request must be in your list; it is also true when the request has no values at all, so pair it with a Null check if the key is required. ForAnyValue means at least one value must match.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ManageOnlyMyProjectInstances",
      "Effect": "Allow",
      "Action": ["ec2:StartInstances", "ec2:StopInstances"],
      "Resource": "arn:aws:ec2:*:111122223333:instance/*",
      "Condition": { "StringEquals": {
        "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}" } }
    },
    {
      "Sid": "LaunchOnlyWithAllowedProjectTag",
      "Effect": "Allow",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:111122223333:instance/*",
      "Condition": { "StringEquals": {
        "aws:RequestTag/Project": ["alpha", "beta"] } }
    }
  ]
}

Cheatsheet extras: password policy, key rotation and policy limits

Your cheat sheet (older SCS-C02 material) spends time on IAM user hygiene: the account password policy, how to rotate access keys without breaking an application, what to do when a previous admin used the root user, and the size limits of each policy type. These are small facts, but they turn up as “which TWO steps” and “least disruption” questions. Today the best answer is still “no IAM users at all, use roles and IAM Identity Center”, but when the question has IAM users, these are the rules.

Rotating an access key without downtime

An IAM user can have two access keys at once. That is exactly what makes zero-downtime rotation possible: create the second key, move the application to it, check the old key is no longer used, deactivate it (your roll-back path), and only then delete it. If the key is leaked, skip the waiting: deactivate it at once and accept the short outage.

$ aws iam create-access-key --user-name build-bot
{ "AccessKey": { "AccessKeyId": "AKIAEXAMPLENEWKEY111", "Status": "Active", ... } }

# 2. update the application / secret store to use the new key, redeploy

$ aws iam get-access-key-last-used --access-key-id AKIAEXAMPLEOLDKEY000
{ "UserName": "build-bot",
  "AccessKeyLastUsed": { "LastUsedDate": "2026-10-18T09:12:00Z", "ServiceName": "s3", "Region": "eu-west-1" } }

$ aws iam update-access-key --user-name build-bot --access-key-id AKIAEXAMPLEOLDKEY000 --status Inactive
# watch the app for a while; if something breaks, set it back to Active

$ aws iam delete-access-key --user-name build-bot --access-key-id AKIAEXAMPLEOLDKEY000

Policy size and count limits

Older material quotes these as “2 KB for users, 5 KB for groups, 10 KB for roles, 20 KB for bucket policies”. They are really character quotas, and they matter when a question says a policy “can’t be saved” or “has grown too large”.

Hands-on lab (30 minutes)

Use a personal sandbox account, never a work production account.

1. Turn on MFA for the root user and confirm root has no access keys (IAM console, Security credentials).
2. Create a bucket and a role named lab-s3-reader with an inline policy that allows only s3:GetObject on arn:aws:s3:::your-bucket/*.
3. Assume the role (console "Switch role" or aws sts assume-role) and run aws s3 ls s3://your-bucket. You should get AccessDenied.
4. Add s3:ListBucket on arn:aws:s3:::your-bucket (no /*) and try again. It now works. You have just met exam trap number one.
5. In the IAM policy editor, notice the warnings and suggestions under the editor. That is IAM Access Analyzer policy validation, which Day 6 covers.

Lecture summary map

The whole lecture on one screen. Use the three pictures below to review: the mind map for the structure, the keys-fences-wall picture for how permissions work, and the keyword chart for answering exam questions fast.

1. Mind map

2. Keys, fences and a wall

3. “If the question says… pick…”

Exam questions are full of signal words. When you spot the words on the left, the answer is usually the one on the right.

Must-remember cheat sheet

Read this the night before the exam. Each line is something the exam has a habit of testing.

Practice quiz

Pick an answer, then press Check. Multiple-response questions say how many to choose.

Practice test questions (from your mock exams)

These questions come from your own mock exams (the SCS-003 mock 1–9 files in your study folder), matched to this lecture. Wording was tidied and checked against current AWS behavior; where a mock answer was outdated or wrong, the explanation says so. The source is shown at the end of each explanation, like “(Mock 5 · Q12)”. Pick an answer, then press Check.