AWS STS Temporary Credentials and IAM Role Assumption

Purpose of This Lesson

This lesson explains how AWS Security Token Service, or AWS STS, provides temporary security credentials for accessing AWS services. For the SAP-C02 exam, this is important because many identity and access scenarios rely on temporary credentials instead of long-term access keys.

You need to understand how IAM roles, trust policies, permissions policies, and STS work together when a workload, user, service, or external identity needs access to AWS resources.

Key Concepts

What Is AWS STS?

AWS Security Token Service is the AWS service that issues temporary credentials.

These credentials are short-lived and are commonly used when an AWS service, application, user, or external identity needs access to AWS resources without using permanent access keys.

Temporary credentials usually include:

• Access key ID
• Secret access key
• Session token
• Expiration time

The session token is an important difference between temporary credentials and long-term IAM user access keys. When temporary credentials are used, the session token must be included with API requests.

Why Temporary Credentials Matter

Temporary credentials are safer than long-term credentials because they automatically expire. This reduces the risk of exposed credentials being useful indefinitely.

Instead of storing permanent access keys on an EC2 instance, Lambda function, container, or application server, AWS expects you to use IAM roles and STS-generated credentials.

For the SAP-C02 exam, this is a major security design principle:

Use IAM roles and temporary credentials whenever possible.

EC2 Accessing S3 Using an IAM Role

A common example is an application running on an Amazon EC2 instance that needs to read from or write to an Amazon S3 bucket.

The preferred design is not to place IAM user access keys on the instance. Instead, you attach an IAM role to the EC2 instance through an instance profile.

The flow looks like this:

1. An IAM role is created with permissions to access the required S3 bucket.
2. The role is associated with an instance profile.
3. The instance profile is attached to the EC2 instance.
4. The application running on EC2 uses the role credentials provided to the instance.
5. AWS STS issues temporary credentials for the role.
6. The application uses those temporary credentials to call Amazon S3 APIs.

This allows the EC2-hosted application to access S3 securely without storing static credentials on disk.

Instance Profile vs IAM Role

An IAM role defines permissions and trust relationships.

An instance profile is the container that allows an IAM role to be attached to an EC2 instance.

For exam purposes, remember this distinction:

Component	Purpose
IAM Role	Defines what permissions are available and who can assume the role
Instance Profile	Allows the IAM role to be attached to an EC2 instance

In many AWS console workflows, this detail is abstracted away, but architecturally the instance profile is what connects the role to the EC2 instance.

Trust Policy

A trust policy controls who or what is allowed to assume an IAM role.

This is different from a permissions policy.

For an EC2 instance role, the trust policy allows the EC2 service principal to assume the role.

The service principal for EC2 is:

ec2.amazonaws.com

Conceptually, the trust policy says:

“EC2 is allowed to assume this role by calling STS.”

Without a valid trust policy, the role cannot be assumed, even if the role has permissions attached.

Permissions Policy

A permissions policy defines what the role is allowed to do after it has been assumed.

For example, if the EC2 instance needs to write files to an S3 bucket, the permissions policy might allow actions such as:

• s3:GetObject
• s3:PutObject
• s3:ListBucket

The trust policy controls who can assume the role.

The permissions policy controls what the role can do after it is assumed.

This separation is critical for AWS identity design.

AssumeRole API

The sts:AssumeRole API action is used when an entity assumes an IAM role and receives temporary credentials.

In the EC2 example, EC2 assumes the role associated with the instance profile. STS then provides temporary credentials that the application can use to access AWS services.

The application does not need to manually manage long-term credentials. AWS handles the credential delivery and renewal process.

Automatic Credential Rotation

Temporary credentials expire after a defined period.

For AWS-managed role scenarios, such as EC2 instance roles, credential renewal is handled automatically. The application should use the AWS SDK, CLI, or standard credential provider chain so that refreshed credentials are used without manual intervention.

From an operations perspective, this is a major benefit. You avoid manually rotating access keys and reduce the risk of stale or compromised credentials.

Common Uses for STS

AWS STS is used in many identity and authorization scenarios, including:

