AWS Identity and Access Management (IAM): Users, Groups, Roles, and Policies – SAP-C02 Study Guide | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

Purpose of This Lesson

AWS Identity and Access Management (IAM) controls who or what can authenticate to AWS and which actions they are authorized to perform. IAM applies to access through the AWS Management Console, AWS CLI, SDKs, and direct AWS API calls.

The central IAM workflow is:

Authentication verifies the identity of a requester.
Authorization determines whether that identity can perform a requested API action on a specific AWS resource.

Understanding the distinction between users, groups, roles, policies, root access, and programmatic credentials is essential for AWS architecture and security questions.

Key Concepts

Authentication and Authorization

A principal is an entity that makes a request to AWS. It may be a person, application, or other identity using an AWS credential.

Authentication: Proves the requester’s identity, such as with a password, access key, or temporary security credentials.
Authorization: Determines whether the authenticated principal is allowed to perform an operation.
API actions: Operations such as ec2:RunInstances, s3:GetBucketLocation, or iam:CreateUser.
Resources: AWS objects on which those actions operate.

A successful login does not automatically provide permissions. An IAM identity must have applicable policies before it can perform AWS actions.

IAM Users

An IAM user represents a long-term identity within an AWS account. A user can be configured for:

AWS Management Console access through a username and password
Programmatic access through an access key ID and secret access key
Multi-factor authentication (MFA), where appropriate

New IAM users have no permissions by default. Permissions must be provided through policies attached directly to the user or inherited from groups.

IAM users have a friendly name and an Amazon Resource Name (ARN). An ARN uniquely identifies the IAM resource within AWS and includes the account identifier and user name.

IAM User Groups

A user group is a collection of IAM users used to manage permissions by job function or responsibility.

For example, an organization might create groups such as:

Administrators
Developers
Operations

A policy attached to a group is inherited by all members. A user can belong to multiple groups, in which case the permissions provided by those groups are combined.

Groups are generally preferable to attaching the same policy individually to many users because they simplify permission administration and reduce duplication.

IAM Roles

An IAM role is an identity with permissions defined by policies. Unlike a user, a role is generally assumed temporarily by a trusted principal rather than used with a permanent username and password.

Assuming a role provides temporary credentials and the permissions associated with that role. Common uses include:

Allowing an EC2 instance to call AWS services
Giving a Lambda function access to other AWS resources
Providing temporary access to a user or application
Delegating access between AWS accounts
Separating administrative, development, and operations privileges

A role can be viewed as a permissions profile that a principal temporarily adopts. Applications should normally use IAM roles and temporary credentials instead of embedding long-term access keys.

IAM Policies

Policies define permissions for identities or AWS resources. They specify which API actions are allowed or denied and which resources those actions apply to.

Two important categories are:

Identity-based policies: Attached to IAM users, groups, or roles.
Resource-based policies: Attached to supported AWS resources, such as an Amazon S3 bucket policy.

Identity-based policies are commonly used to define what an identity can do. Resource-based policies define who can access a resource and what they can do with it.

Root User

The root user is created when the AWS account is created. It is associated with the email address used during account registration and has broad, unrestricted access. Some account-level operations require the root user.

Recommended controls include:

Set a strong root-user password.
Enable MFA for the root user.
Avoid using the root user for everyday administration.
Do not create root-user access keys for routine or programmatic access.
Store root credentials securely and use them only when required.

The root user is not equivalent to a normal IAM user. Its privileges cannot generally be reduced through ordinary IAM policies.

Credential Types and Access Paths

Access method	Typical credentials	Common use
Management Console	IAM username, password, and optionally MFA	Human interactive access
AWS CLI	Access key ID and secret access key, or temporary credentials	Command-line administration and automation
SDK or AWS API	Access keys or temporary credentials	Application and service integration
Assumed role	Temporary credentials issued through AWS STS	Delegated, cross-account, or workload access

AWS Security Token Service (STS) can issue short-term credentials. Temporary credentials are useful when access should be limited in duration and scope.

Exam-Relevant Takeaways

IAM separates authentication from authorization.
An IAM user can authenticate but still cannot perform AWS actions unless permissions are granted.
IAM users have no permissions by default.
User groups are a scalable way to assign common permissions to multiple users.
A user can belong to multiple groups and receive the combined permissions from those groups.
Roles are assumed identities and are designed for temporary or delegated access.
Workloads such as EC2 instances and Lambda functions should use IAM roles rather than hard-coded access keys.
Console access normally uses a password; CLI and API access use access keys or temporary credentials.
MFA strengthens console authentication but does not replace authorization policies.
Protect the root user, enable MFA, and avoid using it for routine operations.
The account ID or account alias can be used with an IAM username when signing in to the AWS Management Console.

Architecture Decision Guide

Requirement	Preferred IAM approach	Reason
Several employees need the same permissions	Attach a policy to an IAM group	Centralized permission management
A person needs different responsibilities	Use multiple groups or assume an appropriate role	Supports separation of duties and controlled privilege changes
An EC2 instance needs to call AWS APIs	Attach an IAM role to the instance through an instance profile	Avoids storing long-term credentials on the server
A Lambda function needs access to AWS services	Assign an execution role	Provides service-to-service authorization
Temporary access is required	Use an assumed role and STS temporary credentials	Credentials expire automatically
A resource must control access to principals	Use a supported resource-based policy	Permissions are managed at the resource boundary
Routine account administration is required	Use an IAM user or, preferably in larger environments, federated or role-based access	Avoids exposing root credentials
An account-level operation requires root access	Use the root user only for that operation	Root access is difficult to restrict and should be tightly controlled

Common Exam Traps

