Domain 2 of 4 · Chapter 3 of 4

Access Management

IAM building blocks and the root user

Every request to AWS comes from a principal, and IAM allows it only when a policy attached to that principal permits the action: that one sentence is the engine behind every access question on the exam, from users and roles to secret storage. AWS Identity and Access Management (IAM) decides who can do what in an AWS account. It is free and global, so the identities you create are not tied to a single AWS Region.

The one model behind every IAM question: every request to AWS is made by a principal, the identity making the call (a user, an application, or an AWS service). A policy is a JSON document listing allowed (or denied) actions; it grants nothing until attached to an identity. On each request, IAM evaluates the policies attached to the calling principal and allows the action only if one permits it. The four building blocks below are the pieces of that model: who the principal can be, and how you attach permissions:

  • Users: a principal for one person or application needing long-term access, with a console password, programmatic access keys, or both.
  • Groups: a collection of users; a policy attached to the group is inherited by every user in it. You cannot nest groups, and a group is not itself a principal that can sign in or hold keys.
  • Roles: an identity whose permissions are assumed temporarily rather than signed into. A role has no password or long-term keys: a user, application, or AWS service assumes it and gets short-lived credentials from AWS Security Token Service (STS)[1] that rotate automatically. A role is not a user you log in as: you take on its permissions for a session, then drop them.
  • Policies: the JSON documents above. AWS managed policies are written by AWS for common use cases; customer managed policies are ones you create and reuse. AWS recommends starting from a managed policy and tightening toward least privilege.

When you create an AWS account you also get the root user, which signs in with the account's email address and has complete, unrestricted access to every service and resource. Because that power cannot be scoped down, AWS strongly recommends you do not use the root user for everyday tasks[2]. Treating root as a daily admin login is the classic mistake. Instead, create an administrative identity (an IAM user or, better, a user in IAM Identity Center) for daily work and lock the root user away. The exam rewards answers that protect the root user with multi-factor authentication (MFA) and remove its access keys.

A short list of root-only tasks can be performed only while signed in as the root user, including changing the account's email address or root password and closing the AWS account[2], restoring IAM permissions if an administrator locks themselves out, registering as a seller in the Reserved Instance Marketplace, and enabling MFA Delete on an Amazon S3 bucket. If a question describes one of these tasks, the root user is the correct (and only) answer.

Principal makes a request the identity calling AWS IAM user long-term identity Assumed IAM role temporary, via STS AWS service acting via a role Policy attached to the identity JSON allow / deny; grants nothing until attached group policy inherited IAM evaluates: allow? allowed only if a policy permits it Root user unrestricted; not governed by IAM
The IAM access model: a request comes from a principal (IAM user, assumed role, or AWS service); IAM allows it only if an attached policy permits. The root user sits outside this model, locked away.

Least privilege, MFA, and protecting credentials

This section covers the credential practices the exam tests most: how broadly to grant, how to add a second factor, and where application secrets live. Least privilege is the principle of granting a principal only the permissions it needs to do its job, and nothing more. If a credential is later leaked, least privilege limits the blast radius to just those few actions. On the exam, an answer that grants AdministratorAccess or full * permissions "to keep things simple" is almost always the wrong choice; the answer that scopes permissions to the specific task is correct.

The single most exam-relevant rule for credentials is prefer temporary credentials over long-lived ones, the trade-off behind roles above. For AWS workloads such as Amazon EC2 instances and AWS Lambda functions, AWS recommends attaching an IAM role[3] so the workload receives temporary credentials that rotate automatically; you should not embed an IAM user's access keys in the application. Long-term access keys remain valid for narrow cases (for example, a tool that cannot assume a role), and when you do use them you should rotate them on a schedule.

Multi-factor authentication (MFA) adds a second proof of identity on top of a password: something you have (an authenticator app, a hardware security key, or a passkey) in addition to something you know. AWS recommends enabling MFA for the root user and for any privileged IAM user[3]. You can also enforce a password policy for IAM users that sets minimum length, required character types, and expiration.

Application secrets (database passwords, API keys, OAuth tokens) should never be hard-coded in source. Two services hold them safely, and the diagram below shows the single question that separates them, whether you need automatic rotation:

  • AWS Secrets Manager encrypts secrets with AWS KMS and can rotate supported database credentials automatically[4], with built-in support for Amazon RDS, Amazon Redshift, and Amazon DocumentDB. Choose it when you need scheduled rotation.
  • AWS Systems Manager Parameter Store stores configuration data and secrets (as encrypted SecureString parameters) and offers a free tier for standard parameters[5]. Choose it for simple, low-cost secret and configuration storage when automatic rotation is not required.

