Identity and Access Management

A failed S3 call can mean two completely different things, and the fix lives in two different places. Either the caller never got a valid credential, or the caller has one but no policy lets the action through. AWS keeps these halves strictly separate: authentication proves a principal's identity and hands back a credential, then authorization evaluates policies against that identity to decide the action. Identity and Access Management is the largest domain on the SCS-C03 at 20% of scored content, and most of its questions are really asking which half owns the problem. The classic trap is an authentication question dressed up in permission language (a federation trust that won't establish, an expired session, a missing MFA prompt) where the tempting distractor edits a policy. Read for the verb: if the caller cannot get a valid credential, it is authentication; if the credential is valid but the request is blocked, it is authorization.

Read this page as a map, then follow the two subtopics in order. Authentication covers the first half: matching each identity type to its canonical AWS home (IAM Identity Center for the human workforce, Amazon Cognito for application and customer end users, IAM roles plus AWS Security Token Service, or STS, for machines and services), preferring short-lived credentials over long-lived access keys, and layering MFA (multi-factor authentication) on top so a stolen password alone cannot sign in. Authorization covers the second half: the IAM policy-evaluation model that turns an authenticated principal into a yes or no on every API call. That model is where ABAC (attribute-based access control) versus RBAC (role-based access control), permission boundaries, cross-account trust, and IAM Access Analyzer all live. Authentication decides whether you get in the door; authorization decides which rooms you can enter.

Across both halves the exam rewards the same instinct: the most secure option that still meets the requirement. For identity that means temporary STS credentials over long-lived IAM user access keys, federation over per-employee IAM users, and a strong MFA device on the root user that is then locked away. For permissions it means the least-privilege grant and a ceiling that caps it: a permission boundary, service control policy, or resource control policy that can only narrow what an explicit allow already gave, never grant on its own. You rarely need a memorised exception; the managed, expiring, least-privilege default is the exam-correct answer far more often than not.