AWS Access Management (IAM, IAM Identity Center)

AWS access management is the collection of AWS services, constructs, and practices that decide who can sign in to your AWS account, what they can do once signed in, and how their identity is proven. The flagship service is AWS Identity and Access Management (AWS IAM), which lets you create users, groups, roles, and IAM policies that implement the principle of least privilege. For organizations with many employees and multiple AWS accounts, AWS IAM Identity Center (formerly AWS SSO) centralizes workforce access. Together, AWS IAM and IAM Identity Center form the authentication and authorization layer for every API call on AWS.

On the CLF-C02 exam, Task Statement 2.3 ("Identify AWS access management capabilities") expects you to recognize IAM users vs IAM roles, apply least privilege with IAM policies, configure MFA, protect the root user, and know when to reach for IAM Identity Center instead of raw AWS IAM. This guide walks through every construct in plain language, highlights the most common traps, and gives you memorable analogies so the vocabulary sticks.

What is AWS Access Management (AWS IAM)?

AWS access management is the AWS-native framework that controls access to AWS resources across any AWS service. It is delivered primarily through AWS IAM, a global, free-of-charge AWS service that handles authentication (are you who you say you are?) and authorization (are you allowed to do this API call?). AWS IAM stores identities (IAM users, IAM roles), groupings (IAM groups), and permission documents (IAM policies) and then evaluates every request against those documents in real time.

Every request to an AWS API — whether through the AWS Management Console, AWS CLI, AWS SDKs, or the AWS Management Console mobile app — is routed through AWS IAM before AWS will execute it. If AWS IAM cannot identify the caller, or if the caller's IAM policy does not grant the required permission, the request is denied. That is why AWS access management sits at the heart of the AWS Shared Responsibility Model: identity and access management is always the customer's job, no matter how managed the underlying service is.

Why AWS access management matters for CLF-C02

The CLF-C02 Security and Compliance domain carries 30% exam weight, and AWS access management (IAM, IAM Identity Center) is the single most-mentioned sub-topic inside it. Candidates consistently get tripped up on three questions: "when do I use an IAM role vs an IAM user?", "what must I do with the root user right after account creation?", and "which AWS service issues credentials for federated workforce access?". Answer those three confidently and you will already be ahead of most CLF-C02 test takers on AWS access management questions.

Plain-Language Explanation: AWS Access Management

Theory is easier when it maps to something physical. Here are three distinct analogies that cover every major AWS access management concept on CLF-C02.

Analogy 1: The Office Building with Access Cards

Picture a big corporate office. An IAM user is like an employee badge with the employee's photo on it — it belongs to one specific person, has a long-lasting PIN, and opens the doors that person is allowed through. An IAM group is like a team door code — you configure "Engineering can open rooms 3, 4, 5" once, and every engineer's badge inherits that permission. An IAM role is like a temporary visitor lanyard kept at the front desk: anyone (or any AWS service) can check one out by asking the security guard (AWS STS, the AWS Security Token Service), wear it for the duration of their visit, and hand it back. Nobody permanently carries a role. The root user is the building owner who holds the master key — they can re-key every lock, but because a lost master key would be catastrophic, you keep it in a vault (AWS root credentials locked away, MFA enabled) and only use it for truly one-of-a-kind tasks.

MFA (multi-factor authentication) is the second turnstile after the badge reader — even with a stolen badge, you can't get in without also tapping a hardware token, authenticator app, or passkey. IAM policies are the written rules taped on every door ("badge must have Engineering tag, time must be 08:00-20:00"). IAM Identity Center is the corporate lobby reception where a visitor signs in once and is then escorted to the 12 different buildings (AWS accounts) they are authorized to enter, without badging in 12 times.

Analogy 2: The Open-Book Exam Rules

Think of taking an open-book certification exam with strict rules. The proctor is AWS IAM — they check your ID (authentication) and then look at the rulebook (authorization) for what you can and can't do. The rulebook is your IAM policy. Least privilege means the rulebook should say "you may use these three reference books" not "you may use every book in the library" — the smaller the allowed surface, the less damage if your seat is compromised. An explicit deny in an IAM policy is like the proctor's big red "DO NOT" sign — no matter what other permissions say, a deny wins. That is the core of AWS IAM policy evaluation logic: default deny, union of allows, and an explicit deny trumps any allow.

Analogy 3: The Hotel Front Desk and Room Keys

