Identity, Access, and Privilege Management in the Cloud
Domain 2: Identity, Access, and Privilege Management in the Cloud
This domain tests authorization mechanics: who can do what, under which conditions, and how you prove least privilege. Expect federation, role trust, policy evaluation, privilege elevation, and access review.
Core rules
- Prefer federated human access through SAML or OIDC into short-lived role sessions; avoid long-lived access keys.
- Cloud policy evaluation is explicit-deny-wins and default-deny. In AWS, identity policies, resource policies, permission boundaries, SCPs, and session policies all interact.
- A role trust policy defines who may assume it; the permission policy defines what the role can do. Both must be correct.
- Use permission boundaries to cap delegated permissions, SCPs for organization-wide guardrails, and just-in-time elevation for admin tasks.
- CIEM tools find unused permissions; access reviews and entitlement management remove drift.
Worked example
A vendor needs to write to a customer's S3 bucket. The customer creates a cross-account role with a trust policy that requires the vendor account and an external ID. The permission policy allows s3:PutObject on one prefix, not s3:. Reasoning: the external ID mitigates the confused-deputy risk; the prefix limits blast radius; the vendor uses STS temporary credentials. If the trust policy used Principal '' without conditions, the design fails even if the permission policy is narrow.
Traps
- Wildcard actions such as s3:* or iam:PassRole without conditions.
- Confusing authentication with authorization.
- Assuming a resource policy alone is enough for cross-account access; the caller's identity policy must also allow it.
- Forgetting that SCPs do not grant permissions; they only filter.
- Leaving access keys active after federation rollout.