Study guide

Technical reference and lesson notes

AWS IAM Deep Dive: Principals, Authentication, Authorization, Users, Groups, and Roles

Purpose of This Lesson

This lesson explains how AWS Identity and Access Management (AWS IAM) controls access to AWS resources. The key workflow is to identify the principal making a request, authenticate that principal, evaluate applicable policies, and then allow or deny the requested action.

The material is especially relevant to AWS Certified CloudOps Engineer Associate SOA-C03 scenarios involving console access, programmatic access, application permissions, users, groups, and roles.

Key Concepts

Principals

A principal is a person or application that can request an action on an AWS resource. Examples include:

An IAM user uploading an object to Amazon S3.
An application launching an Amazon EC2 instance.
An authenticated identity deleting an Amazon RDS database.
A federated user accessing AWS resources.

Most principals must be authenticated before AWS processes their requests.

Authentication

Authentication establishes that the principal is who or what it claims to be. Common authentication methods include:

Management Console: IAM username and password, optionally combined with multi-factor authentication (MFA).
AWS CLI and AWS APIs: An access key ID and secret access key for programmatic access.
Applications using roles: The application assumes an IAM role through the AWS Security Token Service (AWS STS) AssumeRole API action.

MFA adds another authentication factor by requiring something the user possesses, such as a phone or hardware device that generates a code.

Authorization

Authorization determines whether an authenticated principal may perform a requested action on a particular resource. AWS evaluates policies and produces an allow or deny decision.

The request is evaluated using information such as:

The requested action or operation.
The principal making the request.
The target resource.
The policies applying to the identity or resource.

Examples of actions include RunInstances for launching an EC2 instance, retrieving information about an S3 bucket, and CreateUser for creating an IAM user.

IAM Policies

The lesson identifies two broad policy types:

Identity-based policies: Policies associated with an IAM identity, such as a user or role.
Resource-based policies: Policies associated directly with a resource.

These policies define which actions are permitted or denied for specified resources and principals. The lesson emphasizes that authorization is based on the request context and the applicable identity- or resource-level policies.

IAM Identities and Groups

IAM users and IAM roles are IAM identities. User groups are organizational containers used to assign permissions to multiple users; they are not principals and cannot authenticate independently.

A user can belong to more than one group. The user receives the permissions assigned through each group. For example, a user who belongs to both an operations group and a developers group receives the permissions associated with both groups.

Authentication and Authorization Workflow

A useful way to reason about an AWS access request is:

A principal initiates a request. The request identifies the intended action and resource.
AWS authenticates the principal. The credentials may be console credentials, access keys, or temporary credentials obtained by assuming a role.
AWS builds the request context. This includes who is making the request, what action is requested, and which resource is targeted.
AWS evaluates applicable policies. Identity-based and resource-based policies provide the authorization information.
AWS allows or denies the action. An allowed request can proceed against the specified resource; a denied request cannot.

This distinction is essential: authentication answers “Who are you?” while authorization answers “What are you allowed to do?”

IAM Users, Groups, Roles, and Applications

IAM Users

An IAM user represents an identity that can authenticate to AWS. Console users typically use a username and password. A user may also have access keys for CLI, API, or application access.

Access keys should be treated like credentials. When an application uses an IAM user, the access key information is placed into the application, which then uses those credentials to make AWS API requests.

IAM Groups

Groups simplify permission management for users with common needs. Instead of assigning the same policies individually to many users, an administrator can place users in a group and attach the relevant permissions to that group.

Important limitations:

You cannot authenticate as a group.
A group is not an IAM principal.
Groups are used for organizing users and applying permissions.
A user may receive permissions from multiple groups.

IAM Roles

A role has permissions defined by policies and can be assumed by a principal. An application can call the AWS STS AssumeRole API action to obtain the role’s permissions and access AWS resources.

The role-based application workflow is:

The application assumes the role.
AWS STS provides the role-based access needed by the application.
The application uses the role’s permissions to make authorized AWS API requests.

The lesson contrasts this with an application using an IAM user, where access keys are created for the user and embedded or configured in the application.

Federated Users

Federated users are also identified as IAM principals. The lesson names federation as a category of principal but does not describe a specific federation configuration or protocol.

Amazon Resource Names and Request Context