Neither of these is an identity service: they store and serve secrets, while IAM governs the AWS-API permissions a principal holds.

Storing an application secret database password, API key, token Need scheduled rotation? automatic, on a schedule AWS Secrets Manager KMS-encrypted; auto-rotates supported DB credentials Yes Parameter Store encrypted SecureString; free tier, simple and low cost No
Choosing where an application secret lives: need automatic scheduled rotation, Secrets Manager; simple, low-cost storage without rotation, Parameter Store.

Roles, IAM Identity Center, and federation: which to pick

As an account or organization grows, the question shifts from "how do I make a user" to "which identity mechanism fits this access need." Four patterns (all built on the assume-a-role idea from the model above) cover almost every CLF-C02 question.

IAM role for AWS services and cross-account access. When an EC2 instance, Lambda function, or other AWS service needs to call AWS APIs, attach an IAM role[1]; it supplies temporary credentials with no stored keys. Roles also enable cross-account access: instead of creating a user in every account, you create a role in account B that trusts account A, and principals in A assume it, as the diagram below traces. This is the standard, exam-correct way to let one account's users operate in another.

IAM Identity Center for workforce sign-in across many accounts. AWS IAM Identity Center[6] (the successor to AWS Single Sign-On, renamed in 2022) gives employees one sign-in and one portal to reach all the AWS accounts and applications they are assigned. You define reusable permission sets (collections of policies) and assign a group to an account with a permission set; users then get temporary sessions in each account. The organization instance is deployed in the AWS Organizations management account. If a stem says "a company with many AWS accounts needs centralized employee access," Identity Center is the answer, not creating IAM users in every account.

Federated identity for reusing existing logins. Federation means letting users authenticate with an external identity provider (a corporate directory such as Microsoft Entra ID, or a SAML/OIDC provider) and then assume an AWS role, so no new AWS password is created and access is centrally managed in the existing directory. Identity federation[7] is what lets a workforce reuse the logins it already has. Identity Center itself can connect to such an external IdP, combining federation with multi-account permission sets.

Exam-pattern recognition. Watch for these distractors:

  • "Create an IAM user in each account for the employee": wrong when many accounts are involved; the answer is IAM Identity Center.
  • "Store the access keys in the application code / EC2 user data": wrong; attach an IAM role.
  • "Use the root user so the script always has access": wrong; root is for root-only tasks, never automation.
  • Confusing workforce access (employees reaching AWS: IAM / Identity Center / federation) with application end-user sign-up, which is a separate customer-identity concern and not what these services do.

The through-line is consistent: temporary, centrally managed, least-privilege credentials beat long-lived per-account users every time.

Account A Account B Principal in A user or role Role in B trust policy trusts A assumes Temporary credentials no IAM user in B operate in B with the role's permissions
Cross-account access: a principal in account A assumes a role in account B whose trust policy trusts A; STS issues temporary credentials in B, with no IAM user created there.

Choosing an identity or credential mechanism

AspectIAM userIAM roleIAM Identity CenterSecrets Manager
Primary purposeLong-term identity in one accountTemporary credentials assumed on demandWorkforce sign-in across many accountsStore and rotate application secrets
Credential lifetimeLong-lived password or access keysTemporary, auto-rotated via STSTemporary session via permission setSecret rotated on a schedule
Best forRare cases needing a fixed userEC2/Lambda and cross-account accessEmployees using multiple AWS accountsDB passwords, API keys in apps
Federation supportNo native federationAssumed by federated identitiesConnects to external IdP (SAML/SCIM)Not an identity service

Decision tree

Is an AWS service (EC2, Lambda) the thing that needs AWS access? Yes IAM role temporary, auto-rotated creds No Are you storing an application secret (password, API key)? Yes Secrets Manager / Parameter Store encrypted store; rotation in Secrets Mgr No Do employees need sign-in across many AWS accounts? Yes IAM Identity Center permission sets, one portal No Reuse an existing corporate or web login (IdP)? Yes Federated identity assume a role, no new AWS password No IAM user last resort; rotate keys
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

IAM is free and global

AWS Identity and Access Management (IAM) controls who is authenticated and authorized in an account, and it's a feature of your AWS account offered at no additional charge. You pay only for the other services your identities then use. It's global, not Regional, so a user, group, role, or policy you create works the same in every AWS Region rather than being scoped to one.

