← Back to Labs Executive Study Guide

AWS · L2 Authorization Model · Executive Learning Path

AWS L2 Authorization Model

Executive, mentor, and student study guide for understanding how AWS authorization decisions are made, constrained, exposed, and protected across identity, organization, resource, storage, and cryptographic layers.

Audience Executive / Mentor
L2 LABs 6
Model Authorization
Runtime Read-only

Executive Overview

The AWS L2 Authorization Model explains how cloud access is actually decided. It turns six technical LABs into one clear learning path for students, interns, mentors, security engineers, CISOs, and executives.

The key lesson is simple: AWS authorization is not one policy. It is a layered decision system. 

Identity policy
→ principal boundary
→ organization guardrail
→ resource policy
→ applied exposure state
→ cryptographic access control

Visual Authorization Model

This visual model shows how the six L2 labs work together.

1. IAM Policy Evaluation Can the principal request the action?
→
2. Permission Boundary Does the principal stay inside its maximum authority?
→
3. SCP Guardrail Does the account or OU allow this class of action?
4. Resource Policy Does the resource trust or deny the principal?
→
5. S3 Public Exposure Do policies and safety controls create public reachability?
→
6. KMS Key Policy Can the principal use the key to decrypt protected data?
Executive rule: cloud risk is the final state of multiple controls, not a single setting.

The Six L2 LABs

These six labs form the AWS Intermediate Identity and Authorization curriculum.

1. AWS IAM Policy Evaluation Identity-side authorization, explicit deny, and effective permission reasoning. 2. AWS Permission Boundary Basics Principal-level maximum authority and delegated administration controls. 3. AWS SCP Guardrail Reasoning Organization and account-level maximum authority. 4. AWS Resource Policy Evaluation Resource-side trust, explicit deny, and cross-account authorization. 5. AWS S3 Public Access Risk Applied public exposure reasoning across policy, ACLs, public blocks, and guardrails. 6. AWS KMS Key Policy Evaluation Cryptographic authorization across key policies, grants, context, and IAM permissions.

Study Paths

Students Start with IAM Policy Evaluation, then move one layer at a time until KMS key policy reasoning feels natural.
Interns Use the visual model to explain each authorization layer out loud before opening the detailed LAB.
Mentors Teach one LAB per session, then use S3 and KMS to show applied business risk.
CISO / Executive Review Use the model to ask whether identity, resource, organization, storage, and cryptographic controls agree.

Concept Deep Dives

Expand these concepts during mentoring, executive walkthroughs, or quick mobile study.

What is effective permission?

Effective permission is the final result after every relevant policy layer is evaluated. A single allow is not enough. The request must survive identity policy, boundaries, SCPs, resource policies, and explicit deny.

What is a guardrail?

A guardrail is a control that limits what can happen even when a local policy appears to allow it. Permission boundaries constrain principals. SCPs constrain accounts and organizational units.

Why does resource-side authorization matter?

A resource can decide who it trusts. Bucket policies, key policies, queue policies, topic policies, and role trust policies all participate in authorization.

Why does KMS change the risk conversation?

KMS controls whether encrypted data can actually be decrypted. A user may reach a storage object, snapshot, or secret, but still fail if KMS denies decrypt authority.

What should executives ask?
  • Which identities can change access state?
  • Which guardrails prevent excessive authority?
  • Which resources trust external or broad principals?
  • Which data remains protected by cryptographic controls?
  • Which controls are proven by evidence instead of assumption?

Governance Boundary

This guide is a static learning artifact. It summarizes existing L2 LABs and does not create runtime authority. 

Runtime = source of truth
OPA = decision authority
Aegis = bounded intelligence
Frontend = rendering only
  • Does not exploit AWS
  • Does not mutate infrastructure
  • Does not deploy live resources
  • Does not issue runtime tokens
  • Does not create Shield findings
  • Does not create Aegis fixtures
  • Does not override OPA