IAM users and groups in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

What happens when an IAM user is removed from a group?

Consider an IAM user who is part of a group with specific permissions. What is the effect on the user's permissions immediately after they are removed from that group?

A The user’s permissions are unaffected because group membership changes do not apply to existing users.

B The user retains the group permissions until they log out and log back in.

C The user keeps the group permissions permanently unless explicitly revoked.

D The user immediately loses all permissions granted by the group.

💡 Hint

Think about how AWS evaluates permissions dynamically.

When a user is removed from a group, the permissions granted by that group are revoked immediately. AWS evaluates permissions in real time, so the user no longer inherits the group's permissions right after removal.

❓ Architecture

intermediate

How to organize IAM users for a company with multiple departments?

A company has three departments: Sales, Engineering, and HR. Each department needs different AWS permissions. What is the best way to organize IAM users and groups to manage permissions efficiently?

A Create one IAM group per department and assign users to their respective groups with department-specific policies.

B Create one IAM group for all users and assign all permissions to that group.

C Create individual IAM users with unique policies for each user without using groups.

D Assign permissions directly to IAM users without using groups or roles.

💡 Hint

Think about how groups help manage permissions for many users.

Using one group per department allows you to assign permissions once to the group. Then, adding or removing users from groups automatically grants or revokes the correct permissions. This is efficient and scalable.

❓ security

advanced

What is the security risk of assigning permissions directly to IAM users instead of groups?

Consider a scenario where permissions are assigned directly to individual IAM users rather than through groups. What is a key security risk of this approach?

A It increases the chance of inconsistent permissions and makes auditing difficult.

B It automatically grants admin access to all users.

C It disables multi-factor authentication for users.

D It prevents users from accessing AWS services.

💡 Hint

Think about managing many users and tracking their permissions.

Assigning permissions directly to users can lead to inconsistent permissions across users and makes it harder to audit and manage permissions. Groups help centralize and simplify permission management.

🧠 Conceptual

advanced

What is the effect of attaching multiple policies to an IAM group?

If an IAM group has multiple policies attached, how are the permissions combined for users in that group?

A Only the permissions from the first attached policy are applied.

B Permissions from all policies are combined, granting the union of all allowed actions.

C Permissions are intersected, so only actions allowed by all policies are granted.

D The last attached policy overrides all previous policies.

💡 Hint

Think about how AWS evaluates multiple policies together.

AWS combines permissions from all attached policies by taking the union of allowed actions. This means users get all permissions granted by any of the policies.

✅ Best Practice

expert

How to securely grant temporary elevated permissions to an IAM user?

An IAM user needs temporary elevated permissions for a specific task. Which approach follows AWS best practices for security?

A Attach the elevated permissions policy directly to the user permanently.

B Add the user to a group with elevated permissions permanently and remove them after the task.

C Create a role with the elevated permissions and allow the user to assume that role temporarily.

D Create a new IAM user with elevated permissions and share the credentials.

💡 Hint

Think about temporary access and avoiding permanent permission changes.

Using roles that users can assume temporarily is the best practice. It avoids permanent permission changes and reduces risk by granting elevated permissions only when needed.

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