SkarpSkarp

Chapter 5 of 26

Identity and Access Management Deep Dive: IAM Users, Groups, Roles, and Policies

Access design drives many SAA-C03 questions; walk through real-world IAM patterns so you can instantly recognize the right combination of users, groups, roles, and policies under exam pressure.

27 min readen

IAM in the Bigger Picture: Why It Dominates the Exam

Why IAM Matters

IAM controls who can do what, from where, and under which conditions in AWS. It appears in questions about S3, EC2, Lambda, Organizations, and more on the SAA exam.

IAM and Well-Architected

IAM is central to the Security pillar, which "describes how to take advantage of cloud technologies to protect data, systems, and assets in a way that can improve your security posture."

What You Will Learn

You will distinguish users, groups, roles, and policies; understand policy evaluation logic; design cross-account and app access; and read JSON policies for least privilege.

Shared Responsibility Link

Under the shared responsibility model, AWS secures the cloud; you secure in the cloud. IAM is your main lever to configure that security for your accounts and workloads.

IAM Building Blocks: Users, Groups, Roles, and Policies

IAM Users

IAM users represent people or apps that need long-term credentials in your account. They can have passwords and access keys, and receive permissions via identity-based policies.

IAM Groups

Groups are collections of IAM users. You attach policies to groups; users inherit them. You cannot log in as a group and groups do not have credentials.

IAM Roles

Roles are identities with permissions but no long-term credentials. They are assumed by users, services (EC2, Lambda, ECS), or federated identities and yield temporary STS credentials.

Policies

Policies are JSON documents that define allowed or denied actions on resources, usually via identity-based policies or resource-based policies with optional conditions.

Designing Human Access: Users, Groups, and Managed Policies

Scenario Overview

Startup: 2 admins (full access), 5 devs (dev-only EC2/S3), 10 analysts (read-only). They want centralized, maintainable access control in a single AWS account.

Group-Based Design

Create groups: `Admins`, `Developers`, `AnalystsReadOnly`. Attach `AdministratorAccess` to Admins, `ReadOnlyAccess` to Analysts, custom dev-only policy to Developers.

Why It’s Good

Groups scale better than per-user policies, AWS managed policies provide sensible baselines, custom managed policies handle dev scoping for least privilege.

Exam Traps

Watch for answers that give each user AdministratorAccess directly, use many inline policies, or create separate policies per user instead of shared managed policies.

IAM Roles and Temporary Credentials (STS) Deep Dive

Role Mechanics

A role has a trust policy (who can assume it) and permissions policies (what it can do). STS issues temporary credentials (access key, secret, token) when it is assumed.

Service Roles

Service roles let AWS services like EC2 or Lambda call other AWS APIs. Attach an EC2 role via an instance profile and use the SDK; never hard-code long-term keys.

Human and Federated Roles

Humans can assume roles (e.g., AdminRole) via Switch Role. Federated users from SSO/SAML/OIDC authenticate externally, then assume roles inside AWS without IAM users.

Exam Clues

Phrases like temporary access, avoid access keys, EC2 to S3, or cross-account usually point to an IAM role and STS-based solution, not new IAM users.

Policy JSON and Evaluation Logic: How AWS Decides Allow vs Deny

Policy Structure

Policies define Effect (Allow/Deny), Action (APIs), Resource (ARNs), and optional Condition (IP, tags, time, MFA). Default is implicit deny until an Allow applies.

Evaluation Basics

AWS combines identity-based and resource-based policies. If any explicit Deny matches, access is denied. If at least one Allow matches and no Deny, access is allowed.

Boundaries and SCPs

Permissions boundaries cap what a user/role can do. SCPs in AWS Organizations cap what accounts can do, even if IAM policies allow more.

Exam Troubleshooting

If a user "has permissions" but gets AccessDenied, look for explicit Deny in bucket policies, SCPs, or a permissions boundary blocking the action.

Reading and Fixing a Broken S3 Access Policy

Cross-Account S3 Goal

Account A role `AppRole` must read objects from an S3 bucket in Account B. Both a role policy and a bucket policy are involved.

Bucket Policy Attempt

