AWS IAM Users, Groups, Roles, and Policies | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

Purpose of This Lesson

This lesson introduces the core identity and access management building blocks inside an AWS account: IAM users, IAM groups, IAM roles, and IAM policies.

For the SAP-C02 exam, this topic matters because many scenario-based questions depend on understanding who or what is requesting access, how permissions are granted, and whether temporary credentials or long-term credentials are the better design choice.

At the professional level, AWS expects you to understand that IAM is not just about creating users. It is about designing secure, scalable, and auditable access patterns across users, services, applications, and multiple AWS accounts.

Key Concepts

AWS IAM Overview

AWS Identity and Access Management, or IAM, is the service used to manage access to AWS resources.

Inside an AWS account, IAM includes several major components:

Users
Groups
Roles
Policies

These components work together to answer a basic question:

Is this identity allowed to perform this action on this AWS resource?

By default, AWS follows a secure model where permissions are not automatically granted. Access must be explicitly allowed through policies.

IAM Users

An IAM user is an identity inside an AWS account that usually represents a person or workload requiring long-term credentials.

Each AWS account also has a root user, which is the original account identity created when the AWS account was opened. The root user has full access to the account and should not be used for normal administrative work.

Root User Best Practices

The root user should be treated as highly sensitive because it has unrestricted access to the AWS account.

Best practices include:

Avoid using the root user for daily administration
Enable MFA on the root user
Use IAM users, roles, or federated identities for normal access
Secure the root account email address and credentials

For the exam, remember that the root user is not just another IAM user. It is the account owner identity and has permissions that should be tightly protected.

IAM User Limits and Defaults

AWS accounts can have up to 5,000 IAM users.

When a new IAM user is created, it has no permissions by default. The user may be able to authenticate, such as logging into the AWS Management Console, but cannot perform actions until permissions are granted.

This is an important exam point:

Authentication proves who the user is. Authorization determines what the user can do.

A user can authenticate successfully and still be denied access to AWS services if no permissions have been assigned.

IAM User Authentication Methods

IAM users can access AWS in multiple ways:

Access Method	Credential Type	Common Use
AWS Management Console	Username and password	Human interactive access
AWS CLI	Access key ID and secret access key	Command-line administration and automation
AWS API	Access key ID and secret access key	Programmatic access

Access keys are used for CLI and API access. From a security perspective, access keys require careful handling because they are long-term credentials unless rotated or removed.

For professional-level architecture, AWS generally prefers temporary credentials through roles when possible instead of long-term access keys.

Amazon Resource Names

An Amazon Resource Name, or ARN, uniquely identifies an AWS resource or identity.

For IAM users, the ARN includes the AWS account ID and the specific IAM identity. This means two users with the same friendly name in different AWS accounts still have different ARNs because the account ID is different.

Example conceptually:

arn:aws:iam::123456789012:user/username

The account ID makes the ARN globally unique across AWS accounts.

This matters when writing policies because permissions often reference specific resources, principals, or identities by ARN.

IAM Groups

An IAM group is a container for IAM users.

Groups are used to organize users and assign permissions collectively. Instead of attaching the same permissions policy to many users individually, you can attach the policy to a group and then place users into that group.

Common examples include:

Admin group
Developer group
Operations group
Read-only auditor group

A user can be a member of up to 10 IAM groups.

Why IAM Groups Matter

Groups simplify permission management.

Instead of managing permissions user by user, you manage permissions by job function. This aligns with the principle of least privilege because each group can receive only the permissions required for that role.

For example:

Group	Example Permission Pattern
Admins	Broad administrative permissions
Developers	Access to development services and resources
Operations	Monitoring, deployment, and operational access
Auditors	Read-only access for reporting and compliance

The user receives permissions from the policies attached to their group memberships.

IAM Roles

An IAM role is an identity with permissions that can be assumed by another trusted entity.

Roles are commonly assumed by:

IAM users
AWS services
Applications
Mobile apps
Federated users
Identities from another AWS account