A hotel captures AWS access management perfectly. The root user is the hotel owner — they have a universal override key and are the only person who can shut down the hotel, change the name on the lease, or close the bank account. The front desk clerk is AWS IAM — they issue room keys (IAM users, IAM roles) with specific access (room 305 only, pool only, gym only). A keycard that expires at checkout is an IAM role — it gives temporary access and automatically deactivates, so a forgotten keycard isn't a long-term risk. MFA is the signature you leave at check-in plus the photo ID they scanned — two factors that prove you are really the person on the reservation. IAM Identity Center is the hotel chain loyalty program — one profile, one sign-in, and you can check into any of the brand's 200 properties (AWS accounts) without creating a new account each time.

Core Operating Principles — Identity, Authentication, and Authorization

Every AWS IAM decision follows the same three-step pipeline: identify, authenticate, authorize. Master this and every AWS access management question becomes easier to parse.

Identification: who is making the request?

When a request arrives at AWS, AWS IAM extracts the principal — the IAM user, IAM role, AWS service, or federated identity making the call. The principal is embedded in the request signature (for AWS CLI and SDK calls) or inferred from the active AWS Management Console session. Without a valid principal, there is nothing to evaluate and the request is rejected immediately.

Authentication: is the principal really them?

Authentication proves the principal holds valid credentials. For AWS IAM users, this means a username and password (AWS Management Console) or an access key ID and secret access key (AWS CLI, SDK). For IAM roles, the caller presents temporary credentials (access key ID, secret access key, and session token) previously issued by AWS Security Token Service (AWS STS). Multi-factor authentication (MFA) layers a second factor — typically a time-based one-time password from a virtual MFA device, a FIDO2 hardware key, or a passkey — on top.

Authorization: is the principal allowed to do this?

Authorization is IAM policy evaluation. AWS IAM collects every applicable IAM policy — identity-based policies attached to the principal, resource-based policies attached to the target resource, permissions boundaries, AWS Organizations service control policies (SCPs), and session policies — and runs them through a defined algorithm. The outcome is always one of two words: Allow or Deny.

IAM Building Blocks: Users, Groups, Roles, and Policies

AWS IAM has four primitives that every CLF-C02 question is built from. Knowing what each one is — and, more importantly, what each one is not — is the single biggest lever on your AWS access management score.

IAM users

An IAM user represents a single identity in one AWS account, typically a human being or a long-running external application. An IAM user gets a unique name, can have a console password, and can have up to two active access keys (so you can rotate without downtime). Because IAM user credentials are long-term by design, they are the highest-risk construct in AWS access management and should be used sparingly. AWS best practice is to prefer IAM roles and IAM Identity Center over new IAM users wherever possible.

IAM groups

An IAM group is a container that bundles IAM users together so you can attach IAM policies once and have them apply to every member. A user can belong to multiple IAM groups. Groups are not an identity — you cannot "sign in as a group" or embed credentials into a group — they exist purely to make IAM policy management scalable.

IAM roles

An IAM role is an identity with IAM policies attached, but no long-term credentials. Instead, a principal (an AWS service, an AWS account, a federated user, an IAM user in another AWS account) assumes the role and receives temporary security credentials from AWS STS. Those temporary credentials expire (default 1 hour, configurable up to 12 hours for many workflows) and leave no persistent secret behind. IAM roles are the correct AWS IAM construct for:

• Granting an Amazon EC2 instance access to Amazon S3 (an EC2 instance profile) without embedding access keys in the AMI.
• Letting an AWS Lambda function write to Amazon DynamoDB without hardcoded credentials.
• Cross-account access where a user in Account A needs occasional access to resources in Account B.
• Identity federation from a corporate identity provider (SAML 2.0, OIDC, web identity providers like Google, Facebook, or Amazon Cognito).

IAM policies (managed vs inline)

An IAM policy is a JSON document that lists allowed or denied AWS API actions on specific resources, optionally filtered by conditions. There are two delivery formats:

• Managed policies are standalone IAM policy objects you create once and attach to many identities. AWS-managed policies are pre-built and maintained by AWS (for example, AmazonS3ReadOnlyAccess). Customer-managed policies are the ones you author and version.
• Inline policies are embedded directly in a single IAM user, IAM group, or IAM role and live and die with it. Use inline IAM policies when you want a strict 1:1 tie between the identity and the permissions, and use managed IAM policies everywhere else for reusability.

IAM Users vs IAM Roles — Key Distinctions and When to Use Each

This is the most-tested distinction on CLF-C02 AWS access management questions. Get it wrong and you will miss questions across the whole Security domain.

