Study guide
Technical reference and lesson notes
This lesson explains how AWS IAM roles are used to grant temporary, controlled access to AWS resources without relying on long-term credentials. For the SAP-C02 exam, IAM roles are a major security design pattern because they support least privilege, cross-account access, AWS service integration, application permissions, and federation.
IAM roles are especially important in scenario-based questions where AWS expects you to avoid static access keys and use temporary credentials through AWS Security Token Service, or STS.
Key Concepts
What Is an IAM Role?
An IAM role is an AWS identity that can be assumed by a trusted entity. Unlike an IAM user, a role is not tied to one permanent person or application. Instead, the role provides temporary credentials when it is assumed.
A role has two major parts:
| Component | Purpose |
|---|---|
| Trust policy | Defines who or what is allowed to assume the role |
| Permissions policy | Defines what actions the role can perform after it is assumed |
The trust policy answers:
“Who can become this role?”
The permissions policy answers:
“What can this role do?”
This distinction is very important for the SAP-C02 exam.
IAM Roles Use Temporary Credentials Through STS
IAM roles use AWS Security Token Service to generate temporary security credentials. These credentials are short-lived and are safer than long-term access keys.
Temporary credentials typically include:
- Access key ID
- Secret access key
- Session token
- Expiration time
The key design point is that the credentials expire automatically. This reduces risk if credentials are exposed, because they are only valid for a limited time.
Why IAM Roles Are More Secure Than Access Keys
Static access keys are long-term credentials. If an IAM user has broad permissions and access keys are created for that user, those access keys inherit the same permissions as the user.
That can create unnecessary risk.
For example, if an administrator creates access keys for automation, those keys could potentially have administrator-level access. A better design is to create a role with only the permissions required for the workload.
For the SAP-C02 exam, the safer answer is usually:
Use an IAM role with temporary credentials instead of embedding access keys.
Users Can Assume Roles
IAM users can assume roles to temporarily gain a different set of permissions.
A common example is a developer who normally works in a development environment but occasionally needs access to production. Instead of giving the developer permanent production permissions, the developer can assume a production deployment role only when needed.
When the user assumes the role, they operate using the role’s permissions. The user is no longer operating with their normal user permissions for that session. In practical terms, they have “become” the role.
This helps reduce accidental changes because elevated permissions are only used when needed.
Applications Can Assume Roles
Applications can also use roles.
For example, an application running on an EC2 instance may need to read from Amazon S3 or write to Amazon DynamoDB. Instead of storing access keys on the instance, the EC2 instance can be assigned a role.
The application then receives temporary credentials automatically and uses those credentials to call AWS APIs.
This is the preferred pattern for AWS-hosted workloads.
Service Integration with IAM Roles
AWS services commonly use IAM roles to access other AWS services securely.
Amazon EC2 Instance Profiles
For Amazon EC2, IAM roles are attached through an instance profile.
An instance profile is the mechanism that allows an EC2 instance to use an IAM role. Applications running on the instance can retrieve temporary credentials and use them to access AWS services.
Example use case:
An EC2-hosted application needs to read objects from S3.
Best design:
Attach an IAM role to the EC2 instance through an instance profile with only the required S3 permissions.
AWS Lambda Execution Roles
AWS Lambda uses an execution role.
The execution role grants the Lambda function permissions to call other AWS services. For example, a Lambda function may need to write logs to Amazon CloudWatch Logs, read an object from S3, or write records to DynamoDB.
The Lambda service assumes the role when the function runs.
Amazon ECS IAM Roles
Amazon ECS can use IAM roles in more than one way.
Two important patterns are:
| ECS Role Type | Purpose |
|---|---|
| Instance IAM role | Grants permissions to the EC2 container instance |
| Task IAM role | Grants permissions directly to the ECS task/application |
For application-level permissions, the task role is usually the better least-privilege design. It allows each workload to have its own permissions instead of sharing broad permissions from the underlying EC2 host.
Service-Linked Roles
Some AWS services use service-linked roles.
A service-linked role is created and managed by AWS for a specific service. It gives the service the permissions it needs to interact with other AWS resources on your behalf.
Elastic Load Balancing is an example of a service that can use a service-linked role to interact with resources in EC2.
For the exam, remember that service-linked roles are tied to AWS service operations and are usually created automatically or through service setup.
Cross-Account Access with IAM Roles
IAM roles are a standard way to grant access across AWS accounts.
Example:
- Account A owns an S3 bucket.
- Account B has a user who needs access to that bucket.
- Account A creates a role with permissions to access the bucket.
- The trust policy allows the user or principal from Account B to assume the role.
- The user in Account B calls
sts:AssumeRole. - STS returns temporary credentials.
- The user can now access the S3 bucket using the role’s permissions.
This avoids creating IAM users in multiple accounts and avoids sharing long-term credentials.
External ID for Cross-Account Access
An external ID can be used as an additional condition in the trust policy.
This is especially useful when allowing a third party or another account to assume a role. The trusted party must provide the correct external ID when calling AssumeRole.
The external ID helps prevent confused deputy problems, where a trusted entity could accidentally be used to access resources on behalf of the wrong customer or account.
For SAP-C02, external ID is strongly associated with secure third-party or cross-account role assumption.
Federation with IAM Roles and STS
IAM roles and STS are also used in federation scenarios.
Federation allows users to authenticate through an external identity provider instead of using native IAM users.
Common identity providers include:
- Microsoft Active Directory
- Active Directory Federation Services
- SAML-based providers
- OpenID Connect providers
- Social identity providers through Amazon Cognito
The high-level pattern is:
- User authenticates with an external identity provider.
- The identity provider returns a token or assertion.
- AWS uses that identity information to map the user to an IAM role.
- STS issues temporary credentials for that role.
- The user or application accesses AWS resources using those temporary credentials.
Amazon Cognito Example
Amazon Cognito can be used for web and mobile application authentication.
A common architecture includes:
- Cognito user pool
- Cognito identity pool
- External or social identity provider
- IAM roles
- STS temporary credentials
- AWS service access, such as DynamoDB
The user pool handles authentication. The identity pool exchanges the authenticated identity for temporary AWS credentials. Those credentials are associated with an IAM role.
This allows web or mobile users to securely access AWS services without embedding AWS credentials in the application.
Active Directory and SAML Federation
In enterprise environments, federation may use Active Directory and ADFS.
The user authenticates with the enterprise identity provider. AWS receives the federation response and maps the authenticated user to an IAM role. STS then issues temporary credentials.
This is commonly used when organizations want centralized identity management while still granting access to AWS accounts and resources.
Exam-Relevant Takeaways
IAM roles are the preferred method for granting temporary permissions in AWS.
For the SAP-C02 exam, remember these points:
- IAM roles use STS to issue temporary credentials.
- Roles do not use permanent passwords or access keys.
- A trust policy defines who can assume the role.
- A permissions policy defines what the role can do.
- When a user assumes a role, they operate with the role’s permissions.
- EC2 uses instance profiles to receive IAM role credentials.
- Lambda uses execution roles.
- ECS can use instance roles and task roles.
- Service-linked roles allow AWS services to operate on your behalf.
- Cross-account access is commonly implemented with IAM roles and
sts:AssumeRole. - External IDs add protection for cross-account or third-party role assumption.
- Federation with SAML, OIDC, Active Directory, or Cognito commonly results in role assumption and STS temporary credentials.
- Avoid embedding long-term access keys in applications or EC2 instances.
Architecture Decision Guide
| Scenario | Best AWS Choice | Why |
|---|---|---|
| EC2 application needs access to S3 | EC2 IAM role through an instance profile | Avoids static keys and provides temporary credentials automatically |
| Lambda function needs to write to CloudWatch Logs and DynamoDB | Lambda execution role | Lambda assumes the role at runtime and receives only the permissions assigned |
| ECS task needs application-specific permissions | ECS task IAM role | Provides least privilege at the task/application level instead of relying on the container instance role |
| Developer needs occasional production access | IAM role for production access | Grants temporary elevated access without permanently assigning production permissions |
| Account B user needs access to Account A resources | Cross-account IAM role with sts:AssumeRole | Avoids creating duplicate IAM users or sharing credentials |
| Third-party vendor needs access to your AWS account | Cross-account IAM role with external ID | Reduces confused deputy risk and provides controlled temporary access |
| Mobile app users need access to DynamoDB | Cognito user pool, Cognito identity pool, IAM roles, and STS | Allows authenticated users to receive temporary AWS credentials |
| Enterprise users need AWS access through corporate identity | SAML or Active Directory federation mapped to IAM roles | Centralizes identity management and avoids separate IAM users |
| AWS service needs permissions to manage related AWS resources | Service-linked role | AWS-managed role designed for a specific service integration |
Common Exam Traps
Trap 1: Choosing Access Keys Instead of Roles
If an application runs on AWS and needs to access AWS services, do not choose static IAM user access keys unless there is a very specific reason. The exam usually expects IAM roles with temporary credentials.
Trap 2: Confusing Trust Policies and Permissions Policies
A trust policy does not grant access to S3, DynamoDB, EC2, or other services. It only defines who can assume the role.
The permissions policy defines what the role can do after it is assumed.
Trap 3: Assuming a User Keeps Their Original Permissions After Role Assumption
When a user assumes a role, they use the role’s permissions for that session. They are not simply adding the role permissions on top of their existing user permissions.
Trap 4: Using Broad User Permissions for Automation
If an administrator creates access keys for automation, those keys may inherit excessive permissions. A role with a narrow permissions policy is usually the better design.
Trap 5: Missing the External ID in Third-Party Access Scenarios
When the scenario includes a third party or cross-account access with additional security concerns, look for external ID as part of the correct answer.
Trap 6: Confusing Cognito User Pools and Identity Pools
A Cognito user pool handles user authentication.
A Cognito identity pool is used to obtain temporary AWS credentials through IAM roles and STS.
For AWS resource access from a mobile or web app, identity pools and IAM roles are usually part of the answer.
Real-World Engineer Notes
In real environments, IAM roles are one of the first places to enforce least privilege properly.
For EC2 workloads, avoid putting credentials in configuration files, scripts, environment variables, or AMIs. Attach an IAM role to the instance and let the AWS SDK retrieve temporary credentials automatically.
For Lambda, keep execution roles narrow. It is common to see Lambda functions with overly broad permissions because teams attach managed policies during testing and never come back to tighten them.
For ECS, task roles are operationally important. If multiple applications run on the same ECS cluster, each application should have its own task role where possible. Otherwise, one compromised container may inherit permissions intended for another workload.
For cross-account access, roles are much cleaner than creating IAM users in every account. This matters in multi-account AWS Organizations designs where teams may need controlled access to shared services, logging accounts, security tooling, or production environments.
For third-party vendor access, always be cautious. Use a dedicated role, least-privilege permissions, external ID, and strong monitoring. In production, this should be documented and reviewed periodically.
For federation, IAM roles allow AWS access to be tied back to the organization’s identity provider. This simplifies onboarding and offboarding because users can be managed centrally rather than directly in IAM.
From an operational perspective, troubleshooting role issues usually comes down to three questions:
- Is the principal allowed to assume the role?
- Does the role have permission to perform the required API action?
- Is there another policy layer blocking access, such as an SCP, permissions boundary, session policy, or resource policy?
Quick Reference Summary
IAM roles provide temporary access to AWS resources through STS.
A role has a trust policy and a permissions policy.
Use roles instead of access keys whenever possible.
EC2 uses instance profiles.
Lambda uses execution roles.
ECS can use instance roles and task roles.
Service-linked roles are used by AWS services to operate on your behalf.
Cross-account access commonly uses sts:AssumeRole.
External IDs add security for third-party or cross-account access.
Federation with SAML, OIDC, Active Directory, or Cognito commonly maps authenticated users to IAM roles and temporary credentials.
For SAP-C02, when you see a scenario involving secure access, least privilege, cross-account access, or applications needing AWS API access, think IAM roles and STS.
Flashcards
Q: What AWS service issues temporary credentials when an IAM role is assumed?
A: AWS Security Token Service, or STS.
Q: What does an IAM role trust policy define?
A: Who or what is allowed to assume the role.
Q: What does an IAM role permissions policy define?
A: What actions the role can perform after it is assumed.
Q: Why are IAM roles preferred over access keys for applications running on AWS?
A: Roles provide temporary credentials and avoid storing long-term static credentials.
Q: How does an EC2 instance receive permissions from an IAM role?
A: Through an instance profile attached to the EC2 instance.
Q: What is a Lambda execution role?
A: An IAM role that Lambda assumes when the function runs, granting the function permissions to access AWS services.
Q: What IAM role type is usually preferred for ECS application permissions?
A: An ECS task role, because it grants permissions directly to the task/application.
Q: What API action is commonly used for cross-account role assumption?
A: sts:AssumeRole.
Q: Why use an external ID in a cross-account role trust policy?
A: To add an additional verification value and help prevent confused deputy problems.
Q: What is a service-linked role?
A: An IAM role associated with a specific AWS service that allows that service to manage AWS resources on your behalf.
Q: In a Cognito-based mobile app, what component helps obtain temporary AWS credentials?
A: A Cognito identity pool, which maps identities to IAM roles and uses STS.
Q: What happens to a user’s permissions when they assume a role?
A: The user operates with the permissions of the role for that session.
Q: What is the main security benefit of temporary credentials?
A: They expire automatically, reducing the risk of long-term credential compromise.
Practice Questions
Question 1:
A developer normally has access only to a development AWS environment. Occasionally, the developer needs to deploy code into production. The company wants to avoid permanent production permissions for the developer. Which design is most appropriate?
A. Create permanent access keys for the developer with production permissions
B. Add the developer directly to an IAM group with full production access
C. Create an IAM role for production deployment and allow the developer to assume it when needed
D. Create a new IAM user in the production account and share the password with the developer
Correct Answer:
C
Explanation:
An IAM role allows the developer to temporarily assume production permissions only when needed. This supports least privilege and avoids permanent elevated access.
Question 2:
An application running on an EC2 instance needs to read objects from an S3 bucket. What is the most secure approach?
A. Store IAM user access keys in a configuration file on the EC2 instance
B. Attach an IAM role to the EC2 instance using an instance profile
C. Give the EC2 instance administrator access through a local operating system account
D. Store the AWS root account credentials in AWS Systems Manager Parameter Store
Correct Answer:
B
Explanation:
EC2 instances should use IAM roles through instance profiles. This allows applications to receive temporary credentials without storing long-term access keys.
Question 3:
A company has two AWS accounts. A user in Account B needs access to an S3 bucket in Account A. The company does not want to create a new IAM user in Account A. What should be used?
A. Cross-account IAM role assumption using STS
B. A shared root account password
C. Long-term access keys copied from Account A to Account B
D. A public S3 bucket policy allowing all authenticated AWS users
Correct Answer:
A
Explanation:
Cross-account IAM roles allow trusted principals in another account to assume a role and receive temporary credentials. This avoids duplicating users or sharing static credentials.
Question 4:
A third-party vendor needs access to resources in your AWS account. You create a cross-account role for the vendor. Which additional control is commonly used to reduce confused deputy risk?
A. MFA delete
B. External ID
C. S3 Transfer Acceleration
D. CloudFront signed cookies
Correct Answer:
B
Explanation:
An external ID can be required in the role trust policy. The vendor must provide the external ID when calling AssumeRole, helping prevent confused deputy scenarios.
Question 5:
A mobile application authenticates users through social identity providers and needs to provide temporary access to a DynamoDB table. Which architecture best matches this requirement?
A. Store IAM user access keys inside the mobile application
B. Use Cognito user pools, Cognito identity pools, IAM roles, and STS temporary credentials
C. Create one IAM user for every mobile application user
D. Make the DynamoDB table publicly accessible
Correct Answer:
B
Explanation:
Cognito can authenticate users and use identity pools to exchange authenticated identities for temporary AWS credentials associated with IAM roles. This is the appropriate pattern for mobile and web application access to AWS resources.