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 designed for secrets such as database passwords and API keys and supports managed rotation for supported secrets.
- Access keys are long-term credentials for an IAM user. Avoid creating them when temporary role credentials or federation can meet the need.
- A rare root-only task should be performed with the root user only for that task, then the credentials should be secured 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 IAM role: Secrets Manager stores secret values; a role supplies temporary AWS credentials and permissions.
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.
Troubleshooting signals
- For an access failure, distinguish failed authentication from an authorization denial before changing permissions.
- For unexpected access, inspect identity assignments, group membership, role trust, and applicable policies rather than immediately granting broader access.
- For an exposed long-lived credential, deactivate or rotate it promptly and replace the pattern with 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