devuplabs.cloud
Architecture note4 lab guides4 lab guides

IAM · Identity and Access Management

Policy evaluation logic, roles over users, and privilege escalation hunting.

Outcome

    • Create an IAM user, generate an access key, and explain why users are for humans not workloads
    • Create a group, add a user, and explain why groups are not principals
    • Create a role with a trust policy and explain the difference between trust policy (who) and permission policy (what)
    • Explain why you cannot put a group ARN in a Principal field
    • Describe the difference between a role and a user in terms of credential lifetime
    • Write a valid JSON policy with Sid, Effect, Action, Resource, and explain each field
    • Create a customer-managed policy, attach it to both a group and a role, and check AttachmentCount
    • Create a new policy version, set it as default, and roll back to the previous version
    • Attach an inline policy to a role and explain why it won't show up in list-attached-role-policies
    • Explain the 5-version limit and how to handle it in a CI pipeline
    • Name the three policy types and the one legitimate use case for inline policies
    • Draw the IAM evaluation flowchart from memory (explicit deny → SCP → identity allow → resource allow → boundary)
    • Use iam:SimulatePrincipalPolicy to test a user's effective permissions against specific actions and resources
    • Use iam:SimulateCustomPolicy to test a policy document without attaching it to anything
    • Add an explicit deny inline policy and confirm via simulate that it overrides a group-level allow
    • Explain the difference between implicitDeny and explicitDeny in simulate output and in CloudTrail
    • Explain the same-account vs cross-account resource policy evaluation difference
    • Write an IP restriction using Deny + NotIpAddress + aws:SourceIp
    • Explain why aws:SourceIp doesn't apply to calls from AWS services and what to use instead
    • Write an MFA-required policy using BoolIfExists: false and explain why Bool: false is insufficient
    • Write a region restriction using StringNotEquals + aws:RequestedRegion with NotAction for global services
    • Write an ABAC policy using aws:ResourceTag and aws:PrincipalTag
    • Explain the difference between StringEquals and StringLike with wildcards
    • Explain why Bool: false silently fails for absent condition keys and what BoolIfExists does instead
    • Call sts:AssumeRole: export the three credential components, and verify the assumed identity
    • Explain what the SessionToken is and why all three components are required together
    • Pass a session policy to assume-role and verify it restricts permissions below the role's policy
    • Explain why a session policy can only restrict, never expand permissions
    • Hit the MaxSessionDuration limit and update the role to allow a longer session
    • Explain the two-sided door: trust policy (who can knock) vs permission policy (what they can do inside)
    • Describe the trust policy configuration for cross-account role assumption
    • Explain when the trust policy should list an account root vs a specific role ARN
    • Perform a two-hop role chain (caller → source role → target role) and verify identity at each step
    • Explain the confused deputy problem with a concrete scenario
    • Create a role with an External ID condition and confirm that missing/wrong IDs fail
    • Explain where External ID should be stored and who generates it
    • Create an EC2 service role and explain why an instance profile is required (Lambda/ECS don't need one)
    • Name the correct service principal for EC2, Lambda, and ECS task roles
    • Explain how credentials get into the execution environment for each service (IMDS, env vars, task endpoint)
    • Register a GitHub OIDC provider and create a role with a repo-scoped trust condition
    • Explain how to scope the GitHub trust to main branch only vs all branches
    • Describe what permissions: id-token: write does in a GitHub Actions workflow
    • Attach a permission boundary to a role and confirm it blocks actions the identity policy allows
    • Explain the intersection semantics: effective = identity policy ∩ boundary
    • Explain why a broad boundary with an empty identity policy still results in implicitDeny
    • Explain why iam:PassRole exists (privilege escalation prevention) with a concrete attack scenario
    • Write a scoped iam:PassRole policy restricted by ARN pattern AND iam:PassedToService condition
    • Explain why iam:PassRole on Resource: * without a condition is a high-severity finding
    • Draw the five-layer evaluation chain from memory in order
    • Explain at which layer explicit Deny kills the request regardless of other layers
    • Explain the difference between SCPs with Allow (sets ceiling) vs Deny (hard block)
    • Explain which principal SCPs do NOT apply to (management account root user)
    • Simulate SCP + identity policy interaction using simulate-custom-policy with --permissions-boundary-policy-input-list
    • When given an AccessDenied error, describe the order in which you'd check each layer
    • Create an Access Analyzer with type ACCOUNT and explain what zone of trust means
    • Generate a finding by attaching a public S3 bucket policy and verify the finding JSON structure
    • Explain the difference between RESOLVED (policy changed) and ARCHIVED (acknowledged) findings
    • Use validate-policy to lint a policy document before deploying it
    • Pass the correct --policy-type to validate-policy and explain why mixing them gives errors
    • Explain the difference between external access analysis and unused access analysis
    • Call generate-service-last-accessed-details with SERVICE_LEVEL and ACTION_LEVEL granularity
    • Identify which services show lastAuthenticated: null and explain what that means
    • Write a tightened policy using only the actions confirmed as used
    • Validate the tightened policy with validate-policy and verify with simulate-custom-policy
    • Explain the difference between service-level and action-level last-accessed data
    • Describe a quarterly process for applying this workflow to production roles
    • Start a policy generation job with generate-policy and poll for completion
    • Read the generated policy and identify at least two things that would need manual review
    • List five gaps that policy generation cannot address (future paths, denied calls, cross-region, etc.)
    • Validate a generated policy with validate-policy before using it
    • Generate and download the credential report using the CLI
    • Parse it to find users with access keys older than 90 days
    • Parse it to find users with console access but no MFA
    • Check the root account's key and MFA status and explain why root keys should never exist
    • Use get-account-summary to get an aggregate IAM inventory snapshot
    • Find orphaned (unattached) customer-managed policies
    • Use lookup-events to find recent AssumeRole and iam.amazonaws.com events
    • Read a raw CloudTrail event JSON and extract: caller ARN, event name, target resource, source IP
    • Deliberately generate an AccessDenied event and locate it in CloudTrail
    • Read the errorMessage and identify which layer (identity, resource, SCP, boundary) caused the denial
    • Describe the six-step AccessDenied debugging workflow from memory
    • Explain why you should never fix AccessDenied by adding Action: * / Resource: *
    • Name five common IAM privilege escalation paths and explain why each works
    • Identify that iam:PassRole on Resource: * without iam:PassedToService is a high-severity escalation path
    • Use simulate-principal-policy to detect a full escalation chain (PassRole + CreateFunction + InvokeFunction)
    • Write a fixed PassRole policy scoped to both a role ARN pattern AND a specific service
    • Explain why iam:CreatePolicyVersion on Resource: * is an escalation path
    • Explain the difference between trusting arn:aws:iam::ACCOUNT:root vs a specific role ARN
    • Demonstrate that any principal in a trusted account can pivot to the target role when root is trusted
    • Update a trust policy from account-root to specific-role and verify the narrowing
    • Explain why ExternalId should always accompany cross-account trust for third-party integrations
    • Describe how a compromised Lambda role in Account A can reach prod data in Account B via a broad trust
    • List the four trust condition levels for GitHub OIDC from broadest to narrowest
    • Explain the security difference between StringLike: repo:org/* and StringEquals: repo:org/repo:environment:production
    • Update a GitHub role trust from org-wide to environment-scoped and verify the change
    • Apply a permission boundary to a GitHub role and explain why it matters even after fixing the trust
    • Explain what GitHub environment protection rules add on top of the IAM trust condition
    • Create a CloudWatch metric filter that counts IAM write events from CloudTrail logs
    • Create an alarm that fires on the first IAM change within a 5-minute period
    • Write a baseline snapshot of IAM roles (trust policies, managed policies, boundaries)
    • Run drift detection against the baseline and identify an added managed policy
    • Describe how you would run this detection on a nightly Lambda schedule
    • Execute all six IR steps in order: contain, scope, blast radius, evict, review, close
    • Disable a compromised access key and verify the status change
    • Look up all CloudTrail events for a username in the last 12 hours
    • Apply the aws:TokenIssueTime deny policy to revoke active STS sessions
    • Explain why deleting an access key does NOT revoke active STS sessions derived from it
    • Explain what information to include in the incident summary (key, timeline, resources, next actions)

Unlock all 24 AWS services & 291+ lab sessions (~180 hours)

Pricing