Root User, IAM Users, IAM Roles, and Access Patterns Review

Learning outcomes

By the end of this lesson, the learner can:

1. Explain the difference between the AWS account root user, IAM users, and IAM roles.
2. Explain why AWS recommends temporary credentials when possible.
3. Recognize when IAM users are still used.
4. Explain common access patterns for humans, workloads on AWS, and workloads outside AWS.
5. Connect root-user protection, MFA, and least privilege into one security practice. AWS's IAM docs recommend protecting the root user, preferring temporary credentials, and using IAM roles where possible. (AWS Documentation)

---

What this review covers

This lesson is about choosing the right kind of identity for the job.

A simple summary is:

• Root user = the account owner identity with full access, used rarely.
• IAM user = a named identity with long-term credentials, used only for specific cases.
• IAM role = an assumable identity with permissions and temporary credentials.

AWS explicitly recommends avoiding routine use of the root user, recommends temporary credentials where possible, and says roles do not have standard long-term credentials such as passwords or access keys. (AWS Documentation)

A simple memory rule:

• root = emergency/highest privilege
• user = named identity with long-term credentials
• role = temporary access identity (AWS Documentation)

---

1) Root user

AWS says that when you first create an AWS account, you begin with a default set of credentials with complete access to all AWS resources in the account. This identity is called the AWS account root user. AWS strongly recommends that you do not use the root user unless you have a task that specifically requires root credentials. (AWS Documentation)

AWS also recommends:

• securing root credentials carefully
• enabling MFA on the root user
• not creating root access keys
• not sharing root credentials broadly
• using an administrative identity for normal work instead of root. (AWS Documentation)

Key takeaway:

• root is not your daily account
• root is your break-glass / account-owner identity (AWS Documentation)

---

2) IAM user

AWS says an IAM user is an entity you create in your AWS account, and that it represents the human user or workload that uses the IAM user to interact with AWS resources. AWS also says an IAM user consists of a name and credentials. (AWS Documentation)

But AWS's current IAM guidance is important here: AWS recommends that human users use federation with an identity provider and temporary credentials instead of IAM users with long-term credentials, and recommends using IAM users only for specific use cases not supported by federated users. (AWS Documentation)

Key takeaway:

• IAM users are real and still exist
• but they are not AWS's preferred default for most human access patterns anymore (AWS Documentation)

---

3) IAM role

AWS says an IAM role is an IAM identity you can create in your account that has specific permissions, but unlike a user, it is intended to be assumable by anyone who needs it. AWS also says a role does not have standard long-term credentials such as a password or access keys. Instead, assuming a role gives you temporary security credentials for that role session. (AWS Documentation)

Roles can be assumed by:

• IAM users
• other IAM roles
• AWS service principals such as EC2 or Lambda
• other trusted entities, depending on configuration. (AWS Documentation)

Key takeaway:

• a role is the cleaner modern pattern
• it gives permission without making long-term credentials the center of the design (AWS Documentation)

---

4) Why AWS prefers temporary credentials

AWS's IAM best-practices page explicitly says to require workloads to use temporary credentials with IAM roles to access AWS whenever possible. AWS also recommends relying on temporary credentials instead of creating long-term credentials such as access keys where possible. (AWS Documentation)

Why this matters:

• temporary credentials expire
• they reduce long-term credential exposure
• they fit better with modern AWS access patterns
• they are easier to rotate implicitly because new sessions get new credentials. AWS also documents that role sessions can be revoked if needed. (AWS Documentation)

Key takeaway:

• temporary credentials are safer than long-term credentials in many cases (AWS Documentation)

---

5) When IAM users are still used

AWS says IAM users are still appropriate for some specific cases that do not work well with role-based or federated access. Examples AWS gives include:

• workloads that cannot use IAM roles
• third-party AWS clients or vendors that do not support more modern access patterns
• AWS CodeCommit access with SSH keys or service-specific credentials in some cases. (AWS Documentation)

AWS also notes on the IAM best-practices page that some use cases still require long-term credentials, but the preference remains to avoid them where possible. (AWS Documentation)

Key takeaway:

• IAM users are now more of a special-case tool
• not the ideal default for every person or workload (AWS Documentation)

---

6) Best access pattern for humans

AWS's root-user guidance says:

• for a single standalone AWS account, use IAM roles to create identities in your account with specific permissions
• for multiple AWS accounts managed through AWS Organizations, use IAM Identity Center workforce users for centralized access management. (AWS Documentation)

So the clean guidance is:

• root user only for root-required tasks
• normal human access should not revolve around daily root use
• modern AWS guidance prefers federated or role-based access with temporary credentials over long-term IAM-user credentials. (AWS Documentation)

