IAM users and groups in AWS - Step-by-Step Execution

Process Flow - IAM users and groups

Create IAM User

↓

Create IAM Group

↓

Attach Policies to Group

↓

Add User to Group

↓

User inherits Group Permissions

↓

User can access AWS resources based on permissions

This flow shows how you create users and groups, attach permissions to groups, add users to groups, and how users get permissions from groups.

Execution Sample

AWS

1. Create user 'Alice'
2. Create group 'Developers'
3. Attach 'AmazonS3ReadOnlyAccess' policy to 'Developers'
4. Add 'Alice' to 'Developers'

This example creates a user and a group, gives the group read-only access to S3, then adds the user to the group so she inherits that access.

Process Table

Step	Action	Resource Created/Modified	Permissions Assigned	Result
1	Create IAM user 'Alice'	User: Alice	No permissions yet	User 'Alice' exists with no permissions
2	Create IAM group 'Developers'	Group: Developers	No permissions yet	Group 'Developers' exists with no permissions
3	Attach 'AmazonS3ReadOnlyAccess' policy to 'Developers'	Group: Developers	S3 Read-Only Access	Group 'Developers' has S3 read-only permissions
4	Add user 'Alice' to group 'Developers'	User: Alice	Inherits S3 Read-Only Access from group	User 'Alice' can read S3 buckets
5	User 'Alice' tries to write to S3	User: Alice	S3 Read-Only Access	Access denied - write not allowed
6	User 'Alice' tries to read from S3	User: Alice	S3 Read-Only Access	Access granted - read allowed

💡 User 'Alice' inherits permissions from group 'Developers'; actions allowed or denied based on those permissions.

Status Tracker

Entity	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
User 'Alice' Permissions	None	None	None	None	S3 Read-Only Access (via group)	S3 Read-Only Access (via group)
Group 'Developers' Permissions	None	None	None	S3 Read-Only Access	S3 Read-Only Access	S3 Read-Only Access

Key Moments - 3 Insights

Why does user 'Alice' have permissions after being added to the group?

Because groups hold permissions, and when a user is added to a group, the user inherits all permissions assigned to that group, as shown in step 4 of the execution_table.

Can user 'Alice' write to S3 after inheriting read-only access?

No, the permissions are read-only, so write attempts are denied, as shown in step 5 of the execution_table.

What happens if a user is not added to any group?

The user has no permissions unless permissions are assigned directly to the user. In this example, before step 4, 'Alice' has no permissions.

Visual Quiz - 3 Questions

Look at the execution_table, what permissions does user 'Alice' have immediately after step 3?

A S3 Read-Only Access

B No permissions

C Full S3 Access

D Write access to S3

💡 Hint

Check the 'Permissions Assigned' column for user 'Alice' at step 3 in the execution_table.

At which step does user 'Alice' gain S3 read-only permissions?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look for when 'Alice' is added to the group that has the permissions in the execution_table.

If the 'AmazonS3ReadOnlyAccess' policy was attached directly to user 'Alice' instead of the group, how would the execution_table change?

A Step 3 would show policy attached to user, and step 4 would be adding user to group with no permissions

B Step 4 would be skipped

C User 'Alice' would have permissions after step 1

D No change in execution_table

💡 Hint

Consider where the policy is attached and how that affects the steps in the execution_table.

Concept Snapshot

IAM Users and Groups:
- Users represent individual people or services.
- Groups hold permissions (policies).
- Attach policies to groups, not users directly.
- Add users to groups to grant permissions.
- Users inherit all group permissions.
- Permissions control access to AWS resources.

Full Transcript

This visual execution shows how IAM users and groups work in AWS. First, you create a user named 'Alice' with no permissions. Then, you create a group called 'Developers' which also starts with no permissions. Next, you attach a policy called 'AmazonS3ReadOnlyAccess' to the group, giving it permission to read S3 buckets. After that, you add 'Alice' to the 'Developers' group. Because of this, 'Alice' inherits the group's permissions and can read from S3. Attempts to write to S3 are denied because the permission is read-only. This demonstrates how users gain permissions through group membership, simplifying permission management.

Practice

1. What is the main purpose of an IAM group in AWS?

easy

A. To organize multiple IAM users and assign permissions collectively

B. To store data securely in the cloud

C. To create virtual servers for applications

D. To monitor network traffic in AWS

Solution

1. Step 1: Understand IAM user and group roles

   IAM users represent individuals or services, while groups organize these users.

2. Step 2: Identify the purpose of groups

   Groups allow assigning permissions to many users at once, simplifying management.

3. Final Answer:

   To organize multiple IAM users and assign permissions collectively -> Option A

4. Quick Check:

   IAM groups = organize users + assign permissions [OK]