Confusing authentication with authorization: A valid login does not imply permission to access a service or resource.
Assuming new IAM users can immediately administer AWS: New users have no permissions until policies are applied.
Treating a role like a permanent user account: Roles are assumed and normally provide temporary credentials.
Giving applications IAM user access keys: Long-term keys increase exposure risk. Use an IAM role and temporary credentials for AWS workloads.
Attaching identical policies separately to every user: Use groups for shared job-based permissions.
Assuming MFA grants access: MFA verifies an additional authentication factor; policies still determine authorization.
Using the root user for everyday work: Root credentials should be protected and reserved for tasks that require them.
Assuming a group is an identity that can log in: Users log in; groups are permission-management containers.
Forgetting that group membership can overlap: Permissions from multiple groups are combined for the user.

Real-World Engineer Notes

Design permissions around job functions and least privilege rather than creating broad policies for convenience.
Prefer role-based access and temporary credentials for human federation, automation, and AWS services.
Keep long-term access keys out of source code, AMIs, container images, and configuration files.
Review group membership regularly, especially when employees change responsibilities.
Treat root-user credentials as a break-glass capability and monitor their use.
Use separate roles for development, operations, and administration to reduce accidental or unauthorized changes.
When troubleshooting access, check both the identity’s effective policies and any resource-based policy governing the target resource.

Quick Reference Summary

IAM: AWS service for authentication and authorization.
Principal: Person, application, or other identity making an AWS request.
User: Long-term IAM identity, commonly representing a person or application that requires persistent credentials.
Group: Collection of users used to apply shared permissions.
Role: Assumable identity that provides permissions through temporary credentials.
Policy: Document that defines allowed or denied actions on resources.
Root user: Original account identity with broad, difficult-to-restrict privileges.
Access keys: Credentials for CLI, SDK, and API access.
MFA: Additional authentication factor, especially important for privileged access.
STS: Service that issues temporary security credentials.

Flashcards

Q: What are the two main functions of IAM?

A: Authentication and authorization.

Q: What is authentication?

A: Verifying that a requester is who they claim to be.

Q: What is authorization?

A: Determining whether an authenticated principal can perform a requested action on a resource.

Q: What permissions does a new IAM user have by default?

A: None.

Q: Why use IAM groups?

A: To apply shared permissions to multiple users and simplify administration.

Q: Can an IAM user belong to more than one group?

A: Yes. Permissions from the user’s groups are combined.

Q: What is the primary purpose of an IAM role?

A: To provide an assumable identity with defined permissions, commonly using temporary credentials.

Q: What should an EC2 instance use to call AWS services?

A: An IAM role attached through an instance profile, rather than embedded access keys.

Q: Which credentials are commonly used for console access?

A: An IAM username and password, optionally protected by MFA.

Q: Which credentials are commonly used for CLI and SDK access?

A: Access keys or temporary security credentials.

Q: What does STS provide?

A: Short-term security credentials, typically when a principal assumes a role.

Q: Why should the root user rarely be used?

A: It has broad privileges that are difficult to restrict, and some actions cannot be limited through ordinary IAM policies.

Practice Questions

Question 1

A company creates an IAM user for a new developer. The developer can sign in to the AWS Management Console but receives access-denied errors when attempting to view Amazon S3 buckets. What is the most likely explanation?

A. The developer must use the root user to access S3.
B. IAM users cannot access S3 from the console.
C. The user has authenticated successfully but has no applicable permissions policy.
D. The user must create an access key before using the console.

Correct answer: C

Explanation: Authentication only proves the user’s identity. New IAM users have no permissions by default, so an identity-based or applicable resource-based policy must grant the required S3 actions.

Question 2

An application running on an EC2 instance needs to call Amazon DynamoDB. The security team does not want credentials stored in application configuration files. Which design is most appropriate?

A. Store the root user access keys in AWS Systems Manager Parameter Store.
B. Create an IAM user and embed its access keys in the application.
C. Attach an IAM role with the required DynamoDB permissions to the EC2 instance.
D. Add the EC2 instance to an IAM user group.

Correct answer: C

Explanation: EC2 workloads should use an IAM role and temporary credentials. IAM groups contain users and cannot be attached directly to an EC2 instance.

Question 3

An organization has separate development and operations teams. Some engineers occasionally need to perform operations tasks for a limited period. Which IAM design best supports this requirement?

A. Give all engineers root-user credentials.
B. Add every engineer permanently to both groups.
C. Create separate permissions and allow authorized engineers to assume an operations role temporarily.
D. Share one IAM user between the two teams.

Correct answer: C

Explanation: Separate roles support least privilege and temporary delegation. Engineers can assume the operations role only when required, avoiding permanent access and shared credentials.

Question 4

Which action is the best initial control for protecting an AWS account’s root user?

A. Attach a restrictive IAM policy directly to the root user.
B. Add the root user to an administrators group.
C. Enable MFA, secure the credentials, and avoid routine use.
D. Generate root-user access keys for emergency automation.

Correct answer: C

Explanation: The root user is not managed like a normal IAM user and cannot generally be restricted with ordinary IAM policies. MFA and strict operational controls are essential, while root access keys should not be created for routine use.

Question 5

A company has 200 developers who require the same read-only access to a set of AWS services. The permissions must be easy to update centrally. Which approach is most suitable?

A. Attach an identical policy separately to every user.
B. Create a developers group, attach the read-only policy to it, and add the users.
C. Give the developers the root user password.
D. Create one shared IAM user for all developers.

Correct answer: B

Explanation: IAM groups provide centralized management of shared permissions. Each developer retains an individual identity while inheriting the group policy.