AWS resources use Amazon Resource Names (ARNs) to identify them. An ARN includes account-specific information and identifies the resource type and name.

The examples in the lesson show:

A user ARN containing an account number followed by user/Paul.
A role ARN containing an account number followed by role/ and the role name.

When evaluating a request, AWS considers the principal, action, and resource represented in the request context. The ARN helps identify the relevant IAM identity or AWS resource in that evaluation.

Exam- or Assessment-Relevant Takeaways

Separate authentication from authorization. Credentials prove identity; policies determine permissions.
Recognize console access as username-and-password authentication, optionally strengthened with MFA.
Recognize CLI and API access as programmatic access using an access key ID and secret access key in the lesson’s model.
For an application that needs AWS permissions, identify an IAM role and the STS AssumeRole action as the role-based access pattern.
Know that an application can also use an IAM user with access keys, but this is a different credential model from assuming a role.
Remember that IAM groups cannot authenticate and are not principals.
A user in multiple groups receives permissions assigned through those groups.
IAM users and IAM roles are IAM identities.
Authorization uses the request context and applicable identity-based or resource-based policies.
Use ARN structure to distinguish IAM users from IAM roles, such as user/ versus role/ after the account information.

Tool / Feature Decision Guide

Requirement	Appropriate IAM feature or method	Decisive reason
A person needs to sign in to the AWS Management Console	IAM user credentials	Console authentication in the lesson uses a username and password, optionally with MFA.
A person or workload needs stronger console authentication	MFA with console credentials	MFA adds proof of possession of a phone or hardware token.
A script or tool needs to call AWS programmatically	Access key ID and secret access key	The lesson identifies access keys as the CLI and API authentication method.
An application needs permissions to call AWS APIs through a role	IAM role with STS `AssumeRole`	The application assumes the role and uses the permissions assigned to it.
Many users share similar permissions	IAM group	Permissions can be managed at the group level and inherited by its users.
One user has multiple job responsibilities	Membership in multiple groups	The user receives permissions from each group.
A request must be evaluated	Applicable identity-based and resource-based policies	These policies determine whether the requested action is allowed or denied.

Common Traps / Misconceptions

Authentication is not authorization. Successfully signing in does not automatically grant permission to every AWS action.
An IAM group is not a principal. Users authenticate individually; they do not sign in as a group.
Groups do not represent applications. They organize users and apply permissions to those users.
Roles and users are not interchangeable credential workflows. An application using a role assumes it through STS, while an application using a user relies on that user’s access keys.
Access keys are for programmatic access in this lesson. Do not confuse them with the username-and-password method used for management console access.
A principal is broader than a human user. Applications and federated users can also act as principals.
A policy does not authenticate an identity. Policies participate in authorization after the request’s identity and credentials have been established.
Multiple group memberships matter. A user such as the example user Sophie receives permissions associated with both groups to which she belongs.

Real-World Engineer / Analyst Notes

Start IAM troubleshooting by separating the failure into authentication or authorization. Invalid credentials indicate an authentication issue; a recognized identity receiving an access denial indicates an authorization issue.
For application access, first identify whether the application is using an IAM user with access keys or assuming an IAM role. The credential path determines where to inspect the configuration and permissions.
Use groups to manage common user permissions rather than repeatedly assigning the same policies to individual users.
When analyzing an access decision, record the principal, requested action, target resource, and policies that apply. This mirrors the request-context model described in the lesson.
Treat access keys as sensitive credentials when configuring programmatic access. The lesson establishes that they function similarly to a username-and-password pair for CLI and API authentication.
Check all relevant group memberships when a user appears to have more permissions than expected.

Quick Reference Summary

Principal: A person, application, or federated user that can make a request.
Authentication: Proves the principal’s identity.
Authorization: Determines whether the authenticated principal may perform the requested action.
Console credentials: Username and password, optionally with MFA.
Programmatic credentials: Access key ID and secret access key.
Application role access: Use STS AssumeRole so the application can use the role’s permissions.
Identity-based policy: Attached to an identity such as a user or role.
Resource-based policy: Attached to a resource.
IAM user: An identity that can authenticate and make requests.
IAM role: An identity whose permissions can be assumed by a principal.
IAM group: A user-organization mechanism; it cannot authenticate independently.
ARN: An identifier that includes account and resource or identity details, such as user/Paul or role/RoleName.