Unlike IAM users, roles do not rely on permanent credentials. Instead, a trusted entity assumes the role and receives temporary security credentials.

Role Assumption and STS

The AWS Security Token Service, or STS, provides temporary credentials when a role is assumed.

For example, a user or application may call:

sts:AssumeRole

After the role is assumed, the caller receives temporary credentials and can act using the permissions assigned to that role.

This is a major exam concept:

IAM roles are used for delegation.

The identity assuming the role temporarily receives the permissions of the role. This allows AWS to avoid distributing long-term credentials in many scenarios.

IAM Roles for Cross-Account Access

IAM roles can also be used across AWS accounts.

For example, a user in Account A can be allowed to assume a role in Account B. After assuming the role, the user can access resources in Account B according to the permissions attached to that role.

This is one of the most important real-world and exam-relevant IAM patterns.

Common cross-account role scenarios include:

Centralized security team accessing member accounts
Shared services account managing infrastructure
Third-party vendor access
CI/CD pipeline deployment into workload accounts
AWS Organizations multi-account operations

For SAP-C02, cross-account access questions often expect an IAM role-based answer rather than creating duplicate IAM users in every account.

IAM Policies

An IAM policy defines permissions.

Policies are written in JSON and include permission statements that specify allowed or denied actions.

A policy defines things like:

Which actions are allowed
Which resources those actions apply to
Optional conditions that must be met

At a basic level, policies answer:

Can this identity perform this action against this resource?

Implicit Deny

AWS permissions are implicitly denied by default.

That means an identity cannot do anything unless a policy explicitly allows it.

This is one of the most important IAM fundamentals:

No policy allowing access means no access.

A user, group, or role does not automatically receive permissions just because it exists inside the AWS account.

Identity-Based Policies

An identity-based policy is attached to an IAM identity.

Identity-based policies can be attached to:

IAM users
IAM groups
IAM roles

For example, if a policy is attached to a Developers group, every user in that group receives the permissions defined by that policy.

This is one of the most common IAM permission models.

Resource-Based Policies

A resource-based policy is attached directly to an AWS resource.

Examples include:

Amazon S3 bucket policies
DynamoDB table resource policies

Resource-based policies define who can access the resource and what actions they can perform.

The major difference is where the policy is attached:

Policy Type	Attached To	Example
Identity-based policy	User, group, or role	IAM policy attached to a Developers group
Resource-based policy	AWS resource	S3 bucket policy

This distinction matters heavily on the exam, especially in cross-account access scenarios.

Identity-Based vs. Resource-Based Permissions

Identity-based policies answer:

What can this identity do?

Resource-based policies answer:

Who can access this resource?

For example:

An IAM role policy may allow s3:GetObject on a bucket.
An S3 bucket policy may allow a specific role or account to access the bucket.

In real AWS environments, access may require both sides to be configured correctly, especially when crossing account boundaries.

Exam-Relevant Takeaways

For SAP-C02, focus on the access design pattern, not just the IAM object name.

Key points to remember:

The root user has full account access and should be protected with MFA.
IAM users have no permissions by default.
IAM users can authenticate with a console password or access keys.
Access keys are used for CLI and API access.
IAM groups are used to manage permissions for multiple users.
A user can belong to up to 10 IAM groups.
An account can have up to 5,000 IAM users.
IAM roles are assumed by trusted entities.
Roles provide temporary credentials through AWS STS.
sts:AssumeRole is used to assume a role.
IAM roles are the preferred pattern for delegation.
IAM roles can support cross-account access.
IAM policies are JSON documents that define permissions.
Permissions are implicitly denied unless explicitly allowed.
Identity-based policies attach to users, groups, and roles.
Resource-based policies attach directly to resources such as S3 buckets or DynamoDB tables.

Architecture Decision Guide

