IAM carries the single largest domain weight on SCS-C03 (20%), and Task 4.1 opens it with the foundational question every other control depends on: proving who or what is actually making a request, for humans, applications, and systems alike.
Identity Solutions for Humans, Applications, and Systems
AWS IAM Identity Center (successor to AWS SSO) is the exam's answer for centralized human workforce identity across an AWS Organization -- it provides single sign-on to multiple AWS accounts and business applications from one place, typically federated from an external identity provider (IdP) rather than maintaining a separate credential per account. Amazon Cognito serves a different population: it handles identity for the end users of an application you build (a mobile app's customers, a web app's registered users), providing user pools (a managed user directory with sign-up/sign-in) and identity pools (which grant those authenticated app users temporary AWS credentials scoped to what the application needs). Multi-factor authentication (MFA) requiring a second verification factor beyond a password applies across both populations and is a baseline expectation the exam treats as non-negotiable for privileged access, especially root user and administrative IAM identities. Identity provider (IdP) integration -- federating IAM Identity Center or Cognito with an external directory (Active Directory, Okta, a SAML or OIDC provider) -- is the pattern the exam expects for any organization with existing corporate identity infrastructure, avoiding a second, parallel set of credentials that has to be manually kept in sync with the authoritative source.
Temporary Credentials Over Long-Lived Ones
A recurring theme across this entire domain: temporary, automatically expiring credentials are strongly preferred over long-lived static ones. AWS STS (Security Token Service) issues short-term credentials for a role, used whenever a human or a service needs to assume a role rather than embed a permanent access key -- this is the mechanism underneath IAM Identity Center federation, cross-account role assumption, and instance profiles alike. Amazon S3 presigned URLs extend the same temporary-access principle to object-level access: a presigned URL grants time-limited access to a specific S3 object to someone (or something) that doesn't have -- and shouldn't need -- an AWS identity at all, expiring automatically after a configured window rather than requiring the access to be manually revoked later.
Key Mechanics
- IAM Identity Center provides centralized SSO for human workforce identity across an AWS Organization, typically federated from an external IdP.
- Amazon Cognito handles identity for an application's own end users, via user pools (sign-up/sign-in) and identity pools (temporary AWS credentials for authenticated app users).
- MFA is a non-negotiable baseline expectation on this exam, especially for root and privileged IAM identities.
- IdP integration federates AWS identity solutions with an organization's existing directory, avoiding a second, manually synced credential set.
- AWS STS issues short-term credentials for role assumption -- the underlying mechanism for federation, cross-account roles, and instance profiles.
- S3 presigned URLs grant time-limited, automatically expiring access to a specific object without requiring the requester to hold an AWS identity.
Exam Tip: A scenario about workforce employees signing into multiple AWS accounts from one place points to IAM Identity Center; a scenario about an application's own customers signing up and signing in points to Cognito -- don't confuse the two populations.
Exam Tip: "Grants time-limited access to a specific object to someone without an AWS identity" is the textbook description of an S3 presigned URL -- distinguish it from a bucket policy, which grants access to identities, not anonymous time-limited links.
Exam Tip: Whenever a scenario's proposed design uses a long-lived IAM access key where a role and STS-issued temporary credentials would work instead, that design is almost always the wrong answer on this exam.
Worked example: A company wants its 200 employees to sign into any of its 15 AWS accounts using their existing corporate Active Directory credentials, while a separate customer-facing mobile app needs its own 50,000 end users to sign up and sign in independently, with the app then calling AWS APIs on the authenticated user's behalf. They federate IAM Identity Center with Active Directory for the employee population (giving SSO across all 15 accounts from one login) and use Amazon Cognito user pools for the mobile app's customers, with a Cognito identity pool issuing each authenticated user short-term AWS credentials scoped narrowly to what the app needs -- keeping the two very different identity populations, and their very different trust boundaries, cleanly separated.