Table of Contents

This course treats identity policy as executable security design. You will model principals, calculate effective access, design human and workload controls, test a disposable provider lab, and prove teardown.

The course compares AWS, Azure, and Google Cloud without hiding their different policy models. Provider terms stay explicit.

Audience

This course serves cloud administrators, security engineers, DevOps practitioners, and auditors who need practical identity access skills.

You should understand accounts, command-line tools, and JSON. Prior provider certification is optional.

Outcomes

By the end, you will produce:

  • An identity map for human and workload principals
  • An effective-permissions worksheet across policy layers
  • A human access design with federation, MFA, session, and emergency controls
  • A workload identity design without long-lived access keys
  • A zero trust access policy using identity, device, resource, context, and telemetry
  • A disposable lab record with preflight checks, grant inspection, AWS policy simulation where selected, teardown, and absence checks
  • An access review decision log and remediation plan

Course Order

#LessonSkill and output
1Identity ModelMap principals, credentials, sessions, roles, and resources
2Effective PermissionsEvaluate allows, boundaries, conditions, inheritance, and denies
3Human AccessDesign federation, MFA, privileged access, and recovery
4Workload IdentityReplace stored keys with short-lived identity
5Zero Trust PolicyBuild resource-focused, context-aware access decisions
6Disposable Cloud LabCreate, test, and remove narrow access in one provider
7Quiz and Answer KeyCheck policy and teardown knowledge
8Capstone and Answer KeyReview access and deliver a zero trust migration plan

Prerequisites

  • One disposable provider sandbox for the optional live lab
  • AWS CLI, Azure CLI, or Google Cloud CLI for the selected track
  • Permission to create and remove lab identities and role assignments
  • A second administrator or recovery route before changing privileged access
  • A clean folder for downloaded policy files and evidence

The concept lessons and capstone work offline. The live lab changes cloud identity state. Use a dedicated sandbox without production resources.

Safety Rules

  1. Confirm the active account, tenant, subscription, or project before every change.
  2. Check that every exact sos-iam-lab object name is absent before creation. Stop on a collision or an uncertain result.
  3. Grant read-only access at the narrowest lab scope.
  4. Do not create access keys or client secrets.
  5. Save identifiers returned by successful create commands. Delete only objects recorded as created by this run.
  6. Run teardown in the same session for those recorded objects.
  7. Verify absence after deletion.

Expected Result: the lab ends with no temporary identity, role assignment, policy, group, or project binding left behind.

Zero Trust Baseline

NIST SP 800-207 removes implicit trust based on network location or asset ownership. NIST SP 800-207A applies identity-tier and network-tier policy to cloud-native and multi-cloud applications. In this course, access decisions use the principal, credential, device or workload, resource, action, context, and current telemetry.

Primary references, checked 2026-10-10: NIST SP 800-207 , NIST SP 800-207A , AWS IAM policy evaluation logic , Microsoft Entra Conditional Access , and Google Cloud service account security .

Troubleshooting

  • No cloud sandbox exists: complete Lessons 1 through 5 and the offline capstone with synthetic data.
  • CLI access is denied: record the denied action and use an approved sandbox operator.
  • Provider terms conflict: return to the identity comparison and preserve provider-specific names.

Verify Readiness

  • The active provider context is recorded
  • The environment holds no production resources
  • Create and delete permissions are approved
  • A recovery administrator exists outside the lab identity

Expected Result: the selected lab environment has a known owner, bounded scope, and verified teardown route.

Start Here

Begin with Lesson 1: Identity Model . Draw the access path before writing policy.