Security and Compliance
IAM, Root User, and Least Privilege
CoreLearn how AWS authenticates identities, authorizes actions, protects root credentials, manages workforce access, and avoids unnecessary long-lived credentials.
Aligned to the current CLF-C02 exam guide, verified August 15, 2026.
Why this matters
Access management is foundational to every AWS workload. CLF-C02 tests safe identity choices and the differences among IAM constructs, federation, root access, and secret storage.
Must Know
- Do not use the root user for everyday tasks. Protect it with a strong unique password, MFA, no routine access keys, and tightly controlled recovery information.
- IAM policies define allowed or denied actions. AWS managed policies are maintained by AWS; customer managed policies let customers define reusable permissions.
- Groups make it easier to assign the same permissions to multiple IAM users. Roles are assumable identities that provide temporary credentials.
- Least privilege should replace broad administrator or wildcard access whenever a narrower permission set meets the need.
- IAM Identity Center is the preferred workforce access service for centrally assigning access across multiple AWS accounts.
- Secrets Manager is purpose-built for secrets such as database passwords and API keys and supports managed rotation for supported secrets; AWS Systems Manager Parameter Store holds configuration values and SecureString parameters.
- An account password policy sets requirements for IAM user console passwords, such as minimum length and character types. Access keys are long-term credentials for an IAM user; avoid creating them when temporary role credentials or federation can meet the need.
- Activating IAM access to the Billing and Cost Management console is one root-user-only task; use root only for that task, then secure the credentials again.
Compare and Distinguish
- Authentication vs authorization: MFA and federation help establish identity; policies determine what the authenticated identity can do.
- Root user vs administrative IAM identity: root has unrestricted account ownership powers; an administrative identity is still governed by IAM and should handle delegated administration.
- IAM user vs IAM role: a user can have long-term credentials; a role is assumed and supplies temporary credentials.
- IAM group vs IAM role: a group collects IAM users for permission assignment; a role is an identity that a trusted principal assumes.
- IAM vs IAM Identity Center: IAM provides identities, roles, and policies within the access model; Identity Center centralizes workforce access across accounts and applications.
- Secrets Manager vs Systems Manager Parameter Store vs IAM role vs AWS KMS: purpose-built secret storage with rotation capabilities; configuration values and SecureString parameters; temporary AWS credentials and authorization; and encryption-key management.
Scenario examples
- Scenario: Employees need one portal for access to assigned roles in several AWS accounts. Think: Use AWS IAM Identity Center for centralized workforce access.
- Scenario: An application on AWS needs access to another AWS service without a stored access key. Think: Assign a least-privileged IAM role that supplies temporary credentials.
- Scenario: A development team embeds a database password in source code. Think: Move the password to AWS Secrets Manager and authorize retrieval through IAM.
- Scenario: An administrator needs to perform a routine IAM task. Think: Use an appropriately authorized IAM or federated identity, not the account root user.
- Scenario: A vendor needs temporary, scoped access to resources in another AWS account. Think: Use a cross-account IAM role with a limited policy.
Exam traps
- An IAM role is not a group, and adding a user to a group is not federation.
- MFA strengthens authentication but does not grant or narrow authorization by itself.
- A password policy for IAM users does not protect embedded application secrets or replace MFA for the root user.
- Administrator access is not the default expression of least privilege merely because a user is an administrator.
- Do not use Secrets Manager as a place to create workforce identities, and do not use IAM Identity Center as an application password vault.
Key takeaways
- Authenticate the identity, then authorize only what it needs.
- Prefer roles and temporary credentials to long-lived access keys.
- Use IAM Identity Center for centralized workforce access across accounts.
- Protect root credentials and reserve root for root-only tasks.
- Use Secrets Manager for secret values, not for AWS identity authorization.
How it works
- An identity signs in directly or federates, and AWS evaluates applicable policies for the requested action.
- A role establishes trust for who may assume it and carries permission policies defining what the resulting session may do.
- Identity Center applies workforce assignments and permission sets across accounts, while IAM roles implement access in those accounts.
- Applications retrieve authorized secrets from Secrets Manager rather than storing the values in code or images.
When to use it
- Use IAM policies, users, groups, and roles to control access to AWS resources.
- Use IAM Identity Center for centralized employee access to multiple accounts and supported applications.
- Use a cross-account role when a trusted principal in one account needs scoped temporary access in another.
- Use Secrets Manager when an application must securely retrieve and possibly rotate a password, token, or API key.
- Use the root user only for a current documented root-only task.
Security and governance implications
- Require MFA for the root user and other privileged human access, and avoid root access keys.
- Remove unused credentials and permissions, and prefer short-lived role sessions.
- Separate secret administration from secret use and log access to sensitive resources.
- Periodically refine policies toward least privilege based on actual job and workload requirements.
Operational context
- Authentication failure and authorization denial are different scenario clues; broader permissions do not fix failed authentication.
- Unexpected access can originate in identity assignments, group membership, role trust, or policies; it does not justify granting broader access.
- An exposed long-lived credential is a security incident; the durable design lesson is to prefer temporary credentials where possible.
More detail
- A principal requests an action, authentication establishes the principal, and authorization evaluates policies and other controls. This sequence explains why strong sign-in protection and least-privileged permissions are both necessary.
- Federation lets users sign in through an existing identity system and receive temporary AWS access. Identity Center can coordinate these workforce assignments across accounts.
- Managed policies improve reuse. Customer managed policies support organization-specific reusable permissions. Inline policies have a direct one-to-one relationship with an identity and are usually a more specialized choice.
- Root-only tasks change over time and are intentionally rare. The durable exam principle is to use root only when current AWS documentation requires it and to protect the credentials before and after use.
Ready for the quiz?
- What is the difference between an IAM group and an IAM role?
- Why is a cross-account role safer than sharing an IAM user access key?
- Which safeguards should protect the account root user?
- When should a company choose IAM Identity Center?
- How do Secrets Manager and IAM solve different problems?
Related objectives
- D2.3 — Identify AWS access management capabilities.