Table of Contents

Return to the Cloud IAM and Zero Trust Lab Course

Effective access is the final result across every applicable policy layer. Reading one role or binding does not establish the decision.

Use a Decision Record 

Principal:
Session:
Action:
Resource:
Identity grant:
Resource grant:
Boundary or session limit:
Hierarchy control:
Condition:
Explicit deny:
Final decision:
Evidence:

Fill every row. Use not applicable where a layer does not exist.

Compare Evaluation Models

ProviderCore modelReview focus
AWSIdentity and resource allows interact, while boundaries, session policies, SCPs, RCPs, and explicit denies limit resultsPrincipal type, resource policy target, boundary, organization controls, conditions
AzureRole assignments apply at scopes and inherit downward, while deny assignments take precedencePrincipal, role definition, assignment scope, inheritance, deny assignment, condition
Google CloudAllow bindings inherit through the resource hierarchy, deny policies restrict matching permissions, and conditions narrow grantsPrincipal, role, resource ancestry, condition, deny policy

AWS documents identity and resource policies as a union in common same-account cases. Permissions boundaries and organization controls act as intersections. An applicable explicit deny overrides an allow. Resource policy behavior changes with principal type, so read the provider logic before simplifying a decision.

Work an Example

The payroll build identity has these layers:

  • Project-level Editor role from an old group binding
  • Resource-level Reader role on payroll reports
  • Organization deny for policy administration actions
  • Time condition ending Friday at 18:00 UTC

For reports.read, the broad project grant and narrow resource grant both support access during the condition window. For setIamPolicy, the organization deny blocks the action. The correct remediation removes the old Editor grant, then retests required reads.

Review Sample Access

Download the synthetic access review .

  1. Verify the principal owner.
  2. Compare the role with the stated business need.
  3. Check scope size.
  4. Review last-used evidence and its collection limit.
  5. Identify privilege-escalation paths.
  6. Choose keep, reduce, remove, or investigate.
  7. Record a test and rollback plan.

The [email protected] row needs a narrower read role. The [email protected] row needs owner research and a controlled removal plan. Last-used age alone does not prove safe removal.

Expected Result: each decision states the principal, action, resource, applicable layers, final result, and evidence gap.

Troubleshooting

ProblemFix
Console access differs from one policyInspect group membership, inherited scope, resource policies, session limits, and deny layers
A broad role looks unusedCheck audit retention and indirect workload use before removal
A deny surprises an administratorLocate hierarchy controls and the exact denied permission
A condition failsCheck attribute names, time zone, resource tags, and session claims

Verify Your Work

  • One decision record is complete
  • Scope inheritance is included
  • Explicit deny and implicit deny are distinct
  • Principal type is recorded
  • Remediation includes a test and rollback plan
  • Last-used data has a retention caveat

Primary references, checked 2026-10-10: AWS IAM policy evaluation logic , Azure role assignments , and Google Cloud IAM policy overview .

Next Steps

Continue to Lesson 3: Human Access . Build short-lived, monitored administrative access.