Quiz - What Best Describes an IAM Role?

What best describes an IAM role?A) A role is a policy that is applied directly to an AWS resource, such as an EC2 instance.B) A role is used when configuring multi-factor authentication.C) A role is something that another entity can "assume."D) A role is how you manage user access to AWS resources.What is the correct answer? Keep reading to find out if you got it right! 

What is an IAM Role?

A role is an AWS identity that another entity can assume, where the entity is another AWS resource (like an EC2 instance) or even an IAM User. AWS resources cannot have permission policies directly applied to them. To receive permissions, the resources must "assume" a role which then gives them permissions that are assigned to that role through policies.This might sound similar to IAM users, but there are some differences. One main difference is that users are meant to be associated with a unique person, whereas roles can be assumed by anyone or anything that needs them.Another main difference is that roles do not have credentials (password or access keys) associated with them. When a role is assumed, credentials are automatically and dynamically generated so you don't have to worry about it. This is very beneficial, especially if you would have to otherwise hardcode credentials.

Use Cases

All of this makes roles ideal for use cases like these:

• Providing access from one of your AWS resources (ie: EC2 instances) to another (ie: Amazon S3).
• Giving access to an AWS IAM user in one of your accounts to another one of your accounts, so they can easily switch roles to the second account instead of having to sign in through another user.
• Granting access through identity federation to externally authenticated users (i.e. users authenticated through a mobile or web-based application).
• Providing controlled access to third-party tools for monitoring or anything else like that.

Creating an IAM Role

To create a role, you can go to IAM > Roles in the AWS console. You can also generate roles through the CLI or SDK.

1. Select a Role Type

This determines whether the role can be used by a service, like EC2, or if it can be used to grant cross-account access, for example.

2. Select a Policy

This step depends on the role type you chose, but if you selected a service role then it is time to select permissions you want to associate with the role.For example, if you want this role to be assumed by EC2 instances, you would have selected that role type. But now, what permissions should those EC2 instances have once they assume the role? Do you want to give full access to S3? Read-only access? Should they have access to view your RDS resources? Policies let you choose which of these permissions will be associated with the role.Note, Step 2 could instead be to "establish trust" if you selected a type other than "service role." For example, if you want to allow cross-account access, you will need to provide the other account's ID and whether you want to require multi-factor authentication or not. To give another example, if you wish to grant Web Single Sign-On (WebSSO) access to SAML providers, you will need to create or select a SAML provider and set conditions during this step.

3. Set a Role Name & Review

Once you create the role, it can then serve its purpose. If you created an EC2 service role, you can now go spin up an instance and assign that role to the instance for it to benefit from its newfound permissions!

Drumroll...

All of this to say that......the answer is C!

---