IAM Users, Groups, Roles and Policies

AWS 020

IAM becomes much easier when the four core objects are separated clearly. Users and groups organize identities, roles provide assumable access, and policies define what those identities are allowed or denied to do.

What You Will Learn

• Understand the core concept and why it matters in real AWS environments.
• Learn the main AWS objects, controls and architecture patterns involved.
• See practical examples and common failure scenarios.
• Understand security, operational trade-offs and troubleshooting.
• Build a clear next step toward the following AWS topics.

Why This Topic Matters

Beginners often create a user, attach a large policy and assume the job is finished. Production AWS requires more discipline. The same access model may involve a human identity, a federated session, an assumed role, a workload role and resource-based policies. Knowing which object controls which part of the flow makes troubleshooting far easier.

1. Start With the Four Objects

Think of IAM objects as different layers rather than interchangeable labels. Users and groups primarily describe identities. Roles describe assumable identities. Policies describe permissions. A policy does not become a person or workload by itself; it becomes effective when attached or otherwise associated with an identity or resource.

This distinction becomes important when an organization moves from a small account to multiple teams and environments.

2. IAM Users

An IAM user represents an identity in an AWS account. Historically, teams often created a user for every employee and gave each user access keys and console credentials. That pattern can create credential lifecycle and governance problems when people change roles or leave.

For human workforce access, AWS recommends federation and temporary credentials. IAM users still exist for specific use cases, but they should not be treated as the default answer for every person.

3. IAM Groups

Groups are collections of IAM users. They are useful for organizing permission policies around responsibilities such as developers, analysts or auditors. A group can make permissions easier to manage than attaching the same policy independently to many users.

Groups do not become principals that can log in or assume roles. They are a permission-management mechanism for users.

4. IAM Roles

A role is designed to be assumed. It contains permissions and a trust policy. The permissions determine what the role can do; the trust relationship determines who can assume it.

Roles are central to workload access. An EC2 instance can use an instance profile to receive role credentials. Lambda can use an execution role. A CI/CD system can assume a deployment role. A human can assume a controlled administrative or troubleshooting role.

5. Trust Policy vs Permissions Policy

This is one of the most common points of confusion. A permissions policy answers: 'What can this role do?' A trust policy answers: 'Who is allowed to assume this role?'

If a role has perfect S3 permissions but its trust policy does not allow the intended principal to assume it, the workflow still fails. Conversely, a role can be assumable but useless if its permissions do not authorize the required action.

6. IAM Policies

Policies are JSON permission documents. Identity-based policies are attached to identities such as users, groups or roles. Resource-based policies are attached to resources such as S3 buckets or KMS keys. Other policy mechanisms, including permissions boundaries, session policies and Organizations SCPs, can also influence effective permissions.

The important production lesson is that a single policy file may not tell the whole story.

7. Managed vs Inline Policies

Managed policies can be reused and centrally updated, while inline policies are embedded directly with an identity. Reuse can improve consistency, but broad reusable policies can also become difficult to reason about.

For production environments, policy ownership, change control and review matter more than simply choosing one policy type. Keep permission sets understandable and aligned with responsibilities.

8. A Practical Example: Developer Access

Suppose a development team needs to work with EC2, Lambda and CloudWatch in a development account. Instead of giving each person administrator permissions, define an access model around the team's actual responsibilities. Human users authenticate through the organization's identity system, receive a permission set or role, and obtain temporary credentials.

The production environment can use a different role with narrower access and stronger controls. The same employee does not need the same permissions everywhere.

9. A Practical Example: Application Access

Suppose a Lambda function reads a secret and writes objects to S3. The function should use an execution role. That role can allow secretsmanager:GetSecretValue for the intended secret and the required S3 actions for the intended bucket or prefix.

The application should not contain a developer's personal access key. This separation keeps human and workload identities independent.

10. Common Design Errors

Common errors include using IAM users for workloads, attaching AdministratorAccess everywhere, confusing a role's trust policy with its permissions policy, using wildcard resources without a reason, and creating policies no one can explain.

Another error is assuming that IAM permissions alone determine access. Resource policies, SCPs, permissions boundaries and session policies may also affect the final decision.

11. Best Practices

Use roles and temporary credentials for workloads; use centralized workforce access where appropriate; keep permissions tied to responsibilities; use groups or permission sets for repeatable access patterns; review policies regularly; apply least privilege; and document why privileged roles exist.

Separate development, testing and production permissions so that an accidental action in one environment does not automatically become a production incident.

12. Troubleshooting Access

Start with the principal, action, resource and account. Then identify how the principal received credentials. For roles, inspect the trust policy and permissions policy. For resources, inspect resource-based policies. Then check boundaries, session policies and organization controls.