Hint: Groups bundle users for easy permission management [OK]

Common Mistakes:

• Confusing groups with storage or servers
• Thinking groups monitor network traffic
• Believing groups are individual user accounts

2. Which of the following is the correct way to add an IAM user named alice to a group named Developers using AWS CLI?

easy

A. aws iam add-group-to-user --group-name Developers --user-name alice

B. aws iam attach-user-policy --user-name alice --policy-name Developers

C. aws iam add-user-to-group --user-name alice --group-name Developers

D. aws iam create-group --group-name Developers --user alice

Solution

1. Step 1: Recall AWS CLI command for adding user to group

   The correct command is aws iam add-user-to-group with parameters --user-name and --group-name.

2. Step 2: Match command syntax with options

   aws iam add-user-to-group --user-name alice --group-name Developers matches the correct syntax exactly.

3. Final Answer:

   aws iam add-user-to-group --user-name alice --group-name Developers -> Option C

4. Quick Check:

   Correct CLI command = aws iam add-user-to-group --user-name alice --group-name Developers [OK]

Hint: Use 'add-user-to-group' command with user and group names [OK]

Common Mistakes:

• Using 'attach-user-policy' instead of adding to group
• Confusing 'create-group' with adding users
• Reversing user and group parameters

3. Given the following IAM group policy attached to group Admins:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
  }]
}

If user bob is added to the Admins group, what permissions does bob have on S3?

medium

A. Full access to all S3 actions and resources

B. Read-only access to S3 buckets

C. No access to S3 unless user policy allows it

D. Access only to S3 buckets created by bob

Solution

1. Step 1: Analyze the group policy permissions

   The policy allows all S3 actions (s3:*) on all resources (*), meaning full access.

2. Step 2: Understand group membership effect

   User bob inherits all permissions from the Admins group.

3. Final Answer:

   Full access to all S3 actions and resources -> Option A

4. Quick Check:

   Group policy allows s3:* on * = full access [OK]

Hint: s3:* on * means full S3 access [OK]

Common Mistakes:

• Assuming user needs separate policy for access
• Thinking group policies restrict to created buckets
• Confusing read-only with full access

4. You tried to add user carol to group Managers using this command:

aws iam add-user-to-group --group-name Managers --user carol

But it failed. What is the error in this command?

medium

A. The command should be 'aws iam add-group-to-user' instead

B. The parameter should be --user-name, not --user

C. The group name should be specified after --user-name

D. The user name must be in quotes

Solution

1. Step 1: Check AWS CLI command syntax

   The correct parameter for specifying the user is --user-name, not --user.

2. Step 2: Identify the error in the command

   Using --user causes the command to fail because it is invalid.

3. Final Answer:

   The parameter should be --user-name, not --user -> Option B

4. Quick Check:

   Correct parameter = --user-name [OK]

Hint: Use --user-name, not --user, for specifying IAM user [OK]

Common Mistakes:

• Using incorrect parameter names
• Swapping user and group parameters
• Adding unnecessary quotes around names

5. You want to create a secure setup where users in the Developers group can only start and stop EC2 instances, but not terminate them. Which IAM policy snippet attached to the group achieves this?

hard

A. {
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["ec2:StartInstances", "ec2:StopInstances", "ec2:TerminateInstances"],
"Resource": "*"
}]
}

B. {
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*"
}]
}

C. {
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": "ec2:TerminateInstances",
"Resource": "*"
}]
}

D. {
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["ec2:StartInstances", "ec2:StopInstances"],
"Resource": "*"
}]
}

Solution

1. Step 1: Understand required permissions

   Users should only start and stop instances, so allow only those actions.

2. Step 2: Evaluate policy options

   { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["ec2:StartInstances", "ec2:StopInstances"], "Resource": "*" }] } allows only StartInstances and StopInstances. { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "ec2:*", "Resource": "*" }] } allows all EC2 actions, including terminate. { "Version": "2012-10-17", "Statement": [{ "Effect": "Deny", "Action": "ec2:TerminateInstances", "Resource": "*" }] } denies terminate but does not allow start/stop explicitly. { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["ec2:StartInstances", "ec2:StopInstances", "ec2:TerminateInstances"], "Resource": "*" }] } allows terminate, which is not desired.

3. Final Answer:

   Policy allowing only start and stop EC2 instances -> Option D

4. Quick Check:

   Allow only start/stop, no terminate = { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["ec2:StartInstances", "ec2:StopInstances"], "Resource": "*" }] } [OK]

Hint: Allow only needed actions, avoid wildcard ec2:* [OK]

Common Mistakes:

• Using ec2:* allows unwanted terminate action
• Only denying terminate without allowing start/stop
• Including terminate in allowed actions