Last updated on December 11, 2025
AWS Identity and Access Management Cheat Sheet
- AWS Identity and Access Management (IAM) is a global service that enables you to manage access to AWS services and resources securely. It controls who is authenticated (signed in) and authorized (has permissions) to use resources.
Features
-
Global Service
-
IAM configurations apply to all AWS Regions immediately.
-
-
Fine-Grained Access Control
-
Allows you to grant granular permissions to specific resources (e.g., allow read access to a specific S3 bucket) rather than granting full account access.
-
-
IAM Identities (The Principals)
-
Root User: The first identity created. Has complete, unrestricted access. Should be secured and not used for daily tasks.
-
IAM Users: Long-term credentials (password/access keys) for specific entities. Note: For human access, this is considered the legacy method. Use IAM Identity Center for workforce users.
-
IAM Groups: A collection of IAM users used to apply permissions to multiple users at once. Groups are not identities (you cannot log in as a group).
-
IAM Roles: An identity with no long-term credentials. Principals “assume” a role to obtain temporary security credentials for a short session.
-
-
Policies (Permissions)
-
JSON Structure: Policies are JSON documents defining
Effect(Allow/Deny),Action(API call), andResource(Target). -
Identity-Based Policies: Attached to a User, Group, or Role. Defines what they can do.
-
Resource-Based Policies: Attached directly to the resource (e.g., S3 Bucket Policy). Defines who can access it.
-
Permissions Boundary: An advanced feature that sets the maximum permissions an identity can ever have.
-
-
Policy Evaluation Logic
-
When determining access, AWS follows this strict order:
-
Explicit Deny: If any policy says “Deny”, the request is stopped immediately.
-
Explicit Allow: If a policy says “Allow” (and no Deny exists), the request is allowed.
-
Implicit Deny: If there is no Allow and no Deny, the request is denied by default.
-
-
-
AWS Security Token Service (STS)
-
A web service that enables you to request temporary, limited-privilege credentials.
-
AssumeRole: API to trade long-term credentials for temporary role credentials.
-
GetSessionToken: Often used to enforce MFA for CLI access.
-
-
AWS IAM Identity Center (Formerly AWS SSO)
-
The modern standard for managing workforce identities (human users).
-
Provides a single place to create or connect workforce users and manage their access across all AWS accounts in an Organization.
-
- Infrastructure Elements
-
Principal
- An entity that can make a request for an action or operation on an AWS resource. Users, roles, federated users, and applications are all AWS principals.
- Your AWS account root user is your first principal.
-
Request
- When a principal tries to use the AWS Management Console, the AWS API, or the AWS CLI, that principal sends a request to AWS.
- Requests includes the following information:
- Actions or operations – the actions or operations that the principal wants to perform.
- Resources – the AWS resource object upon which the actions or operations are performed.
- Principal – the user, role, federated user, or application that sent the request. Information about the principal includes the policies that are associated with that principal.
- Environment data – information about the IP address, user agent, SSL enabled status, or the time of day.
- Resource data – data related to the resource that is being requested.
-
Authentication
- To authenticate from the console as a user, you must sign in with your user name and password.
- To authenticate from the API or AWS CLI, you must provide your access key and secret key.
-
Authorization
- AWS uses values from the request context to check for policies that apply to the request. It then uses the policies to determine whether to allow or deny the request.
- Policies types can be categorized as permissions policies or permissions boundaries.
- Permissions policies define the permissions for the object to which they’re attached. These include identity-based policies, resource-based policies, and ACLs.
- Permissions boundary is an advanced feature that allows you to use policies to limit the maximum permissions that a principal can have.
- To provide your users with permissions to access the AWS resources in their own account, you need identity-based policies.
- Resource-based policies are for granting cross-account access.
- Evaluation logic rules for policies:
- By default, all requests are denied.
- An explicit allow in a permissions policy overrides this default.
- A permissions boundary overrides the allow. If there is a permissions boundary that applies, that boundary must allow the request. Otherwise, it is implicitly denied.
- An explicit deny in any policy overrides any allows.
-
Actions or Operations
- Operations are defined by a service, and include things that you can do to a resource, such as viewing, creating, editing, and deleting that resource.
-
Resource
- An object that exists within a service. The service defines a set of actions that can be performed on each resource.
Users
-
IAM Users
- Instead of sharing your root user credentials with others, you can create individual IAM users within your account that correspond to users in your organization. IAM users are not separate accounts; they are users within your account.
- Each user can have its own password for access to the AWS Management Console. You can also create an individual access key for each user so that the user can make programmatic requests to work with resources in your account.
- By default, a brand new IAM user has NO permissions to do anything.
- Users are global entities.
-
Federated Users
- If the users in your organization already have a way to be authenticated, you can federate those user identities into AWS.
-
IAM Groups
- An IAM group is a collection of IAM users.
- You can organize IAM users into IAM groups and attach access control policies to a group.
- A user can belong to multiple groups.
- Groups cannot belong to other groups.
- Groups do not have security credentials, and cannot access web services directly.
-
IAM Role
- A role does not have any credentials associated with it.
- An IAM user can assume a role to temporarily take on different permissions for a specific task. A role can be assigned to a federated user who signs in by using an external identity provider instead of IAM.
- AWS service role is a role that a service assumes to perform actions in your account on your behalf. This service role must include all the permissions required for the service to access the AWS resources that it needs.
- AWS service role for an EC2 instance is a special type of service role that a service assumes to launch an EC2 instance that runs your application. This role is assigned to the EC2 instance when it is launched.
- AWS service-linked role is a unique type of service role that is linked directly to an AWS service. Service-linked roles are predefined by the service and include all the permissions that the service requires to call other AWS services on your behalf.
- An instance profile is a container for an IAM role that you can use to pass role information to an EC2 instance when the instance starts.
- Users or groups can have multiple policies attached to them that grant different permissions.
|
When to Create IAM User |
When to Create an IAM Role |
|
You created an AWS account and you’re the only person who works in your account. |
You’re creating an application that runs on an Amazon EC2 instance and that application makes requests to AWS. |
|
Other people in your group need to work in your AWS account, and your group is using no other identity mechanism. |
You’re creating an app that runs on a mobile phone and that makes requests to AWS. |
|
You want to use the command-line interface to work with AWS. |
Users in your company are authenticated in your corporate network and want to be able to use AWS without having no sign in again (federate into AWS) |
Policies
- Most permission policies are JSON policy documents.
- The IAM console includes policy summary tables that describe the access level, resources, and conditions that are allowed or denied for each service in a policy.
- The policy summary table includes a list of services. Choose a service there to see the service summary.
- This summary table includes a list of the actions and associated permissions for the chosen service. You can choose an action from that table to view the action summary.
- To assign permissions to federated users, you can create an entity referred to as a role and define permissions for the role.
- Identity-Based Policies
-
- Permissions policies that you attach to a principal or identity.
- Managed policies are standalone policies that you can attach to multiple users, groups, and roles in your AWS account.
- Inline policies are policies that you create and manage and that are embedded directly into a single user, group, or role.
- Resource-based Policies
- Permissions policies that you attach to a resource such as an Amazon S3 bucket.
- Resource-based policies are only inline policies.
- Trust policies – resource-based policies that are attached to a role and define which principals can assume the role.
AWS Security Token Service (STS)
- Create and provide trusted users with temporary security credentials that can control access to your AWS resources.
- Temporary security credentials are short-term and are not stored with the user but are generated dynamically and provided to the user when requested.
- By default, AWS STS is a global service with a single endpoint at https://sts.amazonaws.com.
Assume Role Options
- AssumeRole – Returns a set of temporary security credentials that you can use to access AWS resources that you might not normally have access to. These temporary credentials consist of an access key ID, a secret access key, and a security token. Typically, you use AssumeRole within your account or for cross-account access.
- You can include multi-factor authentication (MFA) information when you call AssumeRole. This is useful for cross-account scenarios to ensure that the user that assumes the role has been authenticated with an AWS MFA device.
- AssumeRoleWithSAML – Returns a set of temporary security credentials for users who have been authenticated via a SAML authentication response. This allows you to link your enterprise identity store or directory to role-based AWS access without user-specific credentials or configuration.
- AssumeRoleWithWebIdentity – Returns a set of temporary security credentials for users who have been authenticated in a mobile or web application with a web identity provider. Example providers include Amazon Cognito, Login with Amazon, Facebook, Google, or any OpenID Connect-compatible identity provider.
STS Get Tokens
- GetFederationToken – Returns a set of temporary security credentials (consisting of an access key ID, a secret access key, and a security token) for a federated user. You must call the GetFederationToken operation using the long-term security credentials of an IAM user. A typical use is in a proxy application that gets temporary security credentials on behalf of distributed applications inside a corporate network.
- GetSessionToken – Returns a set of temporary credentials for an AWS account or IAM user. The credentials consist of an access key ID, a secret access key, and a security token. You must call the GetSessionToken operation using the long-term security credentials of an IAM user. Typically, you use GetSessionToken if you want to use MFA to protect programmatic calls to specific AWS API operations.
IAM Access Analyzer
- Provides policy checks that help you proactively validate policies when creating them. These checks analyze your policy and report errors, warnings, and suggestions with actionable recommendations that help you set secure and functional permissions.
- IAM Access Analyzer continuously monitors for new or updated resource policies and permissions granted for S3 buckets, KMS keys, SQS queues, IAM roles, Lambda functions, and Secrets Manager secrets.
IAM Identity Center
-
- The AWS IAM Identity Center is the successor to AWS Single Sign-On
- Enable you to manage sign-in security for your workforce identities, also known as workforce users.
- Manage your workforce’s sign-in security by creating or connecting your users and groups to AWS in one place.
- Workforce identities
- The members of your organization are also known as workforce users.
- You can only have 1 identity source per AWS organization:
- Identity Center directory
- Active Directory
- External identity provider
- Multi-account permissions
- Enables you to assign workforce identities access to AWS accounts.
- By enabling delegated administration, you can get the following benefits:
- Reduces the number of people who need access to the management account, which helps to alleviate security concerns.
- Allows select administrators to assign users and groups to applications as well as member accounts in your organization.
- You can manage access to AWS resources across multiple AWS accounts using attribute-based access control (ABAC).
- Requires fewer permission sets.
- Permissions for new resources are automatically granted.
- You can use employee attributes from the corporate directory.
- Keep track of who is accessing your resources.
- Application assignments
- Assign users access to SaaS applications.
- Supports the following types of applications:
- Identity Center enabled applications
- Cloud applications
- Custom SAML 2.0 applications
- You can also integrate AWS CLI version 2 with IAM Identity Center.
Security
-
IAM Access Analyzer
-
A proactive feature that checks your policies to identify resources (like S3 buckets or KMS keys) that are shared with external principals (publicly or with other accounts) to help you assess security risks.
-
-
Best Practices
-
Lock Away Root: Delete root access keys, enable MFA, and only use root to create the first IAM admin.
-
Use IAM Identity Center: Prefer Identity Center for human/workforce users over creating individual IAM Users.
-
Least Privilege: Grant only the permissions required to perform a task, and no more.
-
Enable MFA: Enforce Multi-Factor Authentication for all users (especially Root and Admins).
-
Rotate Credentials: Rotate Access Keys regularly to minimize the impact of compromised keys.
-
Use Roles for Compute: Never hard-code credentials in applications. Use IAM Roles for EC2, Lambda, and ECS.
-
Use Cases
1. EC2 Instance Accessing S3 (The “Role” Pattern)
-
Bad Way: Storing Access Keys on the EC2 instance.
-
Good Way: Create an IAM Role with S3 permissions. Attach the role to the EC2 instance (Instance Profile). The SDK on the instance automatically retrieves temporary credentials.
2. Cross-Account Access
-
Scenario: A Developer in “Account A” needs to manage a DynamoDB table in “Account B.”
-
Solution: Create a Role in Account B. Grant Account A permission to
AssumeRole. The Developer assumes the role to switch contexts.
3. Mobile App Authentication (Web Identity)
-
Scenario: Users log into your game using Facebook/Google.
-
Solution: Use Cognito (which uses STS
AssumeRoleWithWebIdentityunder the hood) to exchange the Facebook token for temporary AWS credentials.
Best Practices
- Lock Away Your AWS Account Root User Access Keys
- Create Individual IAM Users
- Use Groups to Assign Permissions to IAM Users
- Use AWS Defined Policies to Assign Permissions Whenever Possible
- Grant Least Privilege
- Use Access Levels to Review IAM Permissions
- Configure a Strong Password Policy for Your Users
- Enable MFA for Privileged Users
- Use Roles for Applications That Run on Amazon EC2 Instances
- Use Roles to Delegate Permissions
- Do Not Share Access Keys
- Rotate Credentials Regularly
- Remove Unnecessary Credentials
- Use Policy Conditions for Extra Security
- Monitor Activity in Your AWS Account
Pricing
-
Cost: Free
Become an IAM Policy Master in 60 Minutes or Less:
AWS IAM-related Cheat Sheets:
Note: If you are studying for the AWS Certified Security Specialty exam, we highly recommend that you take our AWS Certified Security – Specialty Practice Exams and read our Security Specialty exam study guide.
Validate Your Knowledge
Question 1
A company has 100 AWS accounts that are consolidated using AWS Organizations. The accountants from the finance department log in as IAM users in the TD-Finance AWS account. The finance team members need to read the consolidated billing information in the TD-Master AWS master account that pays the charges of all the member (linked) accounts. The required IAM access to the AWS billing services has already been provisioned in the master account. The Security Officer should ensure that the finance team must not be able to view any other resources in the master account.
Which of the following grants the finance team the necessary permissions for the above requirement?
- Set up an IAM group for the finance users in the
TD-Financeaccount then attach aViewBillingpermission and AWS managedReadOnlyAccessIAM policy to the group. - Set up IAM Roles Anywhere in the
TD-Masteraccount to allow finance users in theTD-Financeaccount to access billing information. - Set up an AWS IAM role in the
TD-Financeaccount with theViewBillingpermission then grant the finance users in theTD-Masteraccount the permission to assume that role. - Set up an IAM role in the
TD-Masteraccount with theViewBillingpermission then grant the finance users in theTD-Financeaccount the permission to assume the role.
Question 2
A leading insurance firm has several new members in its development team. The solutions architect was instructed to provision access to certain IAM users who perform application development tasks in the VPC. The access should allow the users to create and configure various AWS resources such as deploying Windows EC2 servers. In addition, the users should be able to see the permissions in AWS Organizations to view information about the user’s organization, including the master account email and organization limitations.
Which of the following should the solutions architect implement to follow the standard security advice of granting the least privilege?
- Attach the
PowerUserAccessAWS managed policy to the IAM users. - Attach the
AdministratorAccessAWS managed policy to the IAM users. - Create a new IAM role and attach the
SystemAdministratorAWS managed policy to it. Assign the IAM Role to the IAM users. - Create a new IAM role and attach the
AdministratorAccessAWS managed policy to it. Assign the IAM Role to the IAM users.
For more AWS practice exam questions with detailed explanations, visit the Tutorials Dojo Portal:
Additional Training Materials: AWS IAM Video Courses on Udemy
AWS IAM Cheat Sheet References:
https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html
https://aws.amazon.com/iam/faqs/

