An AccessDenied error is evidence, not a reason to add permissions blindly.

13. Interview and Architecture Perspective

A strong AWS candidate should be able to explain why a workload uses a role instead of an access key, why a trust policy exists, how group-based permissions differ from role-based access, and why an SCP does not grant permissions.

In architecture reviews, these concepts reveal whether access control was designed intentionally or assembled reactively.

14. Learning Progression

Practice by building one user/group example, one role-assumption example, one EC2 or Lambda workload role and one resource-based policy example. Then deliberately create an AccessDenied situation and troubleshoot it. That exercise builds much stronger understanding than memorizing IAM terminology.

At a Glance

Production Scenario: Separating Human and Workload Access

A common mistake is using one powerful IAM identity for both developers and applications. Imagine a developer's access key is accidentally exposed in a build log. If that same identity is also used by a production deployment process, the blast radius becomes much larger. A better design gives the developer a controlled human access path and gives the deployment system a separate role with only deployment permissions. If one identity is compromised, the other does not automatically fall with it.

Architecture Decision Guide

Use groups to organize repeated user permissions, but prefer centralized workforce access for modern multi-account human access where appropriate. Use roles for applications, CI/CD and cross-account access. Keep role trust relationships narrow. Keep permissions policies focused on the resources and actions actually required. If a policy cannot be explained in one or two sentences, review whether the role has become a collection of unrelated responsibilities.

Interview Questions You Should Be Able to Answer

1. Can a group be assumed? — No; roles are designed for assumption.
2. What does a trust policy do? — It defines which principals can assume a role.
3. What does an identity-based policy do? — It grants or denies permissions to an identity.
4. Why separate production and development roles? — To reduce blast radius and make privileged access intentional.
5. What should you inspect first during AccessDenied? — The actual principal, action, resource and credential path used by the failing request.

Deep-Dive Checklist: Designing Clean Access

Before approving an access design, write down five things: the identity, the reason for access, the target account, the allowed actions and the expected lifetime of the access. Then ask whether the identity is human or workload. Human access should follow the organization's workforce identity pattern; workload access should use an appropriate role.

For every role, inspect both sides of the relationship. The trust policy should identify the expected principal, and the permissions policy should identify the expected actions and resources. If a role is used for several unrelated jobs, consider splitting it. Smaller roles are often easier to understand and safer to change.

Finally, test the negative path. If a developer should read an object but not delete it, actually test the delete operation. If a CI/CD role should deploy one service but not modify another, test the forbidden action. Security becomes much more believable when the deny behavior has been demonstrated rather than assumed.

Professional Review Perspective

When reviewing this design with another engineer, ask whether every permission has a named business or technical reason. Ask which identity owns the role, what happens when the workload is replaced, whether the role can be assumed by an unintended principal, and whether the permissions are different between development and production. Then test the expected access and at least one forbidden action. The objective is not to make the policy look small; it is to make the access model understandable, intentional and defensible.

Final Practical Check

A practical final check is to explain the design to someone who did not build it. If they can identify who receives access, what the identity can do, which resources are protected, and what happens when access is revoked, the design is probably understandable. If the explanation depends on hidden assumptions, undocumented exceptions or one person's memory, the architecture needs more documentation and simplification.

Advantages

• Clear separation of identity and permission responsibilities
• Reusable access patterns
• Better workload isolation
• Easier troubleshooting

Limitations and Considerations

• Too many roles or policies can create governance overhead.
• Poor naming makes access difficult to audit.
• Legacy IAM-user patterns may require careful migration.

Practical Exercise

Build a small IAM model containing a development group, a workload role and a resource policy. Deliberately break the role trust policy and diagnose the failure before fixing it.

Frequently Asked Questions

Can an IAM group be assumed?

No. Groups organize users and policies; roles are designed to be assumed.

What is the most important difference between role trust and role permissions?

Trust controls who can assume the role; permissions control what the role can do after it is assumed.

Should every employee have an IAM user?

Not necessarily. Centralized workforce access with temporary credentials is generally a stronger modern pattern.

Can a role work without a permissions policy?

A role can exist, but it will not have useful permissions unless applicable policies grant them.

Why should development and production access be different?

Separating access reduces blast radius and makes privileged production actions more deliberate.

Related AWS Topics

AWS IAM → IAM policy evaluation → IAM Identity Center → Secrets Manager

AWS Learning Path / Next Step

Next, learn IAM policy evaluation. Being able to predict an authorization decision is one of the most useful AWS troubleshooting skills.

Conclusion

Users, groups, roles and policies are simple individually but powerful when combined. The strongest designs separate human access from workload access, keep trust and permissions understandable, and make production privileges deliberate.

Canonical URL: https://kodestree.com/iam-users-groups-roles-and-policies/