Day 2 - IAM Fundamentals: Users, Groups, Roles, Policies, and the Basic Flow of Policy Evaluation

🔍 Going deeper: What "assuming" a Role actually means is that STS (Security Token Service) issues a set of three temporary credentials (AccessKeyId, SecretAccessKey, SessionToken). These credentials have an expiration time (default 1 hour, maximum 12 hours), so even if they are exposed, the impact is bounded in time. This is the fundamental reason they are safer than long-term keys, and we cover STS in depth on Day 4.

Two Kinds of Policies: Identity-based vs Resource-based

Policies split into two kinds by "where they attach." Today we only establish the concept; Day 3 goes deep.

• Identity-based policy: Attaches to a User, Group, or Role. Describes "what this principal can do." It has no Principal element (whoever it attaches to is the principal).
• Resource-based policy: Attaches directly to a resource (S3 bucket, KMS key, SQS queue, etc.). The Principal element is required — it describes "who can access this resource."

The decisive utility of resource-based policies is that they enable cross-account access. To open your S3 bucket to a principal in another account, you specify the other account in the bucket's resource-based policy.

IAM Policy JSON Structure

Every policy is an array of Statements, and each Statement has the following elements.

• Effect: Allow or Deny
• Action: The API action to allow/deny (s3:GetObject). Wildcards (s3:*) are allowed
• Resource: The target ARN. Required in identity-based policies; in resource-based policies it is usually * (the policy is already attached to that resource)
• Principal: Who (used only in resource-based policies and trust policies)
• Condition: Additional constraints (IP, MFA, time, encryption status, etc.)

⚠️ Pitfall: Combining "Resource": "*" with "Action": "*" is effectively admin. When the exam asks about "least privilege," the answer choice that narrows the wildcards is correct. In particular, s3:ListBucket applies to the bucket ARN (arn:aws:s3:::bucket), while s3:GetObject applies to the object ARN (.../*) — mixing up the two ARN levels so the policy does not work is a common mistake.

The Basic Policy Evaluation Flow: The Algorithm That Decides Allow/Deny

This is today's core. Within a single account, when a request comes in, AWS decides in the following order.

[ IAM policy evaluation flow (single account) ]

  Request (Principal + Action + Resource + Context)
        |
   1. Collect all applicable policies
      (Identity-based, Resource-based, SCP, Permissions Boundary, Session policy)
        |
   2. Is there even one explicit Deny?  ── Yes ──▶  DENY (top priority, unconditional)
        | No
   3. Does the SCP allow this Action? ── No ──▶ DENY
        | Yes
   4. Does the Permissions Boundary allow it? ── No ──▶ DENY
        | Yes
   5. Is there even one explicit Allow? ── No ──▶ DENY (implicit deny)
        | Yes
        ▼
      ALLOW

It compresses into three principles.

1. The default is implicit deny: If no policy allows it, it is denied. Permissions must be granted explicitly.
2. An explicit Allow overrides the implicit Deny: If something explicitly allows it, the default denial is lifted.
3. An explicit Deny beats everything (explicit deny overrides): No matter what policy allows it, if any other policy contains an explicit Deny, it is unconditionally denied.

💡 Related theory: When memorizing this evaluation order, the key point is that "guardrails (SCPs, Permissions Boundaries) do not grant permissions — they only draw an upper bound." Even if an SCP allows s3:*, that alone creates no permissions — there must be an explicit Allow in an identity-based policy. An SCP only defines the "maximum allowed scope." That is why the common pattern in SCPs is not Allow but Deny guardrails.

🔍 Going deeper: In the cross-account case, evaluation happens separately in both accounts. For a principal in account A to access a bucket in account B, you need ① an Allow in account A's identity-based policy and ② account B's resource-based policy allowing A — both are required (within the same account, either one alone suffices). This "both sides" rule is the recurring trap in cross-account scenarios.

Reading the Evaluation Flow Through Scenarios

Let's hold the abstract algorithm up against concrete situations.

Situation 1: A developer has admin permissions, but you want to block only one specific S3 bucket. The identity-based policy is AdministratorAccess, so it allows everything. If you add an explicit Deny statement (e.g., "Effect": "Deny" on the specific bucket ARN), the explicit Deny beats the Allow, and only that bucket is blocked. Put the same Deny in an SCP and it is enforced across the whole account.

Situation 2: An SCP explicitly denies ec2:*, but the user has AmazonEC2FullAccess. The result is Deny. The SCP's explicit Deny beats everything. The Allow in the user's policy is neutralized. This is why SCPs are used as governance guardrails.

🎯 Scenario: A security team wants to prevent CloudTrail from being disabled in all accounts. The answer is not to modify per-user policies but to apply an SCP denying cloudtrail:StopLogging and cloudtrail:DeleteTrail to the OU. Then even an admin or root in that account cannot turn off CloudTrail (the management account root is exempt from SCPs). It is the governance application of the principle that an explicit Deny beats every Allow.

Policy Debugging Tools: Verifying Who Can Do What

If you trace the evaluation logic only in your head, you will make mistakes. AWS provides verification tools.

📚 Case study: In production, 80% of "why is access denied" comes down to four causes: ① implicit Deny (nothing allows it), ② a hidden Deny in an SCP, ③ exceeding a Permissions Boundary, ④ only one side allowed in a cross-account setup. The habit of first checking "which role am I right now" with aws sts get-caller-identity cuts debugging time in half. CloudTrail's AccessDenied events leave clues about which policy caused the denial.

IAM Access Analyzer: Detecting Unintended External Exposure

IAM Access Analyzer analyzes resource policies to automatically find resources that allow access from outside the account or organization boundary. If an S3 bucket, IAM role, KMS key, Lambda function, etc. is open to an external principal, it generates a finding.

This is the intersection of Domain 2 (detection) and Domain 4 (IAM). A human cannot manually review hundreds of buckets and roles, so "access crossing the trust boundary" is detected automatically. The policy generation feature also analyzes CloudTrail logs to build a least-privilege policy from only the permissions actually used.

💡 Related theory: The core of Access Analyzer is the external vs trusted distinction. Access within the same account or organization is treated as normal; only access crossing that boundary is raised as a finding. If you "set the zone of trust to the organization," cross-account access within the organization is treated as normal and only genuine external exposure is caught.

Wrapping Up — IAM Is an Algorithm

Today's three key points. First, among IAM's building blocks, use Roles (temporary credentials) by default and avoid Users (long-term keys) — this is the starting point of every best practice. Second, policy evaluation is an algorithm of three principles — implicit Deny → explicit Allow overrides it → explicit Deny beats everything — and SCPs and Permissions Boundaries do not grant permissions, they only draw the upper bound. Third, cross-account access requires allows in both accounts.

Tomorrow we dig deeper into policies. We cover the subtle interplay of Identity vs Resource policies, precision control using Condition keys, and practical patterns for designing least privilege with Permissions Boundaries. The evaluation algorithm you learned today is the foundation for all of it.