Creating IAM Users and Groups in AWS – SAP-C02 Study Guide

Purpose of This Lesson

AWS Identity and Access Management (IAM) controls who can access AWS resources and which actions they can perform. This lesson focuses on creating IAM groups and users, associating permissions through policies, and using an IAM user for AWS Management Console access.

For modern AWS environments, IAM Identity Center is generally preferred for workforce access across multiple AWS accounts. However, IAM users, groups, and policies remain important for AWS architecture exams and for specific account-level use cases.

Key Concepts

IAM users

An IAM user represents a long-term identity within a single AWS account. A user can have:

• Console access through a username and password.
• Programmatic access through credentials used by the AWS CLI, SDKs, or API tools.
• Permissions granted through group membership, directly attached policies, or both.

IAM users should not be used as a substitute for temporary credentials when a role or federated identity is appropriate.

IAM groups

An IAM group is a collection of IAM users. Policies attached to a group apply to its members, making groups useful for managing permissions consistently.

A typical pattern is:

1. Create a group based on a job function, such as Administrators, Developers, or ReadOnly.
2. Attach one or more IAM policies to the group.
3. Add users to the appropriate group.
4. Manage permissions by changing group membership or group policies.

Groups cannot contain other groups. They contain IAM users only.

IAM policies

IAM policies are JSON documents that define permissions. A policy statement commonly includes:

• Effect: Allow or Deny.
• Action: The AWS API operations affected.
• Resource: The resources affected.
• Optional conditions that further restrict when access is allowed.

An administrator-style policy with Action: "*" and Resource: "*" allows all actions on all resources unless an explicit deny or other policy control prevents access. This is extremely powerful and should be limited to tightly controlled administrative use cases.

IAM Identity Center

IAM Identity Center is AWS’s preferred service for workforce access in many multi-account environments. It supports centralized access management, federation, and single sign-on across AWS accounts and applications.

Use IAM Identity Center when users need centralized access to multiple AWS accounts or business applications. IAM users may still be encountered in existing environments, simple single-account setups, or exam scenarios specifically testing IAM fundamentals.

Root user versus IAM identities

The AWS account root user has unrestricted access to the account and should not be used for routine administration. Recommended controls include:

• Enable multi-factor authentication for the root user.
• Avoid creating root access keys.
• Use IAM roles, IAM Identity Center, or tightly controlled IAM identities for daily work.
• Monitor and protect root-user activity.

Exam-Relevant Takeaways

• Attach common permissions to IAM groups rather than duplicating policies on individual users.
• A user inherits permissions from groups to which it belongs.
• Allow with wildcard actions and resources is effectively administrator access and violates least-privilege design unless deliberately required.
• IAM is a global service; users, groups, roles, and policies are not created separately in each AWS Region.
• AWS resources themselves may be regional, but changing the console Region does not change the IAM identity or its account-wide permissions.
• IAM users can have console access, programmatic access, or both.
• IAM Identity Center is generally preferable for human workforce access spanning multiple AWS accounts.
• Use IAM roles and temporary credentials for workloads such as EC2, Lambda, and container tasks rather than embedding IAM user credentials.
• A password shown during IAM user creation may not be recoverable later; if it is lost, an administrator must reset it.
• Granting permissions directly to every user increases administrative overhead and makes consistent access reviews more difficult.

Architecture Decision Guide

Requirement	Preferred approach	Reason
Centralized employee access across multiple AWS accounts	IAM Identity Center	Provides centralized account assignments, federation, and SSO capabilities
Consistent permissions for several IAM users in one account	IAM group with attached policies	Centralizes permissions and simplifies onboarding or offboarding
Application or AWS service access	IAM role with temporary credentials	Avoids long-term user credentials and supports workload identity
A single user needs an unusual, narrowly scoped permission	Carefully controlled user policy or group design	Avoids broadening an entire group unnecessarily
Emergency or account-level administration	Dedicated, protected administrative identity or role	Enables strong controls and auditing while avoiding routine root-user use
Full account administration	Administrator policy or equivalent role, only when justified	Broad access is operationally powerful and should be tightly restricted

Common Exam Traps

• Confusing IAM groups with organizational units: IAM groups organize users and permissions within an account. AWS Organizations organizational units organize accounts.
• Assuming groups can contain groups: IAM groups can contain users, not nested groups.
• Treating IAM as regional: IAM is global. A user does not need to be recreated when operating in another Region.
• Using an IAM user for an EC2 application: Attach an IAM role to the instance instead.
• Choosing AdministratorAccess for every user: This fails least privilege and increases the impact of compromised credentials.
• Assuming a console login automatically provides permissions: Authentication proves identity; authorization comes from applicable IAM policies.
• Forgetting explicit denies: An explicit deny overrides an allow, including a broad allow.
• Using the root user for labs or routine tasks: The root user should be reserved for tasks that specifically require root credentials.
• Confusing the AWS account sign-in URL with a Region: The sign-in endpoint identifies the account and identity workflow. The selected console Region controls regional service views, not IAM scope.

Real-World Engineer Notes

