AWS IAM Fundamentals: Users, Roles, Policies, and Authentication – SAP-C02 Study Guide

Purpose of This Lesson

AWS Identity and Access Management (IAM) controls who can access AWS resources, how they authenticate, and what actions they are permitted to perform. IAM is used for access through the AWS Management Console, the AWS Command Line Interface (CLI), and AWS APIs.

This lesson introduces the IAM building blocks and security mechanisms that support secure AWS account access:

• IAM users, groups, and roles
• Policies that define permissions
• Authentication and authorization
• Access keys for programmatic access
• Multi-factor authentication (MFA)
• Password policies
• Identity-based and resource-based policies

Key Concepts

Authentication vs. Authorization

These are separate security decisions:

• Authentication verifies an identity. For example, a principal signs in to the console with credentials or makes an API request using access keys.
• Authorization determines whether that authenticated principal is allowed to perform a requested action on a particular AWS resource.

A successful login does not automatically grant permission to use AWS services. Permissions must be granted through IAM policies and other applicable access controls.

IAM Users

An IAM user represents a specific identity within an AWS account. An identity may use:

• A password for AWS Management Console access
• Access keys for CLI or API access
• MFA for an additional authentication factor

IAM users are account-specific identities. For human access, centralized identity federation and IAM roles are generally preferred over creating many long-lived IAM users, but the key exam distinction is that a user is a named identity with credentials and permissions associated with it.

IAM Groups

An IAM group is a collection of IAM users. Groups simplify permission management by allowing policies to be attached to the group rather than individually to every user.

Groups contain users, not roles or other groups. A user can belong to multiple groups, and the user’s effective permissions are derived from all applicable policies.

IAM Roles

An IAM role is an identity that can be assumed temporarily by a trusted principal. Roles do not normally have long-term credentials permanently associated with them. When a principal assumes a role, AWS provides temporary security credentials.

Roles are commonly used for:

• AWS services accessing other AWS services
• Applications running on AWS compute resources
• Cross-account access
• Federated human access
• Temporary elevated or specialized permissions

A role has two important policy concepts:

• Trust policy: Defines who or what is allowed to assume the role.
• Permissions policy: Defines what the role can do after it is assumed.

IAM Policies

Policies are JSON documents that describe permissions. A policy typically specifies:

• The permitted or denied action
• The target resource
• Optional conditions controlling when access is allowed
• An effect of Allow or Deny

An explicit Deny overrides an Allow. Therefore, access decisions must consider all relevant policies and controls rather than looking only for a matching allow statement.

Identity-Based and Resource-Based Policies

Identity-based policies attach permissions to an identity such as a user, group, or role. They define what that identity is allowed to do.

Resource-based policies attach directly to a resource. They define which principals can access the resource and what actions they can perform. Resource-based policies are common with services such as Amazon S3, AWS Lambda, Amazon SQS, and AWS KMS, although the exact policy capabilities vary by service.

When evaluating an architecture, determine whether access is controlled from the identity side, the resource side, or both. Cross-account access frequently requires careful coordination between the principal’s permissions and the target resource’s policy or an assumed role.

Access Through Console, CLI, and APIs

AWS access can occur through three common interfaces:

• AWS Management Console: Typically uses a password and may require MFA.
• AWS CLI: Uses credentials configured for the CLI, commonly temporary credentials or access keys.
• AWS APIs and SDKs: Use credentials supplied through an SDK credential provider chain or another secure mechanism.

Long-lived access keys create credential-management risk. Prefer temporary credentials obtained through IAM roles whenever the workload or access pattern supports them.

Multi-Factor Authentication

MFA adds a second authentication factor in addition to a password or other primary credential. It is an important control for reducing the impact of compromised credentials.

MFA should be considered for:

• Privileged human access
• Sensitive account operations
• Root account protection
• Administrative workflows

MFA is an authentication control; it does not replace authorization policies. A user can successfully authenticate with MFA and still be denied an action by IAM permissions.

Password Policies

IAM password policies define requirements for IAM user passwords, such as complexity and expiration rules. These policies help enforce stronger console credentials, but they do not govern every type of AWS credential. For example, access keys used for programmatic access require separate lifecycle and protection practices.

Exam-Relevant Takeaways

• IAM provides authentication and authorization for AWS access through the console, CLI, and APIs.
• Users are named identities; groups organize users; roles provide temporary assumed permissions.
• Roles are the preferred mechanism for AWS services, applications, federated users, and many cross-account access patterns.
• A role’s trust policy controls who can assume it; its permissions policies control what the assumed role can do.
• Identity-based policies attach to users, groups, or roles. Resource-based policies attach to resources.
• Access keys support programmatic access, but long-lived keys should be avoided when temporary role credentials are available.
• MFA strengthens authentication but does not grant permissions by itself.
• Explicit denies override allows.
• Password policies address IAM user passwords, not the complete lifecycle of programmatic credentials.

Architecture Decision Guide

