IAM, Policies, MFA, and Least Privilege Review

Learning outcomes

By the end of this lesson, the learner can:

1. Explain what IAM is and what problem it solves.
2. Distinguish between IAM users, groups, and roles.
3. Explain what an IAM policy is at a high level.
4. Explain why MFA matters for both the root user and other identities.
5. Explain least privilege and why it is a core AWS security habit. AWS's IAM best-practices docs explicitly recommend protecting the root user, using MFA, and applying least-privilege permissions. (AWS Documentation)

---

What this review covers

This lesson is about who can do what in your AWS environment.

A simple summary is:

• IAM controls access.
• Policies define permissions.
• MFA adds a second layer of sign-in protection.
• Least privilege means granting only the permissions required for the task. AWS's IAM docs describe policies as the way permissions are granted, recommend MFA as a best practice, and define least privilege as granting only the permissions required to perform a task. (AWS Documentation)

A simple memory rule:

• Identity = who is acting
• Policy = what they can do
• MFA = extra sign-in protection
• Least privilege = as little access as needed, not as much as possible. (AWS Documentation)

---

1) What IAM is

IAM stands for AWS Identity and Access Management. At a high level, IAM is the AWS service used to control access to AWS resources by deciding which identities can sign in and what actions they are allowed to perform. AWS's policy docs describe policies as attaching to IAM identities such as users, groups, and roles to grant permissions. (AWS Documentation)

Key takeaway:

• IAM is the main "access control" layer in AWS.

• It answers questions like:

  • Who can sign in?
  • What can they access?
  • What actions are allowed?

---

2) Identities: users, groups, and roles

At this course level, the most important identity types to recognize are:

A) IAM user

An IAM user is an identity for a specific person or workload. Policies can be attached directly to IAM users. AWS's policy docs explicitly list users as IAM entities that can receive attached policies. (AWS Documentation)

Mental model:

• IAM user = one named identity

B) IAM group

A group is a way to organize IAM users so they can receive permissions together. AWS's policy docs explicitly refer to groups of users as IAM identities that can receive permissions. (AWS Documentation)

Mental model:

• group = shared permissions for multiple users

C) IAM role

A role is an identity that can have permissions and be assumed when needed. AWS's MFA docs explicitly mention attaching policies to IAM roles and using policy conditions around MFA for roles. (AWS Documentation)

Mental model:

• role = temporary access identity with permissions

Key takeaway:

• user = individual identity
• group = permission-sharing helper for users
• role = assumable identity for temporary or delegated access

---

3) What a policy is

AWS says an IAM policy is a JSON document that uses IAM policy grammar, and when you attach it to an IAM entity such as a user, group, or role, it grants permissions to that entity. (AWS Documentation)

That means a policy is not the identity itself. It is the permission document attached to the identity.

A high-level mental model:

• identity = person or workload
• policy = permission rules

Policies are expressed in JSON, and AWS automatically validates policy syntax in the console. AWS also says IAM Access Analyzer can provide additional policy checks and recommendations. (AWS Documentation)

---

4) What policies usually describe

At a high level, a policy usually describes:

• actions that are allowed
• resources those actions apply to
• sometimes conditions that narrow access further

AWS's policy-and-permissions docs describe least privilege as defining the actions that can be taken on specific resources under specific conditions. (AWS Documentation)

Key takeaway:

• a good policy is specific
• a weak policy is often too broad

---

5) MFA

AWS says MFA is an additional security layer that requires users to provide additional authentication factors after username and password, and that it significantly enhances security. AWS supports MFA for the root user, IAM users, IAM Identity Center users, Builder ID, and federated users. (AWS Documentation)

AWS also recommends phishing-resistant MFA such as passkeys and security keys whenever possible, because these FIDO-based authenticators are resistant to phishing, man-in-the-middle, and replay attacks. (AWS Documentation)

Key takeaway:

• password alone is not enough
• MFA makes stolen-password attacks much harder

---

6) Root user and MFA

AWS's root-user best-practices page says:

• use the root user only for tasks that require it
• create an administrative user for everyday tasks instead of using root all the time
• secure the root user with MFA
• do not share root credentials broadly. (AWS Documentation)

AWS also states that root users must have MFA configured, and current docs say users must register MFA for the root user within 35 days of the first console sign-in attempt if it is not already enabled. (AWS Documentation)

Key takeaway:

• root is not your daily account
• root should be heavily protected
• MFA on root is essential

---

7) Least privilege