What IAM users are for

An IAM user is appropriate when you need a persistent identity with long-term credentials. Typical examples: a small team of humans signing in to the AWS Management Console in the earliest stage of an AWS account, a third-party monitoring tool that does not support role assumption, or a legacy on-premises script. Every IAM user adds long-term credential management overhead: rotation, offboarding, MFA enrollment.

What IAM roles are for

An IAM role is appropriate whenever the caller does not need to carry credentials around for weeks or months. The biggest CLF-C02 scenarios are:

• EC2 service-access: attach an IAM role to the Amazon EC2 instance via an instance profile; the Amazon EC2 instance metadata service exposes rotating short-term credentials to the application. No secrets in user-data, no secrets in source control.
• Cross-account access: a user or service in AWS account A assumes an IAM role in AWS account B via sts:AssumeRole, gets short-term credentials, performs the work, and has nothing left to clean up afterward.
• Federation: a SAML 2.0 identity provider (like Active Directory Federation Services) or a web identity provider (like Amazon Cognito user pools) issues an assertion; AWS IAM trusts the assertion and returns short-term credentials tied to a chosen IAM role.

Side-by-side comparison

Principle of Least Privilege — Managed Policies vs Inline Policies

Least privilege is the foundational AWS access management principle: grant each IAM user, IAM group, or IAM role only the permissions required to do the task, for the shortest time needed. This is the single most emphasized best practice in the AWS IAM User Guide and it shows up again and again in CLF-C02 scenario questions.

Starting narrow

Begin every IAM policy with a minimal set of API actions and specific resource ARNs. Do not start from "Action": "*" and "peel back" — that approach usually ships with far more permissions than the workload actually needs. Use AWS-managed policies as a baseline if they closely match the job function, but prefer a customer-managed IAM policy tuned to the real actions your workload performs.

IAM Access Analyzer

AWS IAM Access Analyzer is a feature inside AWS IAM that helps you reach least privilege automatically. It has two big capabilities on CLF-C02:

• External access analysis — continuously scans resource-based IAM policies (Amazon S3 bucket policies, IAM role trust policies, AWS KMS key policies, and more) and flags any that grant access to principals outside your trust boundary.
• Unused access analysis and policy generation — inspects AWS CloudTrail activity over a lookback window and generates a refined IAM policy that grants only what the identity actually used.

Permissions boundaries and session policies

Two advanced IAM policy types can further tighten least privilege:

• A permissions boundary is an advanced feature that sets the maximum permissions an identity-based IAM policy can grant to an IAM user or IAM role. The boundary doesn't grant permissions itself — it only caps what other IAM policies can grant.
• A session policy is passed when a role is assumed via AWS STS; it narrows the effective permissions of that specific session without modifying the underlying IAM role.

Both constructs exist to stop accidental over-permissioning, and both show up occasionally on CLF-C02 as distractor options.

Root Account Security — What Only Root Can Do and How to Protect It

The root user is the email-address-based account owner created when you first open an AWS account. It has unconditional, unrestricted access to every resource and every billing setting in that AWS account. That power is also why the root user is the single biggest risk on the account.

What only the root user can do

A handful of tasks can only be done by the root user and cannot be delegated to any IAM user or IAM role, no matter how permissive the IAM policy:

• Change the AWS account's email address or root password.
• Change the AWS account name.
• Close the AWS account.
• Change or cancel AWS Support plans.
• Restore IAM user permissions if every administrator IAM user is locked out (account recovery).
• Register as a seller in AWS Marketplace.
• Configure some AWS billing and tax information.

How to protect the root user

AWS IAM best practices around the root user are short, specific, and very testable:

1. Use the root user only to complete the one-time setup, then immediately create an IAM user (or better, an IAM Identity Center user) with administrator permissions for day-to-day administration.
2. Enable MFA on the root user. CLF-C02 often phrases this as "what is the first thing to do after creating a new AWS account?" — the answer is "activate MFA on the root user".
3. Delete or disable root access keys. If a root access key exists, rotate or remove it; programmatic use of the root user is strongly discouraged.
4. Use a strong, unique password for the root user and physically lock the credentials away.
5. Avoid sharing the root user under any circumstance; if multiple people need admin access, give each their own identity with an admin IAM policy.

Authentication Methods: MFA, Access Keys, Password Policies

AWS IAM supports several authentication factors, and CLF-C02 tests that you can distinguish them.

Console password + password policy

