Course Content
The IAM Foundation – The Basics
0/4
AWS IAM – The Guardian of Your Cloud Castle
Why IAM Forms Your First and Last Defense Line
IAM Building Blocks – Users, Groups, Roles, and Policies
Mini Quiz: Test Your Castle Knowledge
The Pillars of Identity – Roles & Responsibilities
Welcome back to your IAM journey. In Chapter 1, you learned the foundation—what IAM is and why it matters. Now we're stepping inside the castle walls to meet the residents, guilds, and guests who keep your AWS environment running. This chapter answers a critical question: who gets access, and how? Think of it as assigning keys in your castle. Some people live there permanently. Others belong to specific departments. And some just need a temporary pass to deliver supplies. Let's explore each.
0/4
AWS IAM Users Explained – Permanent Cloud Residents
AWS IAM Groups – Simplify Access with RBAC Control
AWS IAM Roles – Temporary Access for Services & Automation
Mini Quiz: Test Your Identity Wisdom
IAM Policies – The Castle Rulebook – The Rules
In Chapter 2, you built the foundation of your AWS castle by understanding identities: users, groups, and roles. You learned who lives in your castle and what roles they play. But here's the truth — identities without policies are like samurai without a code to follow. They exist, but they have no power, no direction, no permissions. Policies are the written laws of your castle. They're the rulebook that every gate guard consults before allowing someone to open a door, read a scroll, or access the treasury. When an IAM user tries to launch an EC2 instance or read from an S3 bucket, AWS doesn't guess. It reads the policies attached to that identity and makes a precise decision: allow or deny. This chapter teaches you how to read, write, and understand IAM policies. You'll learn how AWS evaluates permissions, how to choose between different policy types, and how to craft rules that follow the principle of least privilege. Think of this as learning to write the laws that govern your entire cloud kingdom.
0/4
AWS IAM Policy Basics — The Rulebook That Governs Access
AWS Managed vs Inline IAM Policies — Choosing the Right Rulebook
AWS IAM Policy Evaluation — How Permissions Are Decided
Mini Quiz – Test Your Rulebook Mastery
AWS IAM Mastery: Learn Identity & Access Management the Smart Way

Learning Objectives

  • Understand what AWS IAM users represent and when to create them
  • Learn how to authenticate users securely with MFA
  • Recognize why the root user should stay locked away

The Permanent Residents

Imagine your castle has permanent residents—people who live and work there every day. They each have their own key to the main gate. That’s an IAM user.

An IAM user represents a person or application that needs long-term access to AWS. Each user gets a unique identity with credentials—either a password for console access or access keys for CLI and API calls.

Here’s the thing: unlike a medieval castle where one master key opens everything, AWS lets you give each resident only the keys they need. A scribe doesn’t need access to the armory. A knight doesn’t need access to the treasury.

Creating Your First Resident

Let’s create an IAM user using the AWS CLI:

bash

aws iam create-user --user-name alice-developer

aws iam create-login-profile \
  --user-name alice-developer \
  --password TempPassword123! \
  --password-reset-required

Alice now exists in your AWS account. But she can’t do anything yet—she has no permissions. We’ll fix that when we talk about policies in Chapter 3.

The Root User: Your Master Key

Every AWS account starts with a root user—the account owner with unlimited access. This is your castle’s master key, and it should stay in a locked vault.

Why? If someone steals the master key, they control everything. The root user can delete your entire infrastructure, rack up massive bills, or lock you out of your own account.

Best practice: Use the root user only for initial setup, then lock it away. Enable MFA on it. Never use it for daily work. Create IAM users instead—even for yourself.

Multi-Factor Authentication (MFA)

Think of MFA as a two-key system. One key is your password. The other is a temporary code from your phone or hardware token. Even if someone steals your password, they can’t get in without the second key.

Enable MFA for all users who access the console:

bash

aws iam enable-mfa-device \
  --user-name alice-developer \
  --serial-number arn:aws:iam::123456789012:mfa/alice \
  --authentication-code1 123456 \
  --authentication-code2 789012

In DevOps, we automate everything—but humans still log in to troubleshoot, configure, and approve changes. Protect those human accounts like you’d protect the castle throne room.

Reflection: Do you currently use the root user for daily tasks? If yes, what’s your plan to stop?

Previous
Next