Requirement	Preferred IAM construct	Key consideration
Organize permissions for several IAM users	IAM group	Attach common policies to the group instead of duplicating them per user
Allow an EC2 workload or AWS service to call another service	IAM role	Use temporary credentials and a narrowly scoped permissions policy
Allow an application outside AWS to access AWS	IAM role with a suitable federation or trusted identity mechanism	Avoid embedding long-lived access keys in application code
Allow a principal to access a specific resource	Resource-based policy, where supported	Confirm the service supports the required resource-policy behavior
Enforce an additional factor for console access	MFA	MFA improves authentication but does not alter authorization rules
Enforce stronger IAM user passwords	IAM password policy	Manage access keys separately
Provide CLI or API access	Temporary role credentials when possible; access keys when necessary	Protect, rotate, and limit any long-lived keys

Common Exam Traps

• Confusing authentication with authorization: Signing in successfully does not imply permission to perform an action.
• Treating a role like a user: Roles are designed to be assumed and normally provide temporary credentials rather than permanent user credentials.
• Ignoring the trust policy: A role’s permissions policy does not determine who may assume the role. That is controlled by the trust policy.
• Assuming MFA grants access: MFA verifies an additional factor; IAM policies still determine authorization.
• Using access keys for workloads by default: For AWS-hosted workloads, an IAM role is usually safer than storing long-lived access keys.
• Looking only for an Allow: An explicit Deny takes precedence over an allow statement.
• Assuming password policies secure API credentials: Password rules apply to IAM user passwords and do not replace access-key governance.
• Treating identity-based and resource-based policies as interchangeable: Their attachment points and service-specific behavior differ.

Real-World Engineer Notes

• Design permissions around least privilege: grant only the actions and resources required for a task.
• Prefer roles and temporary credentials for workloads and delegated access.
• Keep human administrative access protected with MFA and avoid sharing credentials.
• Separate authentication design from authorization design during troubleshooting. First verify how the principal authenticated, then inspect the policies governing the requested action.
• For cross-account designs, inspect both sides of the relationship: who is trusted to assume a role or access a resource, and what permissions are granted after access is established.
• Treat access keys as sensitive secrets. Do not place them in source code, container images, or unprotected configuration files.

Quick Reference Summary

• IAM: AWS service for identity and access control.
• User: Named AWS account identity with console or programmatic credentials.
• Group: Collection of IAM users used for shared permission management.
• Role: Assumable identity that provides temporary credentials.
• Trust policy: Determines who or what may assume a role.
• Permissions policy: Determines allowed or denied actions on resources.
• Identity-based policy: Attached to a user, group, or role.
• Resource-based policy: Attached to a supported AWS resource.
• MFA: Additional authentication factor.
• Access key: Credential for CLI, SDK, or API access.
• Explicit deny: Overrides an allow.

Flashcards

1. Q: What are the two major IAM decisions involved in AWS access?

A: Authentication verifies the identity; authorization determines whether that identity may perform the requested action.

1. Q: What is the primary purpose of an IAM group?

A: To organize IAM users and apply shared permissions efficiently.

1. Q: What is the main difference between an IAM user and an IAM role?

A: A user is a named account identity, while a role is assumed by a trusted principal and typically provides temporary credentials.

1. Q: What does a role trust policy control?

A: It controls which principals may assume the role.

1. Q: What does a role permissions policy control?

A: It controls what actions the principal may perform after assuming the role.

1. Q: Where is an identity-based policy attached?

A: To a user, group, or role.

1. Q: Where is a resource-based policy attached?

A: Directly to a supported AWS resource.

1. Q: Does MFA grant additional AWS permissions?

A: No. MFA strengthens authentication; IAM policies still determine authorization.

1. Q: Which policy result overrides an allow?

A: An explicit deny.

1. Q: What type of credentials should AWS workloads prefer?

A: Temporary credentials obtained through an IAM role, when supported by the workload and access pattern.

Practice Questions

Question 1

An application running on AWS needs to call an AWS service. The security team does not want credentials stored in the application code or configuration files. Which IAM design is most appropriate?

• A. Create an IAM user and embed its access keys in the application
• B. Create an IAM group and attach it to the application instance
• C. Create an IAM role with least-privilege permissions and associate it with the workload
• D. Enable MFA on the AWS account root user

Correct answer: C

Explanation: An IAM role provides temporary credentials to an AWS workload and avoids embedding long-lived access keys. Groups contain users and cannot be attached directly to an application workload. MFA on the root user does not provide application authorization.

Question 2

A principal successfully authenticates to AWS but receives an access denied error when calling an API operation. Which statement best explains the result?

• A. Authentication always grants access to all AWS services
• B. Authorization is evaluated separately from authentication
• C. Password policies automatically deny API operations
• D. MFA must be enabled for every API operation

Correct answer: B

Explanation: Authentication verifies the principal’s identity. Authorization then evaluates applicable IAM and resource policies to determine whether the requested action is allowed.

Question 3

An administrator finds an IAM policy that allows an action, but the request is still denied. Another applicable policy contains an explicit Deny for the same action. What is the expected result?

• A. The allow always takes precedence
• B. The deny takes precedence
• C. The request succeeds only if the user belongs to an IAM group
• D. The request succeeds when MFA is enabled

Correct answer: B

Explanation: An explicit deny overrides an allow. Group membership and MFA do not override an explicit policy deny.