Scenario	Best AWS Choice	Why
Grant the same permissions to multiple human users	IAM group with attached policy	Simplifies permission management and aligns access with job function
Grant permissions to one specific IAM user	Identity-based policy attached directly to user	Works, but is harder to scale and manage than group-based access
Allow an application or service to access AWS resources	IAM role	Provides temporary credentials and avoids embedding long-term access keys
Allow a user from another AWS account to access resources	Cross-account IAM role	Supports secure delegation without creating duplicate IAM users
Grant access directly on an S3 bucket	Resource-based bucket policy	The policy is attached to the resource and defines who can access it
Provide CLI or API access for an IAM user	Access keys	Access keys are used for programmatic access, though roles are preferred where possible
Identify a specific IAM user or resource in a policy	ARN	ARNs uniquely identify AWS identities and resources
Prevent use of the root account for daily tasks	IAM users, groups, and roles	Reduces risk by avoiding routine use of unrestricted root credentials

Common Exam Traps

Trap 1: Confusing Authentication with Authorization

A user may be able to sign in to the AWS Management Console, but that does not mean they can perform actions.

IAM users have no permissions by default. Permissions must be granted through policies.

Trap 2: Using the Root User for Administration

The root user has full permissions, but it should not be used for routine administration.

On the exam, answers that suggest using the root user for day-to-day access are usually wrong unless the scenario involves a task that specifically requires root.

Trap 3: Attaching Policies Directly to Every User

Attaching policies directly to users may work, but it does not scale well.

For groups of users with the same job function, use IAM groups and attach policies to the group.

Trap 4: Using Long-Term Access Keys When a Role Would Be Better

Access keys are valid for CLI and API access, but they are long-term credentials.

For applications, AWS services, federated users, and cross-account access, IAM roles are usually the better design because they use temporary credentials.

Trap 5: Confusing IAM Groups and IAM Roles

Groups are for organizing IAM users and assigning permissions collectively.

Roles are for delegation and are assumed by users, applications, or services.

A group is not assumed. A role is assumed.

Trap 6: Thinking Resource-Based Policies and Identity-Based Policies Are the Same

Identity-based policies are attached to identities.

Resource-based policies are attached to resources.

For example, an IAM policy attached to a role is identity-based. An S3 bucket policy is resource-based.

Real-World Engineer Notes

In real environments, IAM design becomes more important as the number of accounts, teams, applications, and automation workflows increases.

For a small AWS lab, it may be tempting to create IAM users and attach permissions directly to them. In a production environment, that becomes difficult to audit and maintain. A better model is to align access with job function, centralize identity where possible, and use roles for delegation.

For infrastructure engineers, IAM roles are especially important for automation. CI/CD pipelines, AWS services, and applications should not rely on hardcoded access keys when a role-based pattern is available. Temporary credentials reduce the blast radius of credential exposure and make access easier to revoke.

Cross-account roles are also a major operational pattern. In a multi-account AWS environment, you generally do not want to create the same administrator user in every account. Instead, you create a role in each target account and allow trusted identities to assume that role.

From a governance perspective, IAM groups and policies should be named clearly and reviewed regularly. Poor naming and excessive direct user permissions can make audits painful. In mature environments, you should be able to answer:

Who has access?
Why do they have access?
What policy grants the access?
Is the access still required?
Is the access temporary or long-term?

For troubleshooting, always separate the problem into authentication and authorization. First confirm the identity can authenticate. Then confirm whether policies allow the required action on the required resource.

Quick Reference Summary

IAM is the foundation of AWS access control.

IAM users represent identities with long-term credentials. IAM groups organize users and make permission assignment easier. IAM roles are assumed by trusted entities and provide temporary credentials through AWS STS. IAM policies are JSON documents that define permissions.

Permissions are implicitly denied by default. Access must be explicitly allowed.

For the SAP-C02 exam, remember that roles are preferred for delegation, cross-account access, AWS services, and applications. Groups are used to manage permissions for multiple IAM users. Resource-based policies attach directly to AWS resources, while identity-based policies attach to users, groups, or roles.

Flashcards

