AWS Authentication Strategies: MFA, STS, and Federation

A Specialty-level MFA strategy distinguishes authenticator strength. FIDO2 security keys (hardware keys and passkeys) are phishing-resistant: the credential is origin-bound, so a lookalike sign-in page cannot replay it. Virtual TOTP authenticator apps are better than nothing but phishable — a proxied login page can capture and immediately use a six-digit code. For privileged human identities, the exam expects you to prefer FIDO2. AWS lets you register multiple MFA devices per user, so a hardware key plus a backup is the standard pattern for administrators.

Enforcement is a policy problem, not a checkbox. The canonical pattern is an explicit deny attached to identities (or applied as a guardrail) that blocks everything when MFA is absent:

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" }
  }
}

The operator choice is the exam trap. aws:MultiFactorAuthPresent is only present in the request context when the call is made with temporary credentials; requests signed with long-term access keys omit the key entirely. BoolIfExists treats a missing key as a match, so the deny also blocks long-term-key requests — which is exactly what you want, because an access key can never carry MFA context on its own. Using plain Bool would silently exempt access-key traffic. You typically carve out the handful of actions a user needs to bootstrap MFA (viewing their user, enabling a device) with a NotAction element in the same statement, and you can pair the deny with aws:MultiFactorAuthAge to force re-authentication for sensitive actions after a time window.

The root user bypasses all IAM policies in its own account, so its protection is procedural: enable MFA (ideally FIDO2), delete any root access keys, use a monitored group email address, and never use root for daily work. AWS reserves a short list of tasks that genuinely require root — closing the account, changing certain account settings, restoring access when an S3 bucket policy or SQS queue policy locks out every principal including administrators. Everything else belongs to IAM roles. At the organization level, SCPs are one of the few controls that do constrain member-account root users, which is why a deny-based SCP guardrail is the standard defense against root misuse in member accounts.

The SCS-C03 guide explicitly calls out centralized root access management. With this AWS Organizations feature, you remove root user credentials from member accounts entirely — no root password, no root MFA to manage per account — and the management account (or a delegated administrator) can perform the remaining root-only tasks through short-lived, task-scoped privileged root sessions, such as deleting a misconfigured bucket policy that has locked everyone out. This shrinks the attack surface dramatically: a credential that does not exist cannot be phished. The exam pairs this with break-glass procedures: a documented, tested path for emergency privileged access, with credentials sealed away, alarms on any use (a CloudWatch alarm on root sign-in events via CloudTrail is the classic detective control), and a post-use rotation step. When a scenario mentions dozens of member accounts and the operational pain of tracking root MFA devices, centralized root access management is the intended answer.

The strongest credential strategy is to have as few long-term credentials as possible. Every place an access key lives — a developer laptop, a CI runner, an EC2 user-data script — is a place it can leak, and a leaked key is valid until someone notices. The design answer is roles everywhere: humans federate through IAM Identity Center, applications use instance profiles, task roles, or OIDC federation, and on-premises workloads use IAM Roles Anywhere. Temporary credentials expire on their own; revocation is a property of the design rather than an incident-response scramble.

For the keys you cannot yet eliminate, the exam expects you to know the audit tooling by name. The IAM credential report is a downloadable, account-wide CSV listing every user with the age and status of their passwords, access keys, and MFA devices — the fastest way to answer "which users still have keys older than 90 days?". Access key last used data (visible in the console and via GetAccessKeyLastUsed) tells you whether a key is actually in use before you deactivate it. IAM access advisor (service last accessed data) shows which services a user or role actually called, which drives least-privilege pruning — but note that is an authorization concern that Task 4.2 picks up. Where rotation is unavoidable, follow the two-key dance: create the second key, deploy it, confirm the old key shows no recent use, deactivate it, observe, then delete. Deactivation is reversible; deletion is not — the exam rewards the sequence that never causes an outage.

AWS STS is the mint for temporary credentials, and the exam repeatedly tests which API fits which caller. The chooser:

Session mechanics matter as much as the chooser. AssumeRole sessions default to 1 hour and can extend to the role's configured maximum session duration, up to 12 hours — but role chaining (using an assumed role's credentials to assume another role) is capped at 1 hour regardless. GetSessionToken for an IAM user defaults to 12 hours and can reach 36; a root user is capped at 1 hour. A session policy passed at assume time can only intersect — never expand — the role's permissions, which makes it the tool for handing a broad role to a caller in a narrowed form. Session tags travel with the session and feed ABAC decisions via aws:PrincipalTag; a tag can be marked transitive so it survives role chaining.

A role has two policy halves: the permissions policy (what the session can do — Task 4.2) and the trust policy (who may become the role). The trust policy is a resource-based policy whose Principal names the trusted account, role, service, or federated provider, and whose Condition block is where authentication controls live: sts:ExternalId for third parties, aws:MultiFactorAuthPresent to require that the assuming identity carries MFA, source conditions for service principals.

Walk the classic scenario. A monitoring vendor operates from its own AWS account and needs read access to your account, and to hundreds of other customers' accounts. You create a role trusting the vendor's account. The danger is the confused deputy: a malicious customer of the same vendor, knowing or guessing your role's ARN, asks the vendor's platform to connect to your role. The vendor — a deputy acting with its own credentials, which your trust policy accepts — would succeed. The defense is an external ID. The vendor assigns you a unique opaque value, and your trust policy requires it:

"Condition": {
  "StringEquals": { "sts:ExternalId": "vendor-assigned-unique-id" }
}

The vendor's platform passes each customer's own external ID on every AssumeRole call and — critically — refuses to let customers choose or edit that value. The attacker can name your role ARN, but the vendor will attach the attacker's external ID, the StringEquals fails, and STS returns AccessDenied. The external ID is not a secret credential; it is a binding between the vendor's customer record and your role. When an exam stem says "a third party accesses your account on behalf of multiple customers," the answer is the external ID.

IAM Identity Center is AWS's recommended workforce answer, built for multi-account organizations. Its unit of authorization is the permission set — a template that Identity Center materializes as an IAM role in every account where a user or group is assigned. Assign one group a ReadOnly permission set across 40 accounts and Identity Center provisions and maintains 40 roles; users get a single access portal and short-lived credentials everywhere. Identity Center brings its own directory, or connects to an external IdP such as Entra ID or Okta over SAML 2.0 for authentication with SCIM for automated provisioning — SCIM keeps users and group memberships synchronized, so disabling a user at the IdP propagates without manual cleanup. That joiner-mover-leaver automation is a security control, not a convenience.

Direct SAML 2.0 federation to IAM predates Identity Center: you create a SAML identity provider entity in IAM, define roles trusting it, and users obtain credentials via AssumeRoleWithSAML. The IdP's assertion carries the role attribute mapping the user to one or more role/provider ARN pairs. Choose it when the question signals legacy constraints, a single account, or a broker that must call STS directly; otherwise Identity Center is the default answer for workforce access at scale.

OIDC federation covers non-human workforce adjacents such as CI. A GitHub Actions pipeline presents a short-lived OIDC token to AssumeRoleWithWebIdentity; the role trusts the OIDC provider and — at concept level — conditions on the token's aud (intended audience) and sub (repository and branch) claims so only the intended repo and branch can deploy. Scoping sub tightly is the difference between "this pipeline can deploy" and "anyone on GitHub can."

Amazon Cognito handles customer identity, and the exam expects you to keep its two halves straight. A user pool is a user directory and OIDC authorization server: it authenticates your app's end users (with password policies, MFA, and social or SAML sign-in) and issues three JWTs — an ID token (identity claims), an access token (authorizes calls to your APIs), and a refresh token. A user pool alone grants no AWS access. An identity pool exchanges a token from a user pool or other provider for temporary AWS credentials, mapping authenticated (and optionally guest) identities to IAM roles. At mention level: the enhanced flow (GetCredentialsForIdentity) is the default and lets Cognito resolve the role server-side; the basic flow has the client call AssumeRoleWithWebIdentity itself with a role it names — more flexible, larger attack surface, disabled by default.

Compute workloads never store keys: EC2 uses instance profiles (credentials delivered and rotated via the metadata service — require IMDSv2), ECS tasks use task roles scoped per task definition, and EKS pods use IRSA, which is OIDC federation under the hood — covered in the compute domain, so a brief cross-reference suffices here. IAM Roles Anywhere extends the same model to on-premises servers: you register a certificate authority as a trust anchor, the workload authenticates with an X.509 client certificate, and a credential helper exchanges the certificate for temporary role credentials. Finally, S3 presigned URLs delegate authentication itself: the URL embeds a signature from the creator's credentials, so anyone holding it acts as the signer until expiry — and it never outlives the signing credentials, a subtlety the exam likes when the signer was a short-lived role session.

Work AssumeRole AccessDenied as a two-sided problem, because both sides must independently allow. Side one: does the caller's identity-based policy allow sts:AssumeRole on the target role's ARN (and does no SCP or boundary deny it)? Side two: does the target role's trust policy name this caller — or its account — as a Principal, and are all trust conditions met? The condition failures are the exam's favorites: the vendor passed no ExternalId or the wrong one; the trust policy requires aws:MultiFactorAuthPresent but the caller's session was minted without MFA (fix: GetSessionToken with an MFA code, then assume); a sts:SourceIdentity or session-tag condition the caller did not set. CloudTrail is your evidence: the AssumeRole event records the caller, the role, and the error, and failed trust evaluation surfaces as AccessDenied — not as a missing event.

Federation failures cluster into three groups. Assertion and mapping problems: the SAML assertion's role attribute maps to no role ARN, the audience or issuer does not match the IAM identity provider, or an attribute your trust policy conditions on is absent. Clock skew, at mention level: SAML assertions and OIDC tokens carry validity windows, and a drifted IdP clock yields inexplicable "expired" rejections. Duration conflicts: requesting a DurationSeconds (or SAML SessionDuration) beyond the role's maximum session duration fails — align the IdP's requested duration with the role's configured cap. Separately, InvalidClientTokenId means the credentials themselves are not recognized: a deactivated or deleted access key, or an STS token presented in a Region whose STS endpoint is deactivated for that account. ExpiredToken means exactly that — the session outlived its duration; re-authenticate rather than retry.