IAM roles concept in AWS - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the AWS service that assumes the IAM role.

AWS

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"Service": "[1]"},
      "Action": "sts:AssumeRole"
    }
  ]
}

Drag options to blanks, or click blank then click option'

Aec2.amazonaws.com

Blambda.amazonaws.com

Cs3.amazonaws.com

Ddynamodb.amazonaws.com

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing EC2 service when the role is for Lambda.

Using S3 or DynamoDB as the principal service.

The Principal specifies which AWS service can assume the role. For AWS Lambda functions, it is lambda.amazonaws.com.

2fill in blank

medium

Complete the code to allow the role to perform the action of reading objects from S3.

AWS

{
  "Effect": "Allow",
  "Action": "s3:[1]",
  "Resource": "arn:aws:s3:::example-bucket/*"
}

Drag options to blanks, or click blank then click option'

AGetObject

BPutObject

CDeleteObject

DListBucket

Attempts:

3 left

💡 Hint

Common Mistakes

Using PutObject which is for uploading files.

Using ListBucket which is for listing bucket contents.

The GetObject action allows reading objects from an S3 bucket.

3fill in blank

hard

Fix the error in the trust policy by completing the missing action that allows role assumption.

AWS

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"Service": "ecs-tasks.amazonaws.com"},
      "Action": "sts:[1]"
    }
  ]
}

Drag options to blanks, or click blank then click option'

AAssumeRole

BPassRole

CGetRole

DCreateRole

Attempts:

3 left

💡 Hint

Common Mistakes

Using GetRole which only retrieves role details.

Using PassRole which is for passing roles to services.

The action sts:AssumeRole is required in the trust policy to allow the specified service to assume the role.

4fill in blank

hard

Fill both blanks to create a policy statement that allows listing all S3 buckets and reading objects from a specific bucket.

AWS

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:[1]", "s3:[2]"],
      "Resource": ["arn:aws:s3:::*", "arn:aws:s3:::example-bucket/*"]
    }
  ]
}

Drag options to blanks, or click blank then click option'

AListBucket

BGetObject

CPutObject

DDeleteBucket

Attempts:

3 left

💡 Hint

Common Mistakes

Using PutObject which is for uploading files.

Using DeleteBucket which is for deleting buckets.

ListBucket allows listing all buckets, and GetObject allows reading objects from the specified bucket.

5fill in blank

hard

Fill all three blanks to define a role trust policy that allows EC2 instances to assume the role with the correct action and service.

AWS

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "[1]",
      "Principal": {"Service": "[2]"},
      "Action": "sts:[3]"
    }
  ]
}

Drag options to blanks, or click blank then click option'

AAllow

Bec2.amazonaws.com

CAssumeRole

DDeny

Attempts:

3 left

💡 Hint

Common Mistakes

Using Deny as the effect.

Using the wrong service name.

Using incorrect STS action.

The trust policy must Allow the ec2.amazonaws.com service to perform the sts:AssumeRole action to assume the role.

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