IAM Fundamentals: Users, Groups, Roles

Why This Level Matters

Every AWS security question on the SAA-C03 exam ultimately touches Identity and Access Management (IAM). Before you can secure EC2 instances, S3 buckets, or databases (coming later), you must understand who is allowed to act on AWS and how that identity is granted. This level builds the vocabulary and mental model the exam expects: users, groups, and roles.

Think of IAM as the front desk and badge system of a secure office building (AWS). Nobody gets past the lobby without a badge (credentials), and the badge determines which floors (services) and rooms (resources) they can enter.

1. IAM Users: Permanent Employees

An IAM user represents a specific person or application that needs long-term, direct access to your AWS account.

• Each IAM user has a unique name within the account.
• A user can have:
  • A password (for AWS Management Console sign-in)
  • Access keys (an Access Key ID + Secret Access Key, for programmatic access via CLI/SDK/API)
• These credentials are long-term: they exist until you rotate or delete them.
• Example: "Maria" is a database administrator. She gets an IAM user named maria-dba with a console password so she can log in and check RDS metrics.

Analogy: An IAM user is like a permanent employee badge — issued once, valid indefinitely (until revoked), tied to one specific person.

Root User Reminder (from L1 context)

The root user is the account owner, created when you sign up for AWS. It is NOT an IAM user — it has unrestricted access and should almost never be used for daily tasks. Best practice: lock it away with MFA, use IAM users/roles instead.

2. IAM Groups: Departments, Not Employees

A group is a collection of IAM users. Groups exist purely for organizing permissions, not for holding credentials themselves.

Key facts the exam expects you to know:

• A group has no credentials of its own — you cannot "log in as a group."
• A group cannot be nested inside another group (no groups-within-groups).
• A user can belong to multiple groups simultaneously.
• Permissions attached to a group apply to every user inside it.

Worked Example:

Imagine a company with 20 developers who all need identical access to a set of S3 buckets and CloudWatch logs.

1. Without groups: You would manually attach the same permission policy to 20 individual IAM users. If policy changes, you edit 20 users.
2. With groups: You create a group called Developers, attach the policy once to the group, and add all 20 users to it.
3. Result: One policy change updates access for everyone instantly. New hire joins? Add them to Developers — done in seconds.

This is the core exam insight: groups exist to simplify permission management at scale, not to grant identity.

Common Misconception

Students often think a group is itself "a type of user" that can be assumed like a role. It cannot. A group is only a container of permission assignments for users.

3. IAM Roles: Temporary Costumes, Not Badges

A role is an identity that can be assumed temporarily by a trusted entity — a person, an AWS service, or an application — to get a specific set of permissions for a limited time.

Critical distinctions from users:

• Roles do not have long-term credentials (no password, no permanent access keys).
• When something "assumes" a role, AWS Security Token Service (STS) issues temporary security credentials that automatically expire (commonly after 15 minutes to a few hours, configurable).
• Roles are defined by two components:
  1. Trust policy — who/what is allowed to assume the role (the "trusted entity")
  2. Permissions policy — what the role is allowed to do once assumed

Analogy: A role is like a visitor's temporary access card at a secure building. A contractor shows ID at the front desk, is issued a temporary card valid for the day, and it stops working automatically when they leave. No one needs to remember to "take the badge back."

Common Use Cases for Roles (exam favorites)

• EC2 instance needing to read from S3: Instead of storing access keys on the instance (a major security risk), attach an IAM role to the EC2 instance. The instance automatically receives temporary credentials via the instance metadata service.
• Cross-account access: A user in Account A assumes a role in Account B to perform work there, without needing a separate IAM user in Account B.
• Federated access: Users authenticate with an external identity provider (e.g., corporate Active Directory, or "login with Google") and are mapped to a role, receiving temporary AWS credentials — no IAM user created at all.
• AWS Lambda execution: A Lambda function assumes an execution role to access other services (previewed here; deep dive comes later in the course).

4. Roles vs. Long-Term Credentials: The Decision Rule

This is one of the most heavily tested distinctions on SAA-C03. Use this decision rule:

Golden Rule the exam tests repeatedly:

Never hardcode long-term IAM user access keys onto an EC2 instance, Lambda function, or any AWS resource. Always use a role instead.

Why this matters: access keys stored on a resource can leak (e.g., committed to a public GitHub repo, or exposed in a compromised container). Temporary role credentials expire automatically, dramatically limiting the damage of exposure.

Edge Case to Watch For

The exam sometimes describes a scenario where a company has "thousands of employees needing occasional AWS access through their existing corporate login." A naive answer is "create IAM users for all of them." The expert answer is federation with IAM roles — mapping external identities to a role via SAML 2.0 or an identity provider, avoiding IAM user sprawl entirely.

5. Putting It Together: A Mini Scenario

A company, "Cloudify Inc.," sets up their AWS account:

1. They create IAM users for 5 named engineers: alex, priya, jun, sam, noor.
2. They create a group Engineering and attach an S3-read/write policy to it.
3. They add all 5 users to the Engineering group — instantly, all 5 have S3 access.
4. They launch an EC2 instance that needs to write logs to S3. Instead of giving it one engineer's access keys, they create an IAM role EC2-S3-Writer with a trust policy allowing EC2 to assume it, and attach the role directly to the instance.
5. A partner company needs temporary read access to one S3 bucket. Cloudify creates a role with a trust policy allowing the partner's AWS account to assume it — no IAM user created for the partner.

Notice the pattern: users for people, groups to organize those people's permissions, roles for machines, temporary access, or cross-boundary trust.

6. Terminology Checklist for the Exam

Memorize these terms — SAA-C03 questions use this exact language:

• Principal: the entity (user, role, or service) making a request to AWS.
• Trusted entity: who is allowed to assume a role (defined in the trust policy).
• Temporary security credentials: short-lived access issued by STS when a role is assumed.
• Federation: granting access to users authenticated outside AWS by mapping them to a role.
• Long-term credentials: passwords and access keys tied to an IAM user.

Key Takeaways

• IAM users = individual identities with long-term credentials (password/access keys); best for named humans.
• IAM groups = containers of users for applying permissions in bulk; they have no credentials and cannot be nested.
• IAM roles = identities assumed temporarily via STS-issued credentials; ideal for AWS services, cross-account access, and federation.
• Roles are defined by a trust policy (who can assume it) and a permissions policy (what it can do).
• Golden rule: never place long-term IAM user credentials on AWS resources (EC2, Lambda) — always use roles.
• The exam frequently tests recognizing when a scenario calls for federation/roles instead of creating new IAM users.