IAM roles concept in AWS - Mini Project: Build & Apply

IAM Roles Concept

📖 Scenario: You are setting up permissions for an AWS Lambda function to access an S3 bucket securely. To do this, you need to create an IAM role that the Lambda function can assume. This role will have a policy attached that allows reading objects from the S3 bucket.

🎯 Goal: Create an IAM role with a trust policy for Lambda service, attach a permission policy to allow reading from a specific S3 bucket, and configure the Lambda function to use this role.

📋 What You'll Learn

Create an IAM role named LambdaS3ReadRole with a trust policy allowing Lambda service to assume it.

Create an inline policy named S3ReadPolicy that allows s3:GetObject on the bucket example-bucket.

Attach the S3ReadPolicy inline policy to the LambdaS3ReadRole role.

Configure a Lambda function named MyLambdaFunction to use the LambdaS3ReadRole role.

💡 Why This Matters

🌍 Real World

IAM roles are essential for securely granting AWS services permissions to access other AWS resources without sharing long-term credentials.

💼 Career

Understanding IAM roles and policies is critical for cloud engineers and developers to implement secure and least-privilege access in AWS environments.

1

Create IAM Role with Trust Policy

Create an IAM role named LambdaS3ReadRole with a trust policy that allows the Lambda service (lambda.amazonaws.com) to assume this role. Use the AWS CLI JSON format for the trust policy document.

AWS

# Your code here to create the IAM role LambdaS3ReadRole with trust policy

Hint

The trust policy must allow the Lambda service to assume the role using sts:AssumeRole.

2

Create Inline Policy for S3 Read Access

Create an inline policy named S3ReadPolicy that allows the action s3:GetObject on the resource arn:aws:s3:::example-bucket/*. Use the AWS CLI JSON format for the policy document.

AWS

aws iam create-role --role-name LambdaS3ReadRole --assume-role-policy-document '{"Version": "2012-10-17", "Statement": [{"Effect": "Allow", "Principal": {"Service": "lambda.amazonaws.com"}, "Action": "sts:AssumeRole"}]}'
# Your code here to create the inline policy S3ReadPolicy

Hint

The inline policy must allow s3:GetObject on all objects in example-bucket.

3

Attach Inline Policy to IAM Role

Attach the inline policy S3ReadPolicy to the IAM role LambdaS3ReadRole. (This is done in step 2 with put-role-policy, so no new command is needed here. Just confirm the policy is attached.)

AWS

aws iam create-role --role-name LambdaS3ReadRole --assume-role-policy-document '{"Version": "2012-10-17", "Statement": [{"Effect": "Allow", "Principal": {"Service": "lambda.amazonaws.com"}, "Action": "sts:AssumeRole"}]}'
aws iam put-role-policy --role-name LambdaS3ReadRole --policy-name S3ReadPolicy --policy-document '{"Version": "2012-10-17", "Statement": [{"Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::example-bucket/*"}]}'
# Confirm the inline policy is attached (no new code needed)

Hint

The inline policy is attached using put-role-policy in step 2, so no new command is needed here.

4

Configure Lambda Function to Use IAM Role

Create a Lambda function named MyLambdaFunction and configure it to use the IAM role LambdaS3ReadRole. Use the AWS CLI command to create the function with the role ARN. Assume the deployment package is function.zip and the handler is index.handler with runtime python3.12.

AWS

aws iam create-role --role-name LambdaS3ReadRole --assume-role-policy-document '{"Version": "2012-10-17", "Statement": [{"Effect": "Allow", "Principal": {"Service": "lambda.amazonaws.com"}, "Action": "sts:AssumeRole"}]}'
aws iam put-role-policy --role-name LambdaS3ReadRole --policy-name S3ReadPolicy --policy-document '{"Version": "2012-10-17", "Statement": [{"Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::example-bucket/*"}]}'
# Your code here to create MyLambdaFunction with role LambdaS3ReadRole

Hint

Use the full ARN of the role LambdaS3ReadRole in the --role parameter. Replace 123456789012 with your AWS account ID.

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