---

7) Best access pattern for workloads running on AWS

AWS says when you are building on AWS compute services such as Amazon EC2 or AWS Lambda, AWS can deliver the temporary credentials of an IAM role to that compute resource, and AWS SDKs can discover and use those credentials automatically. (AWS Documentation)

That means:

• EC2 instances should usually use an attached role
• Lambda functions should usually use an execution role
• on-AWS workloads generally should not need hard-coded long-term access keys if roles can be used. (AWS Documentation)

Key takeaway:

• AWS workload on AWS compute usually points toward role-based temporary credentials (AWS Documentation)

---

8) Best access pattern for workloads outside AWS

AWS's best-practices page says outside-AWS workloads can still use temporary credentials, but you need a way to deliver them. AWS gives examples including:

• IAM Roles Anywhere with X.509 certificates
• AssumeRoleWithSAML
• AssumeRoleWithWebIdentity
• AWS IoT Core in some IoT cases. (AWS Documentation)

Key takeaway:

• being outside AWS does not automatically mean you must use permanent access keys forever
• temporary credentials are still possible in many external scenarios (AWS Documentation)

---

9) Root user vs IAM admin user

AWS makes a clear distinction between the root user and an IAM user with administrator permissions. The IAM users page explicitly says an IAM user with administrator permissions is not the same thing as the AWS account root user. (AWS Documentation)

This is important because learners sometimes think:

• "My admin user is basically root"

But AWS treats them differently:

• root is the original account-owner identity with full account access
• an admin user is still an IAM identity governed within IAM. (AWS Documentation)

Key takeaway:

• admin user is powerful
• root user is still more fundamental and more sensitive (AWS Documentation)

---

10) MFA across these identities

AWS recommends MFA broadly, and its IAM docs say MFA significantly enhances security. AWS supports MFA for the root user, IAM users, IAM Identity Center users, Builder ID, and federated users. AWS also recommends phishing-resistant MFA such as passkeys and security keys whenever possible. (AWS Documentation)

Key takeaway:

• root should have MFA
• IAM users should have MFA if they exist
• strong sign-in protection is part of the correct access pattern, not an optional afterthought (AWS Documentation)

---

Quick comparison table

CSV version:

Identity type,Mental model
Root user,Account-owner identity with full access used rarely
IAM user,Named identity with long-term credentials
IAM group,Shared permissions for multiple IAM users
IAM role,Assumable identity with temporary credentials

This table reflects AWS's root-user, IAM user, and IAM role documentation. (AWS Documentation)

---

Micro-activity 1

---

Micro-activity 2

---

Summary

AWS's current IAM guidance strongly favors temporary credentials and role-based access where possible. The root user should be used only for tasks that require it, IAM users should be used only for specific cases, and IAM roles are the preferred pattern for many human and workload access cases because they provide temporary credentials instead of long-term ones. (AWS Documentation)

The biggest habits to remember are:

• protect root heavily and do not use it daily
• prefer roles and temporary credentials where possible
• understand that IAM users are now more of a special-case identity pattern
• use MFA and least privilege together with the right identity type. (AWS Documentation)

The simplest memory rule is:

• root = rare
• user = named long-term identity
• role = temporary access pattern (AWS Documentation)

---

Quiz 5.6

Reflection questions

---

Answer key

A1: B. AWS says the root user is the default account-owner identity with complete access to the account. (AWS Documentation)

A2: C. AWS says IAM users are named identities with credentials, but recommends using them only for specific use cases not supported by more modern access patterns. (AWS Documentation)

A3: C. AWS says roles are assumable identities that provide temporary security credentials and do not have standard long-term credentials. (AWS Documentation)

A4: Because AWS strongly recommends using the root user only for tasks that require it and protecting it heavily with MFA and other safeguards. (AWS Documentation)

A5: C. AWS recommends temporary credentials through IAM roles for workloads on AWS compute services where possible. (AWS Documentation)

A6: An IAM user is a named identity with long-term credentials, while an IAM role is an assumable identity that provides temporary credentials when used. (AWS Documentation)

A7: B. AWS explicitly says an IAM user with administrator permissions is not the same thing as the root user. (AWS Documentation)

A8: Examples include workloads that cannot use IAM roles, third-party AWS clients that do not support newer access patterns, or certain CodeCommit access cases. (AWS Documentation)

A9: An IAM role attached to the EC2 workload is the strongest first pattern, because AWS recommends role-based temporary credentials for workloads on AWS compute. (AWS Documentation)

A10: root = rare, user = named long-term identity, role = temporary access pattern. (AWS Documentation)

Next lesson

Lesson 5.7: Security Services Recognition Review