IAM roles concept in AWS - Step-by-Step Execution

Process Flow - IAM roles concept

User or Service Requests Access

↓

Assume IAM Role

↓

Temporary Credentials Issued

↓

Access AWS Resources with Permissions

↓

Access Complete

This flow shows how a user or service requests access by assuming an IAM role, receives temporary credentials, and then accesses AWS resources with the permissions granted by that role.

Execution Sample

AWS

1. User calls AssumeRole API
2. AWS returns temporary credentials
3. User uses credentials to access S3 bucket
4. Access allowed or denied based on role permissions

This example shows how a user assumes an IAM role to get temporary credentials and then accesses an AWS S3 bucket using those credentials.

Process Table

Step	Action	Input	Output	Result
1	User requests to assume role	Role ARN	Temporary credentials request	Request sent to AWS STS
2	AWS STS validates request	Role ARN, User identity	Temporary credentials (AccessKeyId, SecretAccessKey, SessionToken)	Credentials issued with limited duration
3	User uses temporary credentials	Temporary credentials	API call to S3 bucket	Request authenticated with role permissions
4	S3 evaluates permissions	Role permissions, bucket policy	Allow or Deny	Access granted or denied
5	User completes operation	N/A	N/A	Access complete or error returned

💡 Process ends after user completes access or is denied based on role permissions

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
User Identity	User credentials	Request to assume role	Validated by STS	Uses temporary credentials	Access granted or denied
Temporary Credentials	None	Requested	Issued by STS	Used for API calls	Expired after duration

Key Moments - 3 Insights

Why does the user need to assume a role instead of using their own credentials?

Because the role provides temporary credentials with specific permissions, limiting access scope and duration, as shown in execution_table step 2 and 3.

What happens if the role permissions do not allow access to the resource?

The access is denied at step 4 when S3 evaluates permissions, resulting in an error returned to the user.

Are the temporary credentials permanent?

No, they are temporary and expire after a set duration, as tracked in variable_tracker under Temporary Credentials.

Visual Quiz - 3 Questions

Look at the execution_table, what is issued by AWS STS at step 2?

A Temporary credentials with limited duration

B Permanent user credentials

C Access denied message

D Role ARN

💡 Hint

Check the Output column in execution_table row 2

At which step does the S3 bucket decide to allow or deny access?

A Step 1

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the Action and Result columns in execution_table row 4

If the temporary credentials expire, what happens to the user's access?

A Access continues without interruption

B User must request new temporary credentials

C User can use original credentials instead

D Access is permanently revoked

💡 Hint

See variable_tracker row for Temporary Credentials and their expiration

Concept Snapshot

IAM Roles let users or services get temporary credentials.
They assume a role to get these credentials.
Temporary credentials have limited permissions and duration.
Use these credentials to access AWS resources securely.
Access is controlled by the role's permissions and resource policies.

Full Transcript

IAM roles allow users or services to request temporary access to AWS resources. The process starts when a user or service requests to assume a role by providing the role's ARN. AWS Security Token Service (STS) validates this request and issues temporary credentials with limited permissions and a set expiration time. The user then uses these temporary credentials to make API calls to AWS services like S3. The service evaluates the permissions associated with the role and the resource policies to allow or deny access. This approach enhances security by limiting access scope and duration. Temporary credentials expire after their duration, requiring the user to assume the role again to continue access.

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