Why IAM roles concept in AWS? - Purpose & Use Cases

The Big Idea

What if you could give access without ever sharing a password?

The Scenario

Imagine you have many people and apps needing access to your cloud resources, and you give each one a username and password manually.

Every time someone new joins or leaves, you must update all permissions by hand.

The Problem

This manual way is slow and confusing.

Passwords can be lost or shared by mistake, causing security risks.

It's easy to give too many permissions or forget to remove them, leading to mistakes and breaches.

The Solution

IAM roles let you create a set of permissions once and let trusted users or apps temporarily 'assume' these permissions without sharing passwords.

This makes access safe, easy to manage, and automatic.

Before vs After

✗ Before

Create user with password
Assign permissions manually
Share password with app

✓ After

Create IAM role with permissions
Allow app to assume role
No passwords shared

What It Enables

You can securely and easily control who can do what in your cloud without juggling passwords or manual updates.

Real Life Example

A mobile app needs to upload photos to cloud storage. Instead of embedding passwords, it assumes an IAM role with upload rights only when needed.

Key Takeaways

Manual user management is slow and risky.

IAM roles provide safe, temporary access without passwords.

This simplifies security and saves time.

Practice

1. What is the main purpose of an IAM role in AWS?

easy

A. To monitor network traffic

B. To store user passwords securely

C. To create virtual machines

D. To grant permissions to entities without sharing long-term credentials

Solution

1. Step 1: Understand IAM role purpose

   An IAM role allows AWS entities to assume permissions temporarily without needing permanent credentials like passwords.

2. Step 2: Compare options

   Only To grant permissions to entities without sharing long-term credentials correctly describes this purpose. Options B, C, and D describe unrelated AWS features.

3. Final Answer:

   To grant permissions to entities without sharing long-term credentials -> Option D

4. Quick Check:

   IAM roles = temporary permissions without passwords [OK]

Hint: Roles give permissions without passwords or keys [OK]

Common Mistakes:

• Confusing roles with user accounts
• Thinking roles store passwords
• Mixing roles with AWS services like EC2

2. Which of the following is the correct way to specify a trust policy for an IAM role?

easy

A. { "Statement": [{ "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "iam:PassRole" }] }

B. { "Statement": [{ "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" }] }

C. { "Statement": [{ "Effect": "Allow", "Principal": { "User": "admin" }, "Action": "iam:CreateUser" }] }

D. { "Statement": [{ "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "sts:AssumeRole" }] }

Solution

1. Step 1: Identify trust policy structure

   A trust policy allows a trusted entity (like EC2) to assume the role using sts:AssumeRole action.

2. Step 2: Check each option

   { "Statement": [{ "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" }] } correctly allows EC2 service to assume the role. { "Statement": [{ "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "sts:AssumeRole" }] } denies all, which is invalid for trust. { "Statement": [{ "Effect": "Allow", "Principal": { "User": "admin" }, "Action": "iam:CreateUser" }] } uses wrong action and principal. { "Statement": [{ "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "iam:PassRole" }] } uses wrong action (iam:PassRole) for trust.

3. Final Answer:

   { "Statement": [{ "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" }] } -> Option B

4. Quick Check:

   Trust policy must allow sts:AssumeRole to a service [OK]

Hint: Trust policy uses sts:AssumeRole with service principal [OK]

Common Mistakes:

• Using iam:PassRole instead of sts:AssumeRole
• Denying all principals in trust policy
• Specifying user instead of service in Principal

3. Given this IAM role trust policy snippet:

{ "Statement": [{ "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" }] }

Which AWS service can assume this role?

medium

A. AWS Lambda functions

B. Amazon EC2 instances

C. Amazon S3 buckets

D. AWS IAM users

Solution

1. Step 1: Read the Principal service

   The Principal is "lambda.amazonaws.com", which means AWS Lambda service is trusted.

2. Step 2: Match service to options

   AWS Lambda functions matches AWS Lambda functions. EC2, S3, and IAM users are different entities and not trusted here.

3. Final Answer:

   AWS Lambda functions -> Option A

4. Quick Check:

   Principal service = lambda.amazonaws.com means Lambda [OK]

Hint: Principal service name shows who can assume role [OK]

Common Mistakes:

• Confusing service names like ec2.amazonaws.com vs lambda.amazonaws.com
• Thinking S3 buckets can assume roles
• Assuming IAM users are trusted by default

4. You created an IAM role with this trust policy:

{ "Statement": [{ "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "iam:PassRole" }] }

Why can't EC2 instances assume this role?

medium

A. Because the Effect should be Deny

B. Because the Principal service is incorrect

C. Because the action should be sts:AssumeRole, not iam:PassRole

D. Because EC2 instances cannot assume roles

Solution

1. Step 1: Identify the required action in trust policy

   The trust policy must allow the action sts:AssumeRole for the trusted entity to assume the role.

2. Step 2: Analyze the given policy

   The policy uses iam:PassRole, which is incorrect for trust. This prevents EC2 from assuming the role.

3. Final Answer:

   Because the action should be sts:AssumeRole, not iam:PassRole -> Option C

4. Quick Check:

   Trust policy action must be sts:AssumeRole [OK]

Hint: Trust policy action must be sts:AssumeRole [OK]

Common Mistakes:

• Using iam:PassRole instead of sts:AssumeRole
• Changing Effect to Deny by mistake
• Believing EC2 cannot assume roles

5. You want to allow an AWS Lambda function to assume an IAM role that grants access to S3 buckets. Which two policies must you configure correctly to make this work?

hard

A. A trust policy allowing lambda.amazonaws.com to assume the role and an IAM permissions policy granting S3 access

B. A trust policy allowing s3.amazonaws.com to assume the role and an IAM permissions policy granting Lambda execution

C. An IAM user policy granting Lambda permissions and a trust policy allowing EC2 to assume the role

D. A permissions policy granting S3 access and a trust policy denying all principals

Solution

1. Step 1: Identify trust policy requirements

   The trust policy must allow the Lambda service (lambda.amazonaws.com) to assume the role.

2. Step 2: Identify permissions policy requirements

   The role's permissions policy must grant access to S3 buckets for the Lambda function.

3. Step 3: Evaluate options

   A trust policy allowing lambda.amazonaws.com to assume the role and an IAM permissions policy granting S3 access correctly pairs the trust policy for Lambda and permissions for S3. Other options have incorrect principals or deny access.

4. Final Answer:

   A trust policy allowing lambda.amazonaws.com to assume the role and an IAM permissions policy granting S3 access -> Option A

5. Quick Check:

   Trust policy + permissions policy = role works [OK]

Hint: Trust policy for who assumes; permissions policy for what they can do [OK]

Common Mistakes:

• Allowing wrong service in trust policy
• Confusing permissions policy with trust policy
• Denying all principals in trust policy