• Prefer role-based access and federation for human users. IAM Identity Center can assign permission sets to users or groups across accounts.
• Use groups that reflect job functions and maintain a clear ownership model for each policy.
• Apply least privilege with specific actions, resources, and conditions instead of wildcard permissions whenever practical.
• Require MFA for privileged access and consider stronger controls such as phishing-resistant authentication through the organization’s identity provider.
• Use AWS CloudTrail to audit IAM changes and sign-in activity. Alert on unexpected policy modifications, root-user activity, and creation of access keys.
• Avoid sharing IAM users. Individual identities provide accountability and make access removal straightforward.
• Treat access keys as secrets. Prefer temporary credentials and rotate or remove long-term keys that are no longer required.
• For training accounts, an administrative user can simplify labs, but production environments should use narrowly scoped roles and permission sets.

Quick Reference Summary

• User: An identity in one AWS account; may have console and/or programmatic access.
• Group: A collection of IAM users used to apply shared permissions.
• Policy: A JSON permissions document containing effects, actions, resources, and optional conditions.
• Role: An identity that provides temporary credentials to trusted users, services, or accounts.
• IAM Identity Center: Centralized workforce access and SSO across AWS accounts and applications.
• Administrator policy: Broad access, commonly represented by all actions on all resources; use sparingly.
• Best practice: Do not use the root user for routine work; use least privilege, MFA, roles, and centralized identity management.

Flashcards

1. Q: What is the main purpose of an IAM group?

A: To apply shared permissions to multiple IAM users through group-attached policies.

1. Q: Can an IAM group contain another IAM group?

A: No. IAM groups contain IAM users only.

1. Q: What does Effect: Allow, Action: "*", and Resource: "*" generally represent?

A: Permission to perform all actions on all resources, similar to administrator access.

1. Q: What happens when a user is added to a group?

A: The user receives the permissions allowed by the policies attached to that group.

1. Q: Which service is designed for centralized workforce access across multiple AWS accounts?

A: IAM Identity Center.

1. Q: Should an EC2 application use an IAM user’s access keys?

A: No. Use an IAM role attached to the EC2 instance.

1. Q: Is IAM regional or global?

A: IAM is global within an AWS account.

1. Q: Which wins when one IAM policy allows an action but another applicable policy explicitly denies it?

A: The explicit deny.

1. Q: Why are groups preferred over attaching identical policies directly to many users?

A: Groups centralize permission management and reduce duplication and administrative error.

1. Q: Why should the root user not be used for routine administration?

A: It has unrestricted account access, so routine use increases security and accountability risk.

Practice Questions

Question 1

A company has 40 developers distributed across four AWS accounts. Employees currently use separate IAM users in each account, and administrators must update access manually whenever a developer changes teams. Which solution best reduces operational overhead?

A. Create an IAM group in each account and manually synchronize membership
B. Create one shared IAM user for all developers
C. Use IAM Identity Center with groups and account assignments
D. Store developer access keys in AWS Secrets Manager

Correct answer: C

Explanation: IAM Identity Center provides centralized workforce access, group-based assignments, and SSO across multiple AWS accounts. Shared users and long-term access keys reduce accountability and increase security risk.

Question 2

An application running on an EC2 instance needs to read objects from one S3 bucket. Which design follows AWS security best practices?

A. Create an IAM user and store its access keys in the application configuration
B. Attach an IAM role to the EC2 instance with permission to read the required bucket
C. Add AdministratorAccess to the EC2 instance’s user group
D. Use the root user credentials through the instance metadata service

Correct answer: B

Explanation: An EC2 instance profile supplies temporary credentials from an IAM role. The role policy can be scoped to the required S3 actions and bucket resources, avoiding long-term credentials and excessive permissions.

Question 3

An administrator attaches an allow policy for s3:GetObject to an IAM group. The same user is affected by another policy containing an explicit deny for s3:GetObject on the target bucket. What is the result?

A. The allow from the group takes precedence
B. The explicit deny takes precedence
C. The user can access the object only from the AWS console
D. The result depends on which policy was created first

Correct answer: B

Explanation: IAM policy evaluation applies an explicit deny over any applicable allow. Policy creation order does not determine the result.

Question 4

A small single-account environment wants several administrators to have the same permissions. The organization does not currently require federation or access to multiple AWS accounts. Which IAM design is the most appropriate among the choices?

A. Create individual IAM users and attach the same policy separately to each user
B. Create an administrators group, attach the required policy, and add the users to it
C. Give every administrator the root-user credentials
D. Create an IAM group for each AWS Region

Correct answer: B

Explanation: A group centralizes shared permissions and simplifies user management. IAM is global, so separate groups are not needed for each Region, and root credentials must not be shared.

Question 5

A user signs in successfully to the AWS Management Console but cannot perform an action in a service. What is the most likely explanation?

A. Authentication succeeded, but no applicable policy allows the requested action
B. IAM users can access only the Region where they were created
C. The user must be added to an IAM Identity Center permission set before IAM policies work
D. The AWS account has no root user

Correct answer: A

Explanation: Successful authentication establishes identity but does not grant authorization. The user needs an applicable allow, and access may still be blocked by an explicit deny, permission boundary, session policy, or other policy control.