Every IAM user can optionally have a console password. A per-account IAM password policy enforces minimum length, character classes, rotation windows, reuse prevention, and whether users can change their own passwords. Password policies apply to all IAM users in the AWS account but do not apply to the root user (the root user simply has its own strong password requirements).

Access keys

Access keys are the long-term credentials (access key ID + secret access key) used by AWS CLI, AWS SDKs, and AWS PowerShell. Each IAM user can have up to two active access keys so that a new key can be provisioned before an old one is deleted, enabling zero-downtime rotation. For non-human workloads, AWS strongly recommends replacing access keys with IAM roles (EC2 instance profile, Lambda execution role, ECS task role) to avoid long-term secrets entirely.

MFA — virtual, hardware, and passkeys

Multi-factor authentication adds a second factor on top of the password. AWS IAM supports three flavors:

• Virtual MFA device — an authenticator app on a phone (Google Authenticator, Authy, 1Password, etc.) that produces a rotating 6-digit time-based one-time password (TOTP). Cheapest and most common.
• Hardware MFA device — a physical key fob (AWS sells Gemalto/SafeNet devices) or a FIDO2 security key (such as a YubiKey). More robust than virtual MFA because the secret cannot be copied off a hardware device.
• Passkey / FIDO authenticator — AWS supports passkeys built into iOS, Android, macOS, Windows Hello, and hardware security keys. Passkeys are phishing-resistant and the preferred modern factor for both IAM users and the root user.

IAM Identity Center (SSO) — Federated Access and Cross-Account Management

AWS IAM Identity Center (formerly AWS Single Sign-On, still sometimes called AWS SSO) is the AWS access management service for workforce identity — the humans in your organization who need to sign in to one or many AWS accounts. It is the recommended way to manage human access in AWS in 2026.

What IAM Identity Center does

• Provides a single sign-on portal. Users log in once with a corporate identity, and see tiles for every AWS account and SaaS application they are entitled to.
• Federates with your existing corporate identity provider via SAML 2.0 or OIDC — common integrations include Microsoft Entra ID (formerly Azure AD), Okta, Ping Identity, Google Workspace, and on-premises Active Directory via AWS Directory Service.
• Optionally runs as its own identity store (built-in directory) for organizations that don't have an existing IdP.
• Manages permission sets that are applied to AWS accounts inside an AWS Organizations structure — users are mapped to permission sets, and IAM Identity Center materializes the necessary IAM roles in each target AWS account automatically.
• Issues short-term credentials for AWS CLI v2 sessions, so engineers never store long-term access keys on their laptops.

When to choose IAM Identity Center vs raw AWS IAM

Identity Federation — SAML 2.0, Web Identity, and Cognito

Identity federation lets you grant AWS access to users who already have identities elsewhere, without creating IAM users for each of them.

SAML 2.0 federation

When your workforce already lives in a SAML 2.0 identity provider (Microsoft Entra ID, Active Directory Federation Services, Okta, Ping), you can either:

• Use IAM Identity Center (simplest; IAM Identity Center brokers the SAML relationship for every AWS account), or
• Configure a SAML 2.0 identity provider inside AWS IAM and map the SAML assertion to IAM roles that trust that provider.

Either way, the end result is the same: users sign in at the corporate IdP, get a SAML assertion, exchange it through AWS STS, and receive short-term credentials.

Web identity federation and Amazon Cognito

For customer-facing mobile and web applications that need to call AWS APIs (for example, an app that uploads user photos to Amazon S3), Amazon Cognito user pools and identity pools are the preferred integration. Cognito handles sign-in with Google, Apple, Facebook, Amazon, or any OIDC-compliant provider, and exchanges the social-login token for short-term AWS credentials tied to an IAM role.

Direct web identity federation (OIDC-to-IAM) is still supported but Amazon Cognito wraps it in a higher-level AWS service that handles user directories, MFA, user migration, and attribute mapping.

No persistent credentials with federation

Both SAML and web identity federation leave no long-term AWS credentials on the user's device or in the IdP — the user gets temporary STS credentials that expire on their own. This is a core AWS security win and a common CLF-C02 scenario ("which approach avoids long-term AWS credentials?" → identity federation with IAM roles).

AWS IAM is GLOBAL, Not Region-Scoped

AWS IAM is a global AWS service. IAM users, IAM groups, IAM roles, and IAM policies are created once per AWS account and are available in every AWS region immediately. You do not pick a region when you create an IAM user, and you do not re-create IAM users in every region where you deploy workloads. The same is true of IAM Identity Center's directory and permission sets for the workforce portal, although the IAM Identity Center instance itself is provisioned in one home region.