• IAM roles
• Cross-account access
• Delegated access
• Identity federation
• Temporary access for workloads

For SAP-C02, STS often appears in questions involving secure access across accounts, federated users, applications running on AWS compute services, and replacing long-term credentials with temporary credentials.

Exam-Relevant Takeaways

AWS STS issues temporary credentials, not permanent credentials.

Temporary credentials include an access key ID, secret access key, session token, and expiration.

IAM roles rely on STS when they are assumed.

An EC2 instance should use an IAM role through an instance profile instead of storing IAM user access keys locally.

A trust policy defines who can assume the role.

A permissions policy defines what the role can do after it is assumed.

For EC2, the role trust policy commonly allows the EC2 service principal, ec2.amazonaws.com, to assume the role.

The sts:AssumeRole API action is used when a role is assumed.

Temporary credentials are automatically renewed in AWS-managed role scenarios such as EC2 instance roles.

STS is heavily used for federation, delegation, cross-account access, and IAM role-based access.

Architecture Decision Guide

Scenario	Best AWS Choice	Why
Application on EC2 needs access to S3	IAM role attached through an instance profile	Avoids storing long-term credentials on the instance
A workload needs short-term AWS access	AWS STS temporary credentials	Credentials expire automatically and reduce long-term exposure
You need to control who can assume a role	IAM role trust policy	Trust policy defines the allowed principal
You need to control what actions the assumed role can perform	IAM permissions policy	Permissions policy defines allowed or denied actions
An external or federated identity needs AWS access	STS-based federation pattern	Allows temporary AWS credentials instead of creating permanent IAM users
One AWS account needs controlled access to another account	Cross-account IAM role with STS AssumeRole	Provides delegated access without sharing permanent credentials

Common Exam Traps

Confusing Trust Policies and Permissions Policies

A common mistake is assuming that a permissions policy is enough for a role to be used.

It is not.

The role also needs a trust policy that allows the correct principal to assume it.

For example, an EC2 role needs a trust relationship that allows EC2 to assume the role. The S3 permissions alone do not allow EC2 to use the role.

Choosing IAM User Access Keys for EC2 Workloads

For applications running on EC2, static IAM user access keys are usually the wrong answer.

The better answer is to attach an IAM role to the EC2 instance using an instance profile.

This is more secure, easier to manage, and aligns with AWS best practices.

Forgetting the Session Token

Temporary credentials are not just an access key and secret access key.

They also include a session token.

If a scenario mentions temporary credentials and API access, remember that the session token is part of the authentication material.

Thinking STS Grants Permissions by Itself

STS does not independently decide what the caller can do.

STS issues credentials for an assumed role. The effective permissions come from the IAM policies attached to that role, combined with any applicable permission boundaries, SCPs, resource policies, or session policies.

Missing the Expiration Behavior

Temporary credentials expire.

That is the point.

Applications should use AWS SDKs or supported credential provider chains so credentials can be refreshed automatically.

Real-World Engineer Notes

In real AWS environments, IAM roles and STS are foundational to secure operations.

For EC2 workloads, you should almost never hardcode access keys into application configuration files, scripts, AMIs, or environment variables. If those credentials are exposed, they may remain valid until manually rotated or deleted. Temporary credentials reduce that risk because they expire automatically.

From an operations standpoint, using roles also simplifies credential lifecycle management. You can update a role’s permissions centrally without logging into each instance to update access keys.

For troubleshooting, separate the problem into two questions:

1. Can the workload assume the role?
2. Does the assumed role have permission to perform the action?

If the role cannot be assumed, check the trust policy.

If the role can be assumed but the API call fails with access denied, check the permissions policy and any other policy layers such as S3 bucket policies, AWS Organizations SCPs, permission boundaries, or resource-based policies.

For EC2 specifically, also verify that the correct instance profile is attached to the instance. It is possible for the IAM role to be correct, but the instance is not actually using the expected instance profile.

Quick Reference Summary

AWS STS provides temporary credentials.

Temporary credentials are used with IAM roles.

An EC2 instance uses an instance profile to receive role-based credentials.

A trust policy controls who can assume a role.

A permissions policy controls what the role can do.

