IAM roles concept in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding IAM Role Trust Policies

Which statement best describes the purpose of the trust policy in an AWS IAM role?

A It defines which AWS services or users can assume the role.

B It specifies the permissions granted to the role for accessing AWS resources.

C It encrypts the role's credentials to enhance security.

D It logs all actions performed by the role for auditing.

💡 Hint

Think about who is allowed to use the role, not what the role can do.

The trust policy defines the entities (users, services, accounts) that are allowed to assume the IAM role. Permissions granted to the role are defined separately in permission policies.

❓ service_behavior

intermediate

Role Assumption Behavior

What happens when an AWS Lambda function assumes an IAM role with limited permissions?

A The Lambda function can perform any action in AWS regardless of the role's permissions.

B The Lambda function ignores the role's permissions and uses the account root permissions.

C The Lambda function can perform only the actions allowed by the role's permissions.

D The Lambda function cannot access AWS resources unless explicitly granted permissions in its code.

💡 Hint

Consider how roles limit what a service can do.

When a Lambda function assumes an IAM role, it inherits only the permissions granted by that role. It cannot exceed those permissions.

❓ Architecture

advanced

Cross-Account Access Using IAM Roles

You want an EC2 instance in Account A to access an S3 bucket in Account B securely. Which setup correctly enables this using IAM roles?

A Create an IAM role in Account A with permissions to access the S3 bucket in Account B without any trust policy in Account B.

B Create an IAM role in Account B with permissions to access the S3 bucket and a trust policy allowing Account A's EC2 instance to assume it. Then configure the EC2 instance to assume this role.

C Create an IAM user in Account B with S3 access and share its access keys with the EC2 instance in Account A.

D Attach an IAM role with S3 access directly to the EC2 instance in Account A without any trust policy changes.

💡 Hint

Think about how trust policies enable cross-account role assumption.

Cross-account access requires a role in the target account (Account B) with a trust policy that allows the source account (Account A) to assume it. Sharing access keys or roles without trust policies does not work securely.

❓ security

advanced

Least Privilege Principle with IAM Roles

You have an IAM role used by an application that only needs to read data from DynamoDB. Which policy best follows the least privilege principle?

A A policy granting only the dynamodb:GetItem and dynamodb:Query actions on the specific DynamoDB table.

B A policy granting full access to all DynamoDB actions on all tables.

C A policy granting read and write permissions on all DynamoDB tables.

D A policy granting only the dynamodb:Scan action on all DynamoDB tables.

💡 Hint

Least privilege means giving only the exact permissions needed.

Granting only the necessary read actions on the specific table limits risk and follows best security practices.

✅ Best Practice

expert

Automating Temporary Credentials with IAM Roles

You want to automate a process that runs on an on-premises server and needs temporary AWS credentials with limited permissions. Which approach follows AWS best practices?

A Use the root account credentials to authenticate the on-premises server for full access.

B Create an IAM user with long-term access keys and embed them in the on-premises server configuration.

C Manually generate IAM user credentials daily and update the on-premises server configuration.

D Use AWS Security Token Service (STS) to assume an IAM role with limited permissions and retrieve temporary credentials programmatically.

💡 Hint

Think about temporary credentials and automation without long-term keys.

Using STS to assume roles and get temporary credentials is secure and avoids long-term keys on servers.

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