Trap Assuming an IAM user or policy must be re-created per Region or that IAM carries a separate charge. IAM is global and free, unlike most AWS services.

1 question tests this
Root user has unrestricted access

The account root user signs in with the email address used to create the account and has complete access to every AWS service and resource. That access is effectively unlimited, which is why AWS strongly recommends not using it for everyday work and instead creating a separate administrative identity.

1 question tests this
Protect root with MFA and remove its access keys

Securing the root user means enabling MFA on it, not creating (or deleting any existing) root access keys, and doing daily work from a separate administrative identity. AWS now mandates root MFA and requires it to be registered within 35 days of the first console sign-in; the exam rewards answers that lock the root user away rather than hand it programmatic keys.

Trap Creating root access keys so automation can run as the root user. Workloads should use an IAM role, and root should hold no access keys at all.

5 questions test this
Some tasks are root-only

A short list of actions can be performed only by signing in as the root user, including changing the account's root email or password, closing the AWS account, restoring access after an IAM administrator locks themselves out, registering as a Reserved Instance Marketplace seller, and enabling S3 MFA Delete. For everything else, use an IAM or Identity Center administrative identity.

Trap Assuming routine admin work such as creating users or editing IAM policies needs the root user. Those are everyday IAM tasks, not the narrow root-only list.

1 question tests this
Least privilege limits blast radius

Least privilege means granting only the permissions an identity needs for its task and nothing more, narrowing what a compromised or mistaken credential can touch. On the exam, an option that attaches full administrator or * permissions for convenience is almost always the wrong choice.

Trap Attaching AdministratorAccess or a wildcard * policy 'to keep things simple'. Convenience over least privilege is the classic distractor.

6 questions test this
Groups manage permissions for many users

An IAM user group is a collection of users that share the policies attached to the group, so adding a user to the group grants them its permissions in one step. Groups can't be nested (they hold only users, not other groups) and a group is not itself a principal you can authenticate or name in a policy's Principal.

Trap Treating a group as something you can sign in as or reference as a Principal in a resource policy. Groups relate to permissions, not authentication.

6 questions test this
Roles give temporary, auto-rotating credentials

An IAM role has no long-term password or access keys; when a principal assumes it, AWS STS issues short-lived credentials for that session that rotate automatically. Roles are the recommended way to grant access to AWS compute (Amazon EC2, AWS Lambda), to federated users, and across accounts.

Trap Picking an IAM user with long-term access keys to grant an EC2 instance or Lambda function permissions. A role with auto-rotating temporary credentials is the recommended choice.

17 questions test this
Use roles, not access keys, for workloads

For workloads on AWS compute such as Amazon EC2 or AWS Lambda, attach an IAM role rather than embedding an IAM user's access keys. AWS delivers and rotates the role's temporary credentials to the resource automatically, so there are no long-lived secrets to distribute or leak.

Trap Storing an IAM user's access keys on an EC2 instance or in a Lambda environment variable. Embedded long-term keys are exactly what an attached role removes.

9 questions test this
AWS managed vs customer managed policies

AWS managed policies are standalone policies written and updated by AWS for common use cases; customer managed policies are ones you create and tune for your specific needs. AWS advises starting from a managed policy (often by copying one) and tightening toward least privilege, since a broad managed policy rarely matches your exact requirement.

Trap Assuming you can edit an AWS managed policy to fit your needs. AWS owns and updates those, so you copy one into a customer managed policy to customize it.

19 questions test this
MFA adds a second authentication factor

Multi-factor authentication requires something you have (a passkey or FIDO security key, a virtual authenticator app, or a hardware TOTP token) in addition to the password, so a stolen password alone can't sign in. AWS recommends enabling MFA for the root user and all privileged IAM users, and now ends support for SMS-based MFA.

Trap Treating a strong or rotated password as multi-factor authentication. MFA requires a second, separate factor such as a security key or authenticator app, not just a better password.

4 questions test this
Password policies set credential rules

An IAM account password policy sets minimum length, required character types, expiration, and reuse rules for IAM user console passwords. It governs only IAM user passwords (not the root user password, not access keys, and not federated or role-based sign-in) and it can't enforce a lockout after failed attempts.

Trap Expecting the IAM password policy to govern the root user's password or lock accounts after failed logins. It applies only to IAM user passwords and has no failed-attempt lockout.

1 question tests this
Secrets Manager stores and rotates secrets