Flashcards

Q: A script must call AWS APIs rather than use the Management Console. Which credential method does this lesson associate with that access?

A: Use an access key ID and secret access key for programmatic CLI or API access.

Q: What is the difference between authentication and authorization in IAM?

A: Authentication proves who the principal is. Authorization evaluates policies to determine whether that authenticated principal may perform a requested action on a resource.

Q: An application needs to use permissions assigned to an IAM role. What operation does it perform?

A: It uses the AWS STS AssumeRole API action to assume the role and obtain the role’s permissions for its AWS requests.

Q: When would an IAM group be preferable to assigning the same permissions to each user individually?

A: Use a group when multiple users have similar permission needs. Policies can be assigned to the group and applied to its members.

Q: Can a user authenticate as an IAM group?

A: No. Groups are not IAM principals and cannot authenticate independently; users authenticate as individual users.

Q: A user belongs to both an operations group and a developers group. How should the user’s permissions be evaluated?

A: The user receives the permissions assigned through both groups. Multiple group memberships therefore contribute to the user’s effective permissions.

Q: What information makes up the key idea of an IAM request context?

A: The request context includes the principal making the request, the requested action or operation, and the resource targeted by the request.

Q: What is the practical difference between an application using an IAM user and one using an IAM role?

A: An application using a user is configured with that user’s access keys. An application using a role assumes it through STS and uses the permissions attached to the role.

Q: Which policy categories are identified in the lesson?

A: Identity-based policies and resource-based policies. They provide the policy information used to decide whether an action is allowed or denied.

Q: In an ARN, what does user/Paul indicate compared with role/RoleName?

A: user/Paul identifies an IAM user, while role/RoleName identifies an IAM role after the account information in the ARN.

Q: A user successfully signs in but receives a denial when attempting an action. Is this primarily an authentication or authorization problem?

A: It is primarily an authorization problem because authentication succeeded, but applicable policies did not permit the requested action on the resource.

Q: What does MFA add to console authentication?

A: MFA adds proof that the user possesses a physical factor, such as a phone or hardware device that generates a code, in addition to knowing the password.

Practice Questions

Question 1

An application must access AWS resources using permissions assigned to a role. Which approach best matches the lesson?

A. Authenticate as an IAM group

B. Store the role name as the application’s password

C. Use AWS STS AssumeRole to assume the IAM role

D. Add the application to an IAM user group

Correct answer: C. The decisive clue is that applications use the STS AssumeRole API action to assume a role and use its permissions. Groups cannot authenticate, and a role name is not a credential.

Question 2

An organization has many users who perform similar developer tasks and should receive the same permissions. What is the most appropriate IAM feature from the lesson?

A. Create a separate role for every user

B. Place the users in a developers group and assign permissions to the group

C. Allow the users to authenticate as the developers group

D. Give every user the root account password

Correct answer: B. Groups are designed to organize users with common needs and apply shared permissions. Users still authenticate individually.

Question 3

A user signs in to the AWS Management Console with a username and password, then tries to launch an EC2 instance and receives an access denial. What should be examined next?

A. Whether the user has an access key for console login

B. The applicable identity-based or resource-based policies

C. Whether the user belongs to an IAM group that can authenticate

D. Whether the ARN contains role/ instead of user/

Correct answer: B. The user has already authenticated, so the next issue is authorization. The applicable policies determine whether the user can perform the launch action on the resource.

Question 4

A command-line tool needs to make AWS requests. Which authentication method is identified for this use case?

A. Username and password only

B. Access key ID and secret access key

C. Group name and group ARN

D. MFA code without any other credential

Correct answer: B. The lesson associates access key ID and secret access key credentials with CLI and API programmatic access.

WordPress Metadata

Suggested Slug:
aws-iam-principals-authentication-authorization-users-groups-roles

Meta Description:
Study AWS IAM principals, authentication methods, policies, users, groups, roles, programmatic access, and application authorization for the AWS Certified CloudOps Engineer Associate SOA-C03.

Tags:
AWS IAM, AWS Certified CloudOps Engineer, IAM users, IAM roles, IAM groups, IAM policies, AWS authentication, AWS authorization, IAM principals, AWS access keys