Study guide
Technical reference and lesson notes
Purpose of This Lesson
AWS Identity and Access Management, or IAM, is the core AWS service used to control authentication and authorization inside an AWS account. For the SAP-C02 exam, IAM is foundational because almost every architecture question involves deciding who or what can access a resource, how access is granted, and how permissions should be managed securely at scale.
This lesson focuses on the core building blocks of IAM:
- Users
- User groups
- Roles
- Policies
- Root user security
- Console versus programmatic access
- Access keys and short-term credentials
Key Concepts
What AWS IAM Does
IAM controls access to AWS services and resources. It answers two major questions:
- Who or what is making the request?
- Is that identity allowed to perform the requested action?
IAM applies whether AWS is accessed through:
- AWS Management Console
- AWS Command Line Interface
- AWS SDKs
- Direct AWS API calls
In AWS, nearly every action is an API request. Examples include:
- Launching an EC2 instance
- Reading information about an S3 bucket
- Creating an IAM user
- Assuming an IAM role
- Calling an AWS service from an application
Before AWS allows the action, the requester must be authenticated and then authorized.
Authentication vs Authorization
Authentication
Authentication proves identity.
In plain English: Are you really who you claim to be?
Examples:
- IAM user signs in with username and password
- User provides MFA token during console sign-in
- Application authenticates with access keys
- Temporary credentials are issued by AWS Security Token Service, or STS
Authorization
Authorization determines what the authenticated identity is allowed to do.
In plain English: Now that AWS knows who you are, what are you allowed to access?
Authorization is controlled through IAM policies. These policies define allowed or denied API actions against AWS resources.
For example, an identity may be allowed to:
- Run EC2 instances
- Read S3 bucket metadata
- Create IAM users
- Assume a role
- Access a specific resource but not others
For the exam, remember this order:
Authenticate first, authorize second.
An identity may successfully authenticate but still have no usable permissions.
IAM Principals
An IAM principal is a person, application, or service that makes a request to AWS.
Examples of principals include:
- IAM user
- IAM role
- Federated user
- AWS service principal
- Application using AWS credentials
A principal sends a request to perform an API action against an AWS resource. AWS evaluates whether the principal has permission to perform that action.
IAM Users
An IAM user represents a specific identity in an AWS account.
IAM users can be used for:
- Human console access
- Programmatic access through access keys
- Service or application authentication, although roles are usually preferred for AWS workloads
Important points:
- IAM users have a friendly name.
- IAM users have an Amazon Resource Name, or ARN.
- IAM users have no permissions by default.
- Permissions must be granted using policies.
- IAM users can be members of one or more groups.
- IAM users can authenticate to the console using a password and optionally MFA.
- IAM users can authenticate programmatically using access keys.
The transcript mentions that an AWS account can have up to 5,000 IAM users. For SAP-C02, the bigger takeaway is not just the number. The key design point is that large-scale access management should not rely on individually managed users and one-off permissions. Use groups, roles, federation, and policy-based governance instead.
IAM User Permissions Are Not Automatic
A newly created IAM user does not automatically inherit permissions just because it exists in the account.
This is an exam-relevant point.
A user may be able to sign in to the AWS Management Console, but if no permissions are attached directly or indirectly, the user cannot perform meaningful actions.
Permissions can be assigned through:
- Policies attached directly to the user
- Policies attached to a group the user belongs to
- Permissions gained by assuming a role
In general, avoid attaching policies directly to individual users unless there is a specific reason. Group-based or role-based access is easier to manage and audit.
IAM User Groups
IAM user groups simplify permission management for multiple IAM users.
Instead of assigning the same policy to many individual users, you can:
- Create a group.
- Attach a policy to the group.
- Add users to the group.
Example groups:
- Admins
- Developers
- Operations
- ReadOnlyUsers
- SecurityAuditors
If users share the same job function, place them in a group and assign permissions to the group.
Multiple Group Membership
IAM users can belong to multiple groups.
When a user is in multiple groups, permissions are combined.
For example:
| Group | Permissions |
|---|---|
| Developers | Access development resources |
| ReadOnlyBilling | View billing information |
| S3ReadOnly | Read S3 buckets |
A user in all three groups receives the combined effective permissions from all attached group policies.
However, remember that explicit deny always overrides allow in IAM policy evaluation. Even though this transcript focuses on the basics, the exam often tests this concept in broader IAM scenarios.
IAM Policies
IAM policies define permissions.
A policy specifies:
- Effect: Allow or Deny
- Action: The AWS API action
- Resource: The AWS resource the action applies to
- Optional conditions: Additional restrictions such as IP address, MFA status, region, tags, or time-based controls
The transcript introduces two important policy categories:
Identity-Based Policies
Identity-based policies are attached to IAM identities:
- Users
- Groups
- Roles
These policies define what the identity is allowed to do.
Example:
A policy attached to a developer group might allow developers to start and stop EC2 instances in a development account.
Resource-Based Policies
Resource-based policies are attached directly to AWS resources.
Examples include:
- S3 bucket policies
- KMS key policies
- SQS queue policies
- SNS topic policies
- Lambda function resource policies
Resource-based policies define who can access the resource and what actions they can perform.
For SAP-C02, this distinction matters because some services commonly use resource policies for cross-account access, while IAM identity policies are commonly used to control permissions inside an account.
IAM Roles
IAM roles are identities with permissions, but they are not meant to be permanently logged into like users.
A role is assumed.
When a principal assumes a role, it temporarily receives the permissions assigned to that role.
Roles are commonly used for:
- Delegation
- Cross-account access
- AWS service permissions
- Applications running on AWS
- Temporary elevated access
- Federation scenarios
A role is often a better design than long-term IAM user credentials because roles support temporary credentials.
Role Assumption
When a principal assumes a role, the principal temporarily operates with the permissions assigned to that role.
Think of it as temporarily switching job functions.
Examples:
- A developer assumes a deployment role.
- An EC2 instance assumes a role to read from S3.
- A Lambda function assumes an execution role.
- A user from one AWS account assumes a role in another AWS account.
For the SAP-C02 exam, roles are usually preferred when AWS services or applications need access to other AWS resources.
AWS Management Console Access
IAM users can access the AWS Management Console using:
- Account alias or account ID
- IAM user name
- Password
- Optional MFA token
Console access is typically used by humans.
Security best practices include:
- Require MFA
- Use strong passwords
- Avoid using the root user
- Grant least privilege
- Avoid direct user policies where group or role-based access is better
Programmatic Access
Programmatic access is used for:
- AWS CLI
- AWS SDKs
- API calls
- Automation scripts
- Applications
Programmatic credentials can include:
- Access key ID
- Secret access key
- Temporary credentials from AWS STS
Access keys function somewhat like a username and password for API access, so they must be protected carefully.
Access Keys
An access key consists of:
- Access key ID
- Secret access key
These are used to authenticate programmatic requests to AWS.
Access keys are powerful and risky because they are long-lived unless rotated or deleted.
Best practices:
- Do not embed access keys in code.
- Do not store access keys in public repositories.
- Rotate keys regularly.
- Prefer IAM roles and temporary credentials where possible.
- Disable unused keys.
- Monitor access key usage.
AWS Security Token Service
AWS Security Token Service, or STS, is used to issue temporary security credentials.
Temporary credentials are commonly used when assuming IAM roles.
For SAP-C02, temporary credentials are important because they support better security than static long-term credentials.
Common use cases:
- Cross-account role assumption
- Federated user access
- AWS service roles
- Temporary elevated permissions
- Application access without hardcoded credentials
IAM Root User
The root user is created when the AWS account is created.
It uses the email address associated with the AWS account.
The root user has full access to the account and is difficult to restrict. Some root user permissions cannot be limited the same way IAM user permissions can.
Root user best practices:
- Do not use the root user for daily administration.
- Set a strong password.
- Enable MFA.
- Store credentials securely.
- Use root only for tasks that specifically require it.
- Create IAM users, roles, or federated identities for normal administration.
Root User vs IAM User
| Feature | Root User | IAM User |
|---|---|---|
| Created when account is created | Yes | No |
| Sign-in identifier | Account email address | Account alias or account ID plus IAM user name |
| Default permissions | Full account access | No permissions by default |
| Can be fully restricted | Not fully | Yes, through IAM policies |
| Best use | Break-glass/account-level tasks | Normal user access when needed |
| Should be used daily | No | Only if appropriate |
| MFA recommended | Yes, strongly | Yes, especially privileged users |
Amazon Resource Names
AWS resources have Amazon Resource Names, or ARNs.
An ARN uniquely identifies a resource in AWS.
For IAM users, the ARN includes information such as:
- AWS partition
- Service name
- AWS account ID
- Resource type
- User name
For SAP-C02, ARNs matter because IAM policies often reference specific resources using ARNs.
Exam-Relevant Takeaways
For the SAP-C02 exam, remember these core IAM points:
IAM is responsible for both authentication and authorization.
Authentication proves identity. Authorization determines what actions are allowed.
All AWS API requests are made by a principal.
A principal can be a user, role, federated identity, service, or application.
IAM users have no permissions by default.
IAM users can sign in to the console if console access is enabled, but they still cannot perform actions unless permissions are granted.
User groups simplify permissions management by allowing policies to be attached once and inherited by multiple users.
Users can belong to multiple groups, and permissions are combined.
IAM roles are assumed and are used for delegation.
Roles are preferred for AWS services, applications, cross-account access, and temporary access patterns.
Access keys are used for CLI, SDK, and API access.
Access keys are long-term credentials and should be avoided when a role-based design is possible.
AWS STS provides temporary credentials.
The root user has unrestricted account-level power and should not be used for daily operations.
Enable MFA on the root user and secure it as a break-glass identity.
Architecture Decision Guide
| Scenario | Best AWS Choice | Why |
|---|---|---|
| A human administrator needs console access | IAM user or federated identity with MFA | Console access requires authentication, and MFA improves security |
| Multiple developers need the same permissions | IAM group with an attached policy | Easier to manage one policy at the group level than many user policies |
| A user needs permissions from multiple job functions | Add the user to multiple groups | Group permissions are combined |
| An application needs AWS API access | IAM role where possible | Avoids hardcoded long-term access keys |
| AWS CLI access is needed for a user | Access key or temporary credentials | CLI/API access requires programmatic credentials |
| Temporary elevated permissions are needed | Assume an IAM role using STS | Provides temporary credentials instead of permanent standing access |
| Root-level account action is required | Root user | Some account-level actions require root, but this should be rare |
| Daily AWS administration | IAM user, role, or federated access | Avoid using the root account for normal operations |
| Cross-account access | IAM role assumption | Role delegation is the standard AWS pattern |
| Granting permissions to a specific S3 bucket | Identity policy or S3 bucket policy depending on design | Identity policies grant permissions to identities; resource policies grant access at the resource |
Common Exam Traps
Trap 1: Assuming IAM Users Have Permissions by Default
A new IAM user has no permissions until policies are attached directly, through a group, or through a role assumption path.
If an exam question says a user can sign in but cannot do anything, the likely issue is missing authorization, not authentication.
Trap 2: Confusing Authentication and Authorization
Signing in successfully does not mean the user can perform actions.
Authentication answers: Who are you?
Authorization answers: What are you allowed to do?
Trap 3: Using the Root User for Normal Administration
The root user should be secured and rarely used.
If an answer suggests using the root user for daily operations, it is usually wrong.
Trap 4: Attaching Policies Directly to Many Users
Direct user policy assignment does work, but it is harder to manage at scale.
For groups of people with the same job role, IAM groups are usually the better answer.
Trap 5: Using Long-Term Access Keys When Roles Are Available
Access keys are valid for programmatic access, but they introduce credential management risk.
For AWS services and applications running in AWS, IAM roles are usually the better design.
Trap 6: Forgetting That Group Permissions Combine
If a user belongs to several groups, the permissions from those groups are combined.
However, in broader IAM evaluation, explicit deny still overrides allow.
Trap 7: Thinking Roles Are Logged Into Like Users
A role is not a traditional user account.
A role is assumed by a trusted principal, and temporary credentials are issued.
Real-World Engineer Notes
In a real environment, IAM design becomes a governance and operational issue quickly.
For a small lab, it may be tempting to create IAM users and attach policies directly. In production, that approach becomes difficult to audit and maintain. Group-based permissions are better for basic human access, while roles and federation are better for scalable enterprise access.
Root user handling should be part of your account build checklist. At minimum, enable MFA, secure the password, and avoid using the root account except for required account-level operations. In a multi-account environment, root user governance becomes even more important because every AWS account has its own root identity.
Access keys should be treated like secrets. If a developer stores an access key in a script, local config file, or Git repository, that key can be abused. Prefer temporary credentials from role assumption wherever possible.
IAM roles are central to clean AWS architecture. EC2 instances, Lambda functions, automation pipelines, and cross-account access patterns should rely on roles rather than static credentials. This reduces secret sprawl and makes access easier to revoke.
From an operations perspective, IAM troubleshooting usually starts with these questions:
- Did the identity authenticate successfully?
- What principal made the request?
- What policies apply to the principal?
- Is the permission attached directly, through a group, or through a role?
- Is there a missing allow?
- Is there an explicit deny?
- Is the request using console credentials, access keys, or temporary credentials?
- Is the wrong identity or role being used?
For cloud engineers, IAM is not just a security topic. It affects deployments, automation, application design, audit readiness, incident response, and account governance.
Quick Reference Summary
IAM controls access to AWS services and resources.
Authentication proves identity.
Authorization determines allowed actions.
A principal is a person, service, or application making an AWS API request.
IAM users have no permissions by default.
IAM groups help manage permissions for multiple users.
IAM roles are assumed and used for delegation.
Policies define permissions.
Identity-based policies attach to users, groups, and roles.
Resource-based policies attach to resources.
Console access uses username, password, and optionally MFA.
Programmatic access uses access keys or temporary credentials.
AWS STS issues short-term credentials.
The root user has full account access and should be locked down with MFA.
Use the root user only when absolutely necessary.
Flashcards
Q: What is the primary purpose of AWS IAM?
A: IAM controls authentication and authorization for AWS services and resources.
Q: What is authentication in AWS IAM?
A: Authentication proves that a user, application, or service is who or what it claims to be.
Q: What is authorization in AWS IAM?
A: Authorization determines whether an authenticated principal is allowed to perform a specific action on a resource.
Q: What is an IAM principal?
A: A principal is a person, application, service, or identity that makes a request to AWS.
Q: Do new IAM users have permissions by default?
A: No. New IAM users have no permissions until policies are attached directly, through groups, or through role assumption.
Q: What is the purpose of an IAM group?
A: An IAM group lets you manage permissions for multiple users by attaching policies to the group.
Q: What happens if a user belongs to multiple IAM groups?
A: The user receives the combined permissions from all groups.
Q: What is an IAM role?
A: An IAM role is an identity with permissions that can be assumed by a trusted principal.
Q: Why are roles preferred over long-term access keys for applications?
A: Roles provide temporary credentials and reduce the risk of hardcoded or leaked long-term credentials.
Q: What service issues temporary AWS credentials?
A: AWS Security Token Service, or STS.
Q: What credentials are commonly used for AWS CLI and SDK access?
A: Access key ID and secret access key, or temporary credentials.
Q: How does the root user sign in?
A: The root user signs in using the email address used to create the AWS account.
Q: Why should the root user not be used for daily administration?
A: The root user has unrestricted account access and some permissions cannot be fully limited.
Q: What should be enabled on the root user?
A: A strong password and MFA.
Q: What is an ARN?
A: An Amazon Resource Name uniquely identifies an AWS resource.
Practice Questions
Question 1:
A new IAM user has been created and given AWS Management Console access. The user can sign in successfully but receives access denied errors when trying to view EC2 instances. What is the most likely cause?
A. The user has not authenticated successfully
B. The user does not have permissions assigned through an IAM policy
C. The root user password needs to be reset
D. The user must use access keys instead of console access
Correct Answer:
B. The user does not have permissions assigned through an IAM policy
Explanation:
IAM users have no permissions by default. A user may authenticate successfully to the console but still be unauthorized to perform AWS actions unless permissions are granted.
Question 2:
A company has ten developers who all need the same permissions in an AWS account. What is the best way to manage their permissions?
A. Attach the same policy directly to each IAM user
B. Add all users to an IAM group and attach the policy to the group
C. Give each user the root account password
D. Create access keys for each user and share them across the team
Correct Answer:
B. Add all users to an IAM group and attach the policy to the group
Explanation:
IAM groups simplify permission management for users with similar job responsibilities. This avoids managing the same policy separately on each user.
Question 3:
An application running in AWS needs to call AWS APIs. Which access pattern is generally preferred?
A. Store the root user credentials in the application
B. Store an IAM user access key directly in the application code
C. Use an IAM role that the application can assume
D. Use the AWS account email address and password
Correct Answer:
C. Use an IAM role that the application can assume
Explanation:
IAM roles are preferred for applications and AWS services because they use temporary credentials and avoid long-term embedded secrets.
Question 4:
Which statement best describes the AWS root user?
A. It has no permissions until policies are attached
B. It is created only after the first IAM user is created
C. It has full account access and should be secured with MFA
D. It is the preferred identity for daily AWS administration
Correct Answer:
C. It has full account access and should be secured with MFA
Explanation:
The root user is created with the AWS account and has full access. It should be protected with a strong password and MFA and should not be used for routine administration.
Question 5:
A cloud engineer needs temporary credentials for delegated access. Which AWS service is commonly involved in issuing those credentials?
A. Amazon EC2
B. AWS Security Token Service
C. Amazon S3
D. AWS Organizations
Correct Answer:
B. AWS Security Token Service
Explanation:
AWS STS issues temporary security credentials, commonly used when assuming IAM roles.