sts:AssumeRole is the key API action used to assume roles.

Temporary credentials include an access key ID, secret access key, session token, and expiration.

Use roles instead of long-term IAM user keys for AWS workloads.

STS is commonly used for IAM roles, federation, delegation, and cross-account access.

Flashcards

Q: What does AWS STS provide?
A: AWS STS provides short-lived temporary security credentials.

Q: What are the main components of temporary credentials?
A: Access key ID, secret access key, session token, and expiration.

Q: What should an EC2 instance use to access S3 securely?
A: An IAM role attached to the instance through an instance profile.

Q: What is the purpose of an IAM role trust policy?
A: It defines who or what is allowed to assume the role.

Q: What is the purpose of an IAM permissions policy?
A: It defines what actions the role is allowed or denied after it is assumed.

Q: What API action is used to assume an IAM role?
A: sts:AssumeRole.

Q: What service principal is commonly used in a trust policy for EC2 instance roles?
A: ec2.amazonaws.com.

Q: Why are temporary credentials preferred over long-term access keys?
A: They expire automatically, reducing the risk of long-term credential exposure.

Q: What AWS component allows an IAM role to be attached to an EC2 instance?
A: An instance profile.

Q: Does STS itself define what an assumed role can access?
A: No. STS issues credentials, but IAM policies define the allowed actions.

Q: What happens when temporary credentials expire?
A: They can no longer be used, and new temporary credentials must be issued.

Q: Name common use cases for STS.
A: IAM roles, identity federation, delegation, and cross-account access.

Practice Questions

Question 1:
An application running on an Amazon EC2 instance needs to write files to an Amazon S3 bucket. What is the most secure and operationally preferred way to provide access?

A. Store an IAM user access key and secret access key in a configuration file on the EC2 instance
B. Attach an IAM role to the EC2 instance using an instance profile
C. Create an S3 bucket policy that allows anonymous writes
D. Use the AWS root user credentials inside the application

Correct Answer:
B. Attach an IAM role to the EC2 instance using an instance profile

Explanation:
EC2 workloads should use IAM roles through instance profiles. This allows the application to receive temporary credentials from STS without storing long-term credentials on the instance.

---

Question 2:
An EC2 instance has an IAM role with an S3 permissions policy attached, but the role cannot be assumed by EC2. What should you check first?

A. The S3 bucket lifecycle policy
B. The role’s trust policy
C. The EC2 instance storage configuration
D. The S3 object encryption algorithm

Correct Answer:
B. The role’s trust policy

Explanation:
The trust policy controls who or what can assume the role. For EC2, the trust policy must allow the EC2 service principal to assume the role.

---

Question 3:
Which statement best describes the difference between a trust policy and a permissions policy?

A. A trust policy defines what actions are allowed; a permissions policy defines billing limits
B. A trust policy defines who can assume the role; a permissions policy defines what the role can do
C. A trust policy applies only to S3; a permissions policy applies only to EC2
D. A trust policy is used for encryption; a permissions policy is used for networking

Correct Answer:
B. A trust policy defines who can assume the role; a permissions policy defines what the role can do

Explanation:
The trust policy controls role assumption. The permissions policy controls access after the role has been assumed.

---

Question 4:
Which item is included in AWS STS temporary credentials but is not part of standard long-term IAM user access keys?

A. Session token
B. VPC endpoint ID
C. Security group ID
D. S3 bucket ARN

Correct Answer:
A. Session token

Explanation:
Temporary credentials include an access key ID, secret access key, session token, and expiration time.

---

Question 5:
A company wants to allow controlled access between AWS accounts without sharing permanent IAM user credentials. Which approach best fits this requirement?

A. Create one shared IAM user and distribute the access key
B. Use cross-account IAM roles with STS AssumeRole
C. Disable IAM authentication and rely on IP allow lists
D. Store credentials in a public S3 bucket for both accounts to retrieve

Correct Answer:
B. Use cross-account IAM roles with STS AssumeRole

Explanation:
Cross-account access commonly uses IAM roles and STS. The trusted account or principal assumes a role and receives temporary credentials for controlled access.