AWS Secrets Manager encrypts secrets with AWS KMS and can rotate them automatically on a schedule, with managed (no-Lambda) rotation for Amazon RDS, Amazon Aurora, Amazon Redshift, and Amazon DocumentDB credentials. Pick it over Parameter Store when you need built-in scheduled rotation of database or API credentials.

Trap Reaching for Systems Manager Parameter Store when the requirement is automatic credential rotation. Parameter Store stores secrets but does not rotate them.

6 questions test this
Parameter Store is the low-cost secret/config option

AWS Systems Manager Parameter Store holds configuration values and secrets, encrypting SecureString parameters with AWS KMS, and its standard tier carries no additional charge. Choose it for simple, low-cost storage when you don't need automatic rotation. AWS itself points you to Secrets Manager for rotating credentials.

Trap Choosing Parameter Store when the requirement calls for built-in automatic rotation. That scheduled rotation is Secrets Manager's job, not Parameter Store's.

3 questions test this
Never hard-code secrets in code

Database passwords, API keys, and tokens belong in AWS Secrets Manager or AWS Systems Manager Parameter Store, not in source code or config files where anyone who can read the app can extract them. The application fetches the secret at runtime, so credentials never live in the codebase.

Trap Treating an encrypted source file or a 'private' repository as a safe place to store credentials. Anyone who can read the app can extract embedded secrets, so they belong in Secrets Manager or Parameter Store.

1 question tests this
IAM Identity Center centralizes workforce access

AWS IAM Identity Center (renamed from AWS Single Sign-On in 2022) gives employees one sign-in and one portal to all the AWS accounts and applications they're assigned, and can connect to an existing identity provider. It's the answer for centralized workforce access across many accounts, instead of creating duplicate IAM users in each one.

Trap Creating duplicate IAM users in every account for centralized employee access. IAM Identity Center provides one sign-in across all accounts and is the intended answer.

3 questions test this
Permission sets assign multi-account access

In AWS IAM Identity Center you define a permission set (a reusable template of IAM policies) then assign a group to an account with it; Identity Center provisions a matching IAM role in that account and lets the users assume it. Sessions are temporary, defaulting to a one-hour AWS account session (up to 12 hours).

1 question tests this
Federation reuses existing logins

Identity federation lets users authenticate with an external identity provider (a corporate directory or a SAML 2.0 / OIDC provider) and then assume an IAM role for temporary AWS access. No new AWS password is created and access stays managed in the existing directory, so there are no long-term AWS credentials to distribute.

Trap Creating a matching IAM user for each employee already in the corporate directory. Federation lets them assume a role with their existing login instead of issuing new AWS credentials.

4 questions test this
Cross-account roles avoid duplicate users

To let one account's principals work in another account you own, create an IAM role in the target account whose trust policy names the source account, then grant those principals permission to call STS AssumeRole. This delegates access without creating and maintaining duplicate IAM users in every account.

Trap Creating a second IAM user with its own access keys in the other account for cross-account access. A role assumed via STS delegates access without duplicate users or long-term keys.

4 questions test this
Workforce identity is not application end-user identity

IAM and AWS IAM Identity Center govern your workforce's access to AWS accounts and resources. Signing in the end users of your own web or mobile app is a separate customer-identity concern handled by Amazon Cognito, not by these workforce services.

Trap Choosing IAM Identity Center to authenticate the customers of your public app. That's Amazon Cognito's job; Identity Center is for your workforce.

1 question tests this
FIDO security keys are the phishing-resistant MFA option

FIDO security keys are physical devices that use public-key cryptography for strong, phishing-resistant authentication that TOTP codes can't match. They need no batteries, and a single key can back multiple root and IAM users, which makes them AWS's recommended MFA type for highly privileged accounts.

Trap Picking an SMS text-message or TOTP authenticator code as the phishing-resistant MFA option. Only FIDO security keys use public-key cryptography that resists phishing.

6 questions test this
IAM policy types: identity-based, inline, trust, and service-linked

Identity-based policies are JSON documents attached to IAM users, groups, or roles to define what they can do. An inline policy is embedded in a single identity in a strict one-to-one relationship and is deleted with it; a managed policy is preferred when more than one identity needs it. A role's trust policy names which principals may assume the role, and a service-linked role is predefined and owned by an AWS service, so administrators can view but not edit its permissions.

4 questions test this

Also tested in

References

  1. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
  2. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html
  3. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
  4. https://aws.amazon.com/secrets-manager/faqs/
  5. https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html
  6. https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html
  7. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html