AWS says least privilege means granting only the permissions required to perform a task. AWS also recommends starting with a minimum set of permissions and granting additional permissions only as necessary. (AWS Documentation)

This is one of the most important security ideas in AWS.

Bad pattern:

• give very broad access "just to make it work"

Better pattern:

• grant only the actions needed
• grant them only on the resources needed
• refine further with conditions when possible. AWS's IAM docs describe least privilege in exactly those action/resource/condition terms. (AWS Documentation)

High-level takeaway:

• least privilege reduces risk
• it also limits damage if credentials are misused

---

8) Broad permissions vs least privilege

AWS says you can use managed policies or wildcard * permissions to get started, but warns that these do not grant least-privilege permissions and can create security risk by granting more permissions than needed. AWS recommends monitoring and then refining toward least privilege. (AWS Documentation)

So a practical high-level workflow is:

1. start with the smallest set you understand
2. test what is missing
3. add only what is necessary
4. validate and refine

AWS also recommends using IAM Access Analyzer to validate policies and review warnings, errors, and suggestions. (AWS Documentation)

---

9) Policy validation

AWS says policies are validated automatically in the console for JSON syntax and grammar, and IAM Access Analyzer can provide additional checks and recommendations. AWS also notes that validation can verify action names, ARN formats, and condition keys. (AWS Documentation)

High-level takeaway:

• a policy can be syntactically valid but still too broad
• validation helps with correctness
• least privilege still requires judgment

---

10) Root user vs admin user

AWS's root-user best-practices page explicitly recommends creating an administrative user for everyday tasks instead of accessing the root user routinely. (AWS Documentation)

This is a very important review point:

• root user = highest-privilege account owner identity
• admin user = high-privilege working identity for day-to-day management
• regular users or roles = narrower permissions for normal tasks

High-level takeaway:

• do not build the habit of living in root
• use root rarely and intentionally

---

Quick comparison table

CSV version:

Concept,Mental model
IAM,Access control for AWS
IAM user,One named identity
IAM group,Shared permissions for multiple users
IAM role,Assumable identity with permissions
Policy,JSON permission document
MFA,Extra sign-in protection
Least privilege,Only the permissions needed

This table is based on the AWS IAM policy, MFA, and best-practices docs. (AWS Documentation)

---

Micro-activity 1

---

Micro-activity 2

---

Summary

IAM is AWS's access-control layer. Policies are JSON documents that grant permissions to IAM identities, MFA adds stronger sign-in protection, and least privilege means granting only the permissions required for a task. AWS's best-practice docs explicitly recommend protecting the root user, enabling MFA, and applying least-privilege permissions. (AWS Documentation)

The key habits to remember are:

• do not use the root user for daily work
• enable MFA
• treat policies as permission documents, not identities
• keep permissions as narrow as practical
• validate and refine policies over time. AWS's policy-validation and best-practices docs support exactly that workflow. (AWS Documentation)

The simplest memory rule is:

• IAM = who can access
• policy = what they can do
• MFA = stronger sign-in
• least privilege = only what is needed

---

Quiz 5.5

Reflection questions

---

Answer key

A1: B. IAM is AWS's access-control layer. Policies, users, groups, and roles are all part of controlling access. (AWS Documentation)

A2: B. AWS says an IAM policy is a JSON document that grants permissions when attached to an IAM entity. (AWS Documentation)

A3: A. AWS says MFA adds an additional authentication factor after username and password. (AWS Documentation)

A4: Because AWS recommends using the root user only for tasks that require it and creating an administrative user for everyday tasks instead. (AWS Documentation)

A5: B. AWS defines least privilege as granting only the permissions required to perform a task. (AWS Documentation)

A6: Because broad wildcard permissions grant more access than needed, which increases risk if the identity is misused or compromised. AWS explicitly warns that wildcard and broad managed policies are not least privilege. (AWS Documentation)

A7: B. AWS strongly recommends MFA for the root user, and current IAM docs state root MFA enrollment is required within the current policy window. (AWS Documentation)

A8: An IAM user is a named identity, while an IAM role is an assumable identity with permissions. AWS policy docs discuss attaching permissions to users, groups, and roles. (AWS Documentation)

A9: They are violating least privilege. AWS says permissions should include only what is required for the task. (AWS Documentation)

A10: IAM = who can access. Policy = what they can do. MFA = stronger sign-in. Least privilege = only what is needed.

Next lesson

Lesson 5.6: Root User, IAM Users, IAM Roles, and Access Patterns Review