AWS IAM vs AWS Organizations — Account-Level vs Multi-Account Control

AWS access management questions on CLF-C02 sometimes mix AWS IAM with AWS Organizations and its service control policies (SCPs). They are complementary, not competing.

• AWS IAM controls what an identity inside a single AWS account can do.
• AWS Organizations controls what an entire AWS account (or organizational unit) is allowed to do, across every identity inside it.
• Service control policies (SCPs) are AWS Organizations guardrails — they set the maximum permissions any IAM policy in a member account can grant. SCPs never grant permissions by themselves; they only restrict.
• AWS IAM Identity Center sits on top of AWS Organizations and assigns workforce identities to permission sets across member AWS accounts.

Credential Storage: AWS Secrets Manager and AWS Systems Manager Parameter Store

AWS access management isn't only about who signs in — it also covers how your applications store credentials for databases, APIs, and third-party services. Two AWS services are tested at CLF-C02 awareness level:

• AWS Secrets Manager — a dedicated secrets storage AWS service with built-in automatic rotation (especially strong for Amazon RDS, Amazon Redshift, Amazon DocumentDB). Pay-per-secret pricing. Use when rotation, cross-account sharing, or fine-grained access is important.
• AWS Systems Manager Parameter Store — a free tier of plain and encrypted configuration parameters with versioning. Good for general configuration and lightweight secret storage when you don't need rotation.

Both AWS services integrate with AWS IAM policies so that only specified IAM users, IAM roles, and IAM Identity Center permission sets can read a given secret. This keeps database passwords and third-party API keys out of source control and out of Amazon EC2 user-data scripts.

Key Numbers and Must-Memorize Facts for AWS Access Management

Memorize this short list. It covers the majority of AWS IAM numeric and categorical traps on CLF-C02.

Common Exam Traps — AWS Access Management

Expect to see at least one of these on every CLF-C02 attempt. Learn to spot the pattern before reading the answer choices.

Trap 1: IAM roles vs IAM users

Answer choices that describe "an IAM user with temporary credentials" or "an IAM role with long-term access keys" are traps. IAM users = long-term credentials. IAM roles = short-term credentials issued by AWS STS. If the scenario involves an Amazon EC2 instance, AWS Lambda function, or cross-account access, the correct AWS access management construct is an IAM role.

Trap 2: Root user vs administrator IAM user

"Administrator" means "has an AdministratorAccess IAM policy attached". "Root user" means the original account owner. They are not the same person. Root has powers an administrator cannot have (close the AWS account, change the root email). Routine administration should happen with an IAM user or IAM Identity Center user, not with the root user.

Trap 3: AWS IAM vs IAM Identity Center

AWS IAM is the in-account identity service. IAM Identity Center is the multi-account workforce portal. Questions that mention "employees", "single sign-on", "multiple AWS accounts", or "SAML" usually want IAM Identity Center. Questions that mention "grant an Amazon EC2 instance access to Amazon S3" want an AWS IAM role.

Trap 4: AWS IAM is NOT region-scoped

Any answer choice that implies you create IAM users per region, replicate IAM policies across regions, or pick a region for AWS IAM is wrong. AWS IAM is global.

Trap 5: SCPs never grant; they only restrict

If an SCP exists that denies s3:DeleteBucket, no IAM policy in that member account can grant s3:DeleteBucket, no matter how permissive it is. But an SCP allowing s3:DeleteBucket doesn't by itself grant the permission — an IAM policy in the member account must also grant it.

Trap 6: MFA is for both root and IAM users

Some questions imply MFA is only for the root user. MFA should be enabled on the root user and on every IAM user with elevated privileges — especially IAM users with administrator-level IAM policies.

AWS Access Management vs AWS Security Governance — Scope Boundary

AWS access management (Task 2.3 — AWS IAM, IAM Identity Center) is about who signs in and what they can do. Security governance and compliance (Task 2.2 — AWS Config, AWS Organizations, AWS Control Tower, AWS Artifact) is about organizational guardrails, compliance attestations, and detective/preventive controls above the identity layer. They overlap at AWS Organizations (which hosts both SCPs used for access management restriction and guardrails used for governance) and at AWS IAM Access Analyzer (which straddles access management and governance). When a CLF-C02 question is about "who can do what", it is access management; when it's about "is the account configured compliantly", it is governance.

