Lesson 14

IAM Fundamentals

Users, Groups, Roles, and Policies — the core building blocks of AWS identity and access control

What is AWS IAM?

AWS Identity and Access Management (IAM) enables you to manage access to AWS services and resources securely. Using IAM, you control who can access what resources, what they can do with them, and how they can access them.

Centralized access control: One tool to manage launching, configuring, and terminating resources.
Granular permissions: Specify exactly which API calls a user is authorized to make per service.
No additional charge: IAM is a feature of your AWS account offered at no extra cost.
Global scope: IAM settings apply across all AWS Regions — not regional.

Exam Note: IAM is a global service. Unlike EC2 (Regional) or S3 (Regional bucket location), IAM configurations like users, groups, roles, and policies are not tied to a specific Region. This is a common exam differentiator.

The Four Core IAM Components

Component	Definition	Key Characteristics
IAM User	A person or application that authenticates with an AWS account	Unique name per account, unique credentials (not shared). Defined in exactly one AWS account. Default: no permissions.
IAM Group	A collection of IAM users granted identical authorization	Cannot be nested. No default group. A user can belong to multiple groups. Groups simplify permission management for teams.
IAM Policy	A JSON document that defines permissions	Specifies Effect (Allow/Deny), Action (API calls), Resource (ARNs). Can be attached to users, groups, or roles. Explicit deny always wins.
IAM Role	An identity with permissions, intended to be assumed by anyone who needs it	Provides temporary security credentials. Not associated with one person. Used for EC2-to-S3 access, cross-account access, federation.

Authentication: Proving Your Identity

When you create an IAM user, you select the type of access they are permitted to use.

Access Type	Used For	Credentials Required
Programmatic access	AWS CLI, AWS SDK, APIs	Access key ID + Secret access key
Console access	AWS Management Console (browser)	12-digit Account ID (or alias) + IAM username + password (+ MFA token if enabled)

You can assign programmatic access only, console access only, or both.

Authorization: What is Permitted

After authentication, authorization determines what the user can do. IAM uses JSON policy documents evaluated according to this logic:

Check for explicit deny: If any policy explicitly denies the action → Request is denied.
Check for explicit allow: If no explicit deny, and a policy explicitly allows → Request is allowed.
Implicit deny: If neither an explicit deny nor an explicit allow exists → Request is denied (default).

Key rule: All permissions are implicitly denied by default. An explicit deny always overrides an explicit allow. The most restrictive policy wins.

Policy Types

Identity-Based Policies

Attached to an IAM user, group, or role. These control what actions that identity can perform.

Managed policies: Standalone policies attachable to multiple entities. AWS provides pre-built managed policies; you can also create customer-managed policies.
Inline policies: Embedded directly into a single user, group, or role. Not reusable on other entities.

Resource-Based Policies

Attached to a resource (such as an S3 bucket). These control what actions a specified principal can perform on that resource. Resource-based policies are always inline — defined directly on the resource, not as a separate standalone document. S3 bucket policies and S3 ACLs are examples.

Policy Evaluation Order

The order of policy evaluation has no effect on the outcome. All policies are evaluated, and the result is always allowed or denied. When conflicting policies exist, the most restrictive outcome applies.

IAM Groups: Key Rules

A user can belong to multiple groups (e.g., both "Developers" and "Testers").
Groups cannot be nested — a group can contain only users, not other groups.
There is no default group that includes all users — you must create and manage group membership explicitly.
If a user changes roles, remove them from old groups and add them to new ones — no need to edit individual policies.

IAM Roles: Delegating Access

An IAM role is similar to a user: it has policies attached that define permissions. But unlike a user, a role:

Is not uniquely associated with one person — it is intended to be assumed.
Has no long-term credentials (no password, no permanent access keys).
Provides temporary security credentials when assumed — these auto-rotate and expire.

Common Role Scenarios

Scenario	How the Role Works
EC2 to S3 access	Attach a role to the EC2 instance with a trust policy allowing EC2 to assume it. The app uses temporary credentials — no keys stored on the instance.
Cross-account access	A role in Account A trusts Account B. Users in B assume the role to access resources in A.
Federation	Users authenticated by an external identity provider (corporate directory) assume an IAM role for AWS access.
Mobile apps	Instead of embedding AWS keys in the app (security risk), the app assumes a role via Amazon Cognito to get temporary credentials.

Best practice: Use IAM roles instead of long-term access keys whenever possible. Roles eliminate the risk of exposed permanent credentials and remove the burden of key rotation.

The Principle of Least Privilege

Grant only the minimal user privileges needed, based on what the user actually needs to perform their tasks. Then grant additional permissions only as necessary. This is safer than starting with broad permissions and trying to tighten later.

Trusted tools

IAM Policy Simulator: Test and troubleshoot IAM and resource-based policies to verify whether access will be granted before deploying.

Primary Source: AWS Academy Module 4: AWS Cloud Security (module-4.txt) — Section 2: AWS Identity and Access Management (IAM).