Conceptual Foundations

IAM Building Blocks and Their Architectural Roles

Before writing a single policy statement, you need a clear mental model of what each IAM primitive does and why it exists. Getting this wrong causes the most common IAM mistake: attaching policies directly to users and then losing track of who has what.

An IAM user represents a long-term identity — typically a human operator or a legacy application that cannot use roles. Users carry permanent credentials (passwords, access keys) which is why their permissions must be tightly scoped. In modern AWS architectures, you minimise the number of users and prefer roles wherever possible.

An IAM group is not an identity — it cannot make API calls. It is purely an administrative container that lets you attach policies once and have them apply to all members. If you need to revoke access from a category of users, you modify the group policy rather than hunting down individual users. This is why you should never attach policies directly to users in a multi-person environment.

An IAM role is an identity without permanent credentials. It issues temporary security tokens (via STS) to whoever assumes it — an EC2 instance, a Lambda function, a CI/CD pipeline, or even another AWS account. The temporary nature of these credentials is a core security property: a leaked token expires, whereas a leaked access key persists until manually revoked.

An IAM policy is a JSON document that defines what actions are allowed or denied on which resources under what conditions. Policies are attached to users, groups, or roles. There are two types relevant here: AWS managed policies (maintained by AWS, broad, useful for prototyping) and customer managed policies (written by you, scoped precisely, what production systems use).

The principle of least privilege means an identity should hold the minimum permissions required to perform its documented function. This is not a one-time configuration — it is an ongoing review process. AWS Access Analyzer and IAM Access Advisor give you data to trim permissions over time.

For this lab, the permission model maps as follows:

• Human operators who audit documents need s3:GetObject and s3:ListBucket on the source bucket. They do not need to write, delete, or modify bucket policy.
• The EC2 processing instance needs s3:PutObject on the output bucket and s3:GetObject on the source bucket. It does not need IAM permissions, EC2 permissions, or access to any other bucket.

The moment you grant s3:* or use a wildcard resource (*) in a production policy, you have failed this design objective.

Conceptual Foundations Check

Question 1 of 2

0/2

Why should you attach policies to groups rather than directly to IAM users?

Groups allow policies to be managed centrally and revoked from a category of users in a single operationDirect user attachments do not work in AWSGroups provide stronger encryption for credentialsAWS charges less when using groups

Back

Submit