Practice Question Links — Task 2.3 Mapped Scenarios

• "Which AWS service grants an Amazon EC2 instance access to Amazon S3 without long-term credentials?" → IAM role (attached via instance profile).
• "What should a company do immediately after creating a new AWS account?" → Enable MFA on the root user and create an administrator IAM user or IAM Identity Center user for day-to-day admin.
• "How should a company with 15 AWS accounts manage workforce sign-in?" → IAM Identity Center federated with the corporate identity provider.
• "Which AWS service helps identify IAM policies granting more permissions than needed?" → AWS IAM Access Analyzer.
• "Which AWS IAM construct is best for temporary cross-account access?" → IAM role assumed via AWS STS.

FAQ — AWS Access Management Top Questions

Q1: What is the difference between AWS IAM and IAM Identity Center?

AWS IAM manages identities and IAM policies inside one AWS account — IAM users, IAM groups, IAM roles, IAM policies. AWS IAM Identity Center (formerly AWS SSO) sits on top of AWS Organizations and provides a single sign-on portal, SAML/OIDC federation, and permission sets that are mapped to IAM roles across many AWS accounts. In 2026, IAM Identity Center is the recommended default for workforce access across multi-account environments, while AWS IAM remains the low-level primitive AWS access management service for AWS services, applications, and cross-account roles.

Q2: When should I use an IAM user vs an IAM role?

Use an IAM role whenever possible because it issues short-term credentials and leaves no persistent secret behind. IAM roles are the right AWS IAM construct for Amazon EC2 service-access, AWS Lambda execution, cross-account access, and federation. Use an IAM user only for cases that truly need a long-term, persistent identity — for example, a third-party tool that cannot assume roles — and apply least privilege + MFA + access key rotation to contain the risk.

Q3: What must I do with the root user right after creating an AWS account?

Enable MFA on the root user immediately (virtual MFA device, hardware MFA device, or passkey), delete any root access keys, set a strong unique password, and create a separate administrator identity — ideally an IAM Identity Center user, or an IAM user with an AdministratorAccess IAM policy — for every subsequent admin task. Lock the root credentials away and only pull them out for root-only actions like closing the AWS account or changing the root email.

Q4: How does AWS implement the principle of least privilege?

Start from minimal IAM policies and only add permissions when a workload demonstrably needs them. Use AWS IAM Access Analyzer to find external access and generate refined IAM policies from AWS CloudTrail activity. Prefer managed IAM policies over inline for reusability, use permissions boundaries for IAM roles that create other IAM roles, and add AWS Organizations SCPs for top-level guardrails. On CLF-C02, "least privilege" and "IAM Access Analyzer" are strongly linked.

Q5: Is AWS IAM free? Is MFA free?

Yes, AWS IAM is a free AWS service — there is no charge for IAM users, IAM groups, IAM roles, or IAM policies. MFA is also free; you only pay if you purchase a physical hardware MFA token, and even then passkeys and virtual MFA apps are no cost. You are of course billed for the AWS resources those IAM policies grant access to (Amazon EC2, Amazon S3, etc.) but not for AWS IAM itself.

Q6: Can I restrict what the AWS root user can do with an IAM policy or an SCP?

No, you cannot meaningfully restrict the root user of an AWS account with an IAM policy, and SCPs at the AWS Organizations level do not apply to the management account's root user in the same way they do to member accounts. The only effective protection for the root user is not to use it — enable MFA, delete access keys, lock credentials away, and delegate day-to-day work to an IAM user, IAM role, or IAM Identity Center permission set.

Q7: What's the difference between SAML federation and Amazon Cognito?

SAML 2.0 federation is the workforce pattern — enterprise identity providers (Microsoft Entra ID, Active Directory Federation Services, Okta, Ping) issue SAML assertions that AWS IAM or IAM Identity Center trusts, and the user receives short-term credentials for an IAM role. Amazon Cognito is the customer-facing pattern — user pools manage sign-up and sign-in for end users of your application, and identity pools exchange the sign-in token for short-term AWS credentials tied to an IAM role. Workforce = SAML + IAM Identity Center; customers of your app = Amazon Cognito.

Further Reading

• AWS IAM User Guide — Introduction
• AWS IAM Security Best Practices
• AWS IAM Policy Evaluation Logic
• AWS IAM Identity Center User Guide
• AWS IAM Access Analyzer
• AWS IAM Roles
• Using MFA in AWS
• AWS CLF-C02 Exam Guide (PDF)