SkarpChapter 3 of 26
Identity and Access Management Deep Dive: IAM Users, Groups, Policies, and Roles
Misconfigured access is one of the fastest ways to fail both the exam and a real audit. In this module, you’ll dissect IAM building blocks and practice designing secure, least-privilege access patterns that match the exam’s most common scenarios.
IAM in the Big Picture: Shared Responsibility and Exam Lens
IAM and Shared Responsibility
IAM design lives squarely on the customer side of the shared responsibility model: AWS secures the IAM service, you configure identities, roles, and policies correctly.
Security Pillar Connection
The Security pillar says how to use cloud tech to protect data, systems, and assets. IAM is the main way you control who can do what in your AWS environment.
Exam Lens on IAM
On SAA-C03, IAM questions are often embedded in scenarios. You must pick between users, roles, and resource-based policies, while enforcing least privilege and operational simplicity.
Security of vs in the Cloud
AWS handles security of the cloud (e.g., IAM infrastructure). You handle security in the cloud: IAM policies, user management, and resource access configurations.
IAM Building Blocks: Users, Groups, Policies, and Roles
IAM Users
IAM users represent a person or app that needs long-term credentials. They can have passwords and access keys, but for humans the exam expects you to prefer SSO or federation over raw IAM users.
IAM Groups
Groups are collections of users. Attach policies to groups instead of users to keep management simple. A user’s effective permissions are the union of all group policies.
IAM Policies
Policies are JSON documents that allow or deny actions on resources. They can attach to users, groups, roles (identity-based) or to resources like S3 buckets (resource-based).
IAM Roles
Roles are identities without long-term credentials. Trusted principals assume roles to get temporary credentials via STS. Roles are key for services, cross-account, and just-in-time access.
Common Exam Trap
Exam trap: picking a user when a role is safer. For apps, cross-account access, and temporary access, choose roles. Reserve users for rare cases needing long-lived IAM identities.
Identity-Based vs Resource-Based Policies and Evaluation Logic
Identity-Based Policies
Identity-based policies attach to users, groups, or roles. They answer: "What can this identity do?" For example, an EC2 role allowed to read from a specific S3 bucket.
Resource-Based Policies
Resource-based policies attach directly to resources like S3 buckets or SQS queues. They answer: "Who can access this resource, and how?" and are great for cross-account access.
Evaluation Order
IAM evaluation: start with implicit deny, then explicit deny (wins), then explicit allow. If no explicit allow is found, the final result is deny.
Combining Policies
When both identity and resource policies apply, both must allow the action. Any explicit deny in either policy overrides all allows.
Exam Pattern
If a question mentions another AWS account accessing your S3 bucket, expect a resource-based policy on the bucket plus a role in the other account, not shared access keys.
Designing a Least-Privilege IAM Policy (Step by Step)
Scenario Setup
Analytics users must list objects in `analytics-reports` and read only from the `2025/` prefix. They must not upload or delete anything. You need a least-privilege policy.
Identify Actions and Resources
Actions: `s3:ListBucket` on the bucket, `s3:GetObject` on objects. Resources: `arn:aws:s3:::analytics-reports` and `arn:aws:s3:::analytics-reports/2025/*`.
Policy JSON
The policy allows just listing the bucket and getting objects under `2025/`. It attaches to a group `AnalyticsReaders` so you avoid per-user policies.
Why Least Privilege
No wildcard `s3:*`, scope is a single bucket and prefix, and there are no write or delete permissions. On the exam, broader wildcards are often wrong even if they function.
IAM Roles and AWS STS: Temporary Credentials and Trust Policies
Role Components
A role has three key pieces: a trust policy (who can assume it), a permissions policy (what it can do), and a session duration (how long temporary credentials last).
STS Basics
AWS STS issues temporary credentials. The key API is `AssumeRole`, used when a user, service, or external identity needs to take on a role’s permissions.
Service Role Example
For EC2 to access S3, the role’s trust policy lists `ec2.amazonaws.com` as the service principal for `sts:AssumeRole`. The permissions policy then grants specific S3 actions.
Exam Signal: Temporary Access
If a scenario mentions apps on EC2/Lambda or temporary access, the safe, expected answer is an IAM role with least-privilege permissions, not static access keys.
Cross-Account Access with Roles vs Resource-Based Policies
Cross-Account S3 Access
For EC2 in Account A to read an S3 bucket in Account B, use a role on EC2 plus a bucket policy in B that allows that role’s ARN to `s3:GetObject`.
Bucket Policy Example
The bucket policy’s Principal is the role ARN from Account A. The Action is `s3:GetObject` and the Resource is the bucket’s object ARN with `/*`.
Cross-Account Console Access
For admins in Account A to manage Account B, create a role in B with a trust policy allowing `sts:AssumeRole` from A. Admins then switch role in the console.
Exam Decision Guide
Use resource-based policies plus roles for services across accounts, and cross-account roles for human admins. Avoid sharing access keys or duplicating users across accounts.
Thought Exercise: Choosing Users, Roles, or Resource Policies
Work through these scenarios and decide which IAM construct is the best fit. Think like the exam: prioritize security, least privilege, and operational simplicity.
- Scenario A
A reporting application runs on EC2 in your account. It needs to write logs to a private S3 bucket in the same account. The app currently uses hard-coded access keys.
- What is the best change to make?
- Why is that more secure and easier to manage?
- Scenario B
A third-party billing system in another AWS account needs read-only access to an SQS queue in your account.
- Would you create an IAM user with access keys in your account and share them, or use a different pattern?
- Which resource supports a resource-based policy here?
- Scenario C
Your company has 10 AWS accounts. Security engineers in the central security account need to view CloudWatch logs in all other accounts, but you want to avoid creating separate IAM users for each account.
- How would you design this with roles?
- Where do you configure trust vs permissions?
Pause and sketch your answers. Then compare to the guidance:
- Scenario A: Replace access keys with an EC2 instance role that has an S3 write policy.
- Scenario B: Use an SQS queue policy (resource-based) that allows the other account’s role to read messages.
- Scenario C: Create cross-account roles in each workload account that trust the security account; security engineers assume those roles when needed.
Quick Check: Shared Responsibility and IAM Constructs
Test your understanding of the shared responsibility model and basic IAM choices.
Which option best aligns with the AWS shared responsibility model and IAM best practices for an application running on EC2 that needs to access DynamoDB?
- Create an IAM user with full DynamoDB access, generate access keys, and store them in the EC2 instance user data.
- Attach an IAM role to the EC2 instance with least-privilege permissions for only the required DynamoDB tables.
- Use the root user credentials for the account and store them in an encrypted file on the EC2 instance.
- Create a resource-based policy on DynamoDB to allow anonymous access from any principal.
Show Answer
Answer: B) Attach an IAM role to the EC2 instance with least-privilege permissions for only the required DynamoDB tables.
Under the shared responsibility model, you are responsible for security in the cloud, including IAM configuration. For EC2 applications, the best practice is to attach an IAM role with least-privilege permissions. Storing long-term access keys on instances (or using root credentials) is insecure, and DynamoDB does not support anonymous access via resource-based policies for this use case.
Quick Check: Identity-Based vs Resource-Based Policies
Test your ability to choose between identity-based and resource-based policies.
A partner company in a different AWS account needs read-only access to objects in a specific S3 bucket in your account. You want to avoid managing their users. What is the MOST appropriate design?
- Create IAM users for each partner engineer in your account and attach an S3 read-only policy.
- Ask the partner to share their IAM user access keys and add them to your credential manager.
- Use an S3 bucket policy that grants s3:GetObject permission to an IAM role in the partner's account.
- Enable public read access on the S3 bucket using a bucket policy.
Show Answer
Answer: C) Use an S3 bucket policy that grants s3:GetObject permission to an IAM role in the partner's account.
The best pattern is to keep identities in the partner's account and grant access via a resource-based policy on your S3 bucket that references an IAM role in the partner's account. Creating users in your account or sharing access keys is hard to manage and less secure. Public read access violates least privilege.
Key IAM and Security Model Terms
Flip through these cards to reinforce core IAM and security model concepts before moving on.
- AWS shared responsibility model
- The AWS shared responsibility model describes how AWS is responsible for security of the cloud, while customers are responsible for security in the cloud, including the configuration of their services and data.
- IAM user
- A long-term identity in IAM representing a person or application. It can have a console password and/or access keys. Best practice is to minimize direct IAM users for humans and prefer federation.
- IAM group
- A collection of IAM users. Policies attached to a group apply to all members, simplifying permission management and supporting least privilege via roles-based groupings.
- IAM role
- An IAM identity with no long-term credentials that can be assumed by trusted principals to obtain temporary security credentials via AWS STS. Used for services, cross-account access, and temporary access.
- Identity-based policy
- A policy attached to a user, group, or role that specifies what actions that identity is allowed or denied to perform on which resources.
- Resource-based policy
- A policy attached directly to a resource (such as an S3 bucket or SQS queue) that specifies which principals are allowed or denied to access the resource and how.
- Explicit deny vs implicit deny
- IAM denies access by default (implicit deny). An explicit deny in any applicable policy overrides all allows. An explicit allow only works if there is no explicit deny.
- AWS STS
- AWS Security Token Service, which issues temporary security credentials (access key, secret key, session token) when principals call APIs such as AssumeRole.
Putting It Together: Evaluating Exam Scenarios Efficiently
Step 1: Who Is the Principal?
Is it a human, an app on EC2/Lambda, or an external account? This choice often decides whether you should use a user, a role, or a resource-based policy plus role.
Step 2: What Resource, What Pattern?
Identify the AWS service, whether access is same-account or cross-account, and whether it is temporary or long-term. That shapes your IAM design.
Step 3: Map to Constructs
Humans: SSO/federation + roles. Apps: service roles. Cross-account access to S3/SQS/SNS/Lambda/KMS: resource-based policies plus roles, not shared keys.
Step 4: Least Privilege
Narrow actions and resources, and use conditions when possible. Avoid wildcards that grant more access than the scenario requires.
Step 5: Responsibility Check
Confirm your design respects the shared responsibility model: you manage IAM and configurations correctly, while AWS secures the underlying services.
Key Terms
- AWS STS
- AWS Security Token Service, which issues temporary security credentials when APIs such as AssumeRole are called.
- IAM role
- An IAM identity with no long-term credentials that trusted principals can assume to obtain temporary security credentials via AWS STS.
- IAM user
- A long-term IAM identity representing a person or application, with optional console password and access keys. Best practice is to minimize direct IAM users for humans and prefer federation.
- IAM group
- A collection of IAM users. Policies attached to the group apply to all members, simplifying permission management.
- Explicit deny
- An IAM policy statement with Effect set to Deny. It overrides any allow statements.
- Implicit deny
- The default in IAM. If an action is not explicitly allowed, it is denied.
- Least privilege
- A security principle where identities are granted only the minimum permissions they need to perform their tasks, and no more.
- Identity-based policy
- A policy attached to a user, group, or role that specifies what that identity is allowed or denied to do.
- Resource-based policy
- A policy attached directly to a resource (for example, S3 bucket, SQS queue, KMS key) that specifies which principals can access it and how.
- AWS shared responsibility model
- The AWS shared responsibility model describes how AWS is responsible for security of the cloud, while customers are responsible for security in the cloud, including the configuration of their services and data.