Q: What is the root user in an AWS account?
A: The original account identity created when the AWS account was opened. It has full permissions and should be protected with MFA and avoided for daily use.

Q: Do new IAM users have permissions by default?
A: No. IAM users have no permissions by default. Access must be explicitly granted through policies.

Q: What are IAM groups used for?
A: IAM groups are used to organize IAM users and assign permissions collectively through attached policies.

Q: How many IAM groups can a user belong to?
A: A user can belong to up to 10 IAM groups.

Q: How many IAM users can be created in an AWS account?
A: Up to 5,000 IAM users.

Q: What credential type is used by IAM users for console access?
A: A username and password.

Q: What credential type is used for CLI and API access?
A: Access keys, which include an access key ID and secret access key.

Q: What is an IAM role?
A: An IAM role is an identity with permissions that can be assumed by trusted users, services, or applications.

Q: What AWS service provides temporary credentials when assuming a role?
A: AWS Security Token Service, or STS.

Q: What API action is commonly used to assume an IAM role?
A: sts:AssumeRole.

Q: What is the main advantage of IAM roles over long-term access keys?
A: IAM roles provide temporary credentials, reducing the need to store or distribute long-term credentials.

Q: What is an identity-based policy?
A: A policy attached to an IAM identity such as a user, group, or role.

Q: What is a resource-based policy?
A: A policy attached directly to an AWS resource, such as an S3 bucket policy.

Q: What does implicit deny mean in IAM?
A: Access is denied unless a policy explicitly allows it.

Q: Why are ARNs important in IAM?
A: ARNs uniquely identify AWS identities and resources and are often used in policies.

Practice Questions

Question 1:
A company creates a new IAM user for a developer. The developer can sign in to the AWS Management Console but cannot view or modify any AWS resources. What is the most likely reason?

A. The IAM user does not have an access key
B. The IAM user has no permissions assigned
C. The IAM user must use the root account first
D. The IAM user is not assigned an ARN

Correct Answer:
B. The IAM user has no permissions assigned

Explanation:
IAM users have no permissions by default. Being able to authenticate to the console does not mean the user is authorized to perform actions.

Question 2:
A company has 20 developers who require the same permissions to work with development resources. What is the most scalable way to assign these permissions?

A. Attach the same policy directly to each IAM user
B. Add the users to an IAM group and attach the policy to the group
C. Give each user root account access
D. Create a separate AWS account for each developer

Correct Answer:
B. Add the users to an IAM group and attach the policy to the group

Explanation:
IAM groups allow permissions to be managed collectively. This is easier to maintain than attaching the same policy directly to many users.

Question 3:
An application needs temporary access to AWS resources without storing long-term access keys. Which IAM component is the best fit?

A. IAM group
B. IAM role
C. Root user
D. IAM user with console password

Correct Answer:
B. IAM role

Explanation:
IAM roles are assumed by trusted entities and provide temporary credentials through AWS STS. This avoids embedding long-term access keys in applications.

Question 4:
A user in one AWS account needs to access resources in another AWS account. Which design pattern is most appropriate?

A. Create a duplicate IAM user in the second account
B. Share the root user credentials for the second account
C. Configure a cross-account IAM role that the user can assume
D. Add the user to an IAM group in the first account only

Correct Answer:
C. Configure a cross-account IAM role that the user can assume

Explanation:
IAM roles support secure delegation across AWS accounts. The trusted user can assume the role and receive temporary credentials for the target account.

Question 5:
Which statement best describes the difference between identity-based and resource-based policies?

A. Identity-based policies are attached to resources, while resource-based policies are attached to users
B. Identity-based policies are attached to users, groups, or roles, while resource-based policies are attached directly to resources
C. Identity-based policies are only used for the root user
D. Resource-based policies cannot grant permissions to external identities

Correct Answer:
B. Identity-based policies are attached to users, groups, or roles, while resource-based policies are attached directly to resources

Explanation:
Identity-based policies define what an identity can do. Resource-based policies define who can access a specific resource.