Bucket policy allows Principal `arn:aws:iam::111122223333:role/AppRole` to call `s3:GetObject` on `arn:aws:s3:::shared-bucket/*`, but AccessDenied still occurs.

Debug Checklist

Check for typos in role ARN, explicit Deny via SCP, Region mismatch, incorrect resource ARN, or a broken trust policy preventing EC2 from assuming `AppRole`.

Exam Takeaway

For cross-account S3, both the role policy and the bucket policy must allow the action, and any explicit Deny in IAM, SCPs, or bucket policy overrides Allows.

Cross-Account Access Patterns with Roles and AWS Organizations

Cross-Account Role Pattern

Create a role in Account B with a trust policy that allows Account A to assume it via STS. Admins in Account A Switch Role to manage resources in Account B.

What SCPs Do

SCPs in AWS Organizations set the maximum permissions accounts can use. They do not grant permissions but can block actions even if IAM policies allow them.

Exam Scenarios

If actions are denied despite IAM allows, suspect an SCP. For central security or logging accounts, expect cross-account roles, not shared root or duplicated IAM users.

Key Mental Model

Use cross-account roles to move identities across accounts; use SCPs to put a permission ceiling on entire accounts or OUs across the organization.

Thought Exercise: Pick the Right Construct

For each scenario, decide which IAM construct(s) you would use. Think it through before revealing the guidance.

  1. Scenario A: A Lambda function in Account A must write to a DynamoDB table in the same account. You want to avoid managing any access keys.
  • What do you use?
  • Answer guide: Create an IAM role for Lambda with a policy allowing the necessary DynamoDB actions on that table. Configure the function to use this role. No IAM users or access keys needed.
  1. Scenario B: Contractors need 30-day, read-only console access to view CloudWatch Logs in an account. After 30 days, access should automatically expire.
  • What do you use?
  • Answer guide: Prefer federated access (e.g., external IdP) mapping to a read-only IAM role with a session duration and external lifecycle control. On the exam, if federation is not in the options, create IAM users in a `Contractors` group with `ReadOnlyAccess` and set password expiration / lifecycle controls.
  1. Scenario C: A central security account must be able to read CloudTrail logs stored in S3 buckets across 20 workload accounts.
  • What do you use?
  • Answer guide: In each workload account, create a role with S3 read permissions on its log bucket and a trust policy allowing the security account to assume it. Optionally, use an S3 bucket policy with `aws:PrincipalOrgID` to restrict to your organization.

Reflect: In all three, roles are preferred for workloads and cross-account access; users/groups are mainly for direct human access when federation is not available.

Quiz 1: Users, Groups, or Roles?

Check your understanding of when to use users, groups, and roles.

A company runs an EC2-based application that needs to read from an S3 bucket in the same account. Security requires that no long-term access keys are stored on the instance. What is the MOST appropriate solution?

  1. Create an IAM user with an access key, store it on the EC2 instance, and attach a policy allowing s3:GetObject on the bucket.
  2. Attach a custom bucket policy allowing any principal in the account to read from the bucket, and do not use IAM.
  3. Create an IAM role for EC2 with a policy allowing s3:GetObject on the bucket, and attach it to the instance via an instance profile.
  4. Create an IAM group with S3 read permissions and add the EC2 instance to the group.
Show Answer

Answer: C) Create an IAM role for EC2 with a policy allowing s3:GetObject on the bucket, and attach it to the instance via an instance profile.

You should use an **IAM role for EC2** with the required S3 permissions and attach it as an instance profile. This provides temporary credentials via STS and avoids long-term access keys. EC2 instances cannot be added to IAM groups, and granting bucket access to all principals is overly permissive.

Quiz 2: Policy Evaluation and SCPs

Test your understanding of how IAM policies and SCPs interact.

An IAM user has an identity-based policy that allows `ec2:TerminateInstances` on all instances. The account belongs to an OU with an SCP that denies `ec2:TerminateInstances`. What happens when the user tries to terminate an instance?

  1. The request is allowed because IAM identity-based policies override SCPs.
  2. The request is denied because the SCP's explicit Deny overrides the Allow in the IAM policy.
  3. The request is allowed only if the user is a member of the Administrators group.
  4. The request is allowed, but a warning is logged in CloudTrail.
Show Answer

Answer: B) The request is denied because the SCP's explicit Deny overrides the Allow in the IAM policy.

SCPs define the maximum permissions available in an account. An explicit Deny in an SCP overrides any Allow in IAM identity-based or resource-based policies. Therefore, the terminate request is denied.

Key IAM Concepts Review

Flip these cards to reinforce your recall of core IAM terms and patterns.

IAM user
An identity in AWS that represents a person or application needing long-term credentials in a single account. Can have a console password and/or access keys, and receives permissions via identity-based policies.
IAM group
A collection of IAM users. You attach policies to the group, and all members inherit them. Groups cannot be logged into and do not have their own credentials.
IAM role
An AWS identity with permissions but no long-term credentials. Assumed by users, AWS services, or federated identities to obtain temporary STS credentials.
Identity-based policy
A JSON policy attached to a user, group, or role that specifies what actions are allowed or denied on which resources, optionally under certain conditions.
Resource-based policy
A policy attached directly to a resource like an S3 bucket or KMS key. Specifies which principals can access the resource and what actions they can perform.
Explicit Deny
A policy statement with Effect set to Deny. If it matches a request, it overrides any Allow in other policies, causing the request to be denied.
Permissions boundary
An advanced IAM feature that sets the maximum permissions a user or role can have. The effective permissions are the intersection of the identity-based policy and the boundary.
Service Control Policy (SCP)
An AWS Organizations policy type that defines the maximum permissions for accounts in an organization or OU. It does not grant permissions but can restrict them, even for the root user.
Service role (e.g., role for EC2 or Lambda)
A role that an AWS service assumes to perform actions on your behalf. Provides temporary credentials to the service instead of using access keys.
Federated access
A method where users authenticate with an external identity provider (such as SAML or OIDC) and then assume a role in AWS without having individual IAM users.

Bringing It Together: IAM Design Patterns for the Exam

Humans vs Apps

Humans: prefer federation + roles, or IAM users in groups with managed policies. Apps: always think service roles with least privilege, not long-term access keys.

Cross-Account Patterns

Use assumable roles with trust policies for cross-account access. In orgs, combine Organizations + SCPs + cross-account roles for centralized control.

Troubleshooting Mindset

On AccessDenied, check identity policies, resource policies, explicit Deny, permissions boundaries, and SCPs. Explicit Deny anywhere overrides Allows.

Exam Strategy

Map each scenario to these patterns quickly. Your upcoming Skarp diagnostics and mocks will surface which IAM areas you should reinforce in spaced review.

Key Terms

IAM role
An AWS identity with permissions but no long-term credentials. Assumed by users, AWS services, or federated identities to obtain temporary STS credentials.
IAM user
An identity in AWS that represents a person or application needing long-term credentials in a single account. Can have a console password and/or access keys, and receives permissions via identity-based policies.
IAM group
A collection of IAM users. You attach policies to the group, and all members inherit them. Groups cannot be logged into and do not have their own credentials.
Service role
An IAM role that an AWS service assumes to perform actions on your behalf, such as an EC2 role or Lambda execution role.
Federated access
A method where users authenticate with an external identity provider (such as SAML or OIDC) and then assume a role in AWS without having individual IAM users.
Instance profile
A container for an IAM role that you can attach to an EC2 instance to provide temporary credentials to applications running on the instance.
Permissions boundary
An advanced IAM feature that sets the maximum permissions a user or role can have. The effective permissions are the intersection of the identity-based policy and the boundary.
Identity-based policy
A JSON policy attached to a user, group, or role that specifies what actions are allowed or denied on which resources, optionally under certain conditions.
Resource-based policy
A policy attached directly to a resource like an S3 bucket or KMS key. Specifies which principals can access the resource and what actions they can perform.
Service Control Policy (SCP)
An AWS Organizations policy type that defines the maximum permissions for accounts in an organization or OU. It does not grant permissions but can restrict them, even for the root user.
AWS STS (Security Token Service)
A web service that enables you to request temporary, limited-privilege credentials for IAM users or federated users, often when assuming roles.

Finished reading?

Test your understanding with a custom practice exam on this chapter.

Test yourself