EC2 Access Keys and IAM Roles – SAP-C02 Study Guide

Purpose of This Lesson

An EC2 instance does not automatically inherit the AWS permissions of the person who launched or connected to it. Applications and commands running on the instance need their own AWS identity.

This lesson demonstrates two approaches:

• Configuring static IAM user access keys on the instance.
• Attaching an IAM role to the EC2 instance, which is the recommended approach.

The key architectural lesson is to avoid storing long-term credentials on compute resources whenever an IAM role can provide temporary credentials instead.

Key Concepts

Operating-system identity and AWS identity are different

A Linux user such as ec2-user controls access within the operating system. It does not automatically have permission to call AWS APIs.

AWS API authorization is based on an AWS identity, such as:

• An IAM user with access keys.
• An IAM role assumed by an AWS service, application, or federated principal.
• Temporary credentials issued through AWS Security Token Service (AWS STS).

Therefore, the fact that an administrator can access the AWS console does not mean commands run on an EC2 instance can access AWS services.

Access keys and aws configure

An IAM user access key consists of an access key ID and a secret access key. The AWS CLI can use these values when configured with:

aws configure

The CLI commonly stores configuration in:

• ~/.aws/config for settings such as the default Region.
• ~/.aws/credentials for access keys and named profiles.

A command such as the following uses the configured credentials to call Amazon S3:

aws s3 ls

Static access keys are risky on EC2 because they are long-lived credentials. Anyone who obtains them may be able to perform actions permitted by the associated IAM user. The credentials can also be exposed through backups, AMIs, logs, shell history, configuration management systems, or a compromised operating-system account.

IAM roles for EC2

An IAM role is an AWS identity designed to be assumed temporarily. When a role is attached to an EC2 instance, the EC2 service obtains temporary credentials for the role and makes them available to applications running on the instance through the Instance Metadata Service (IMDS).

The AWS SDKs and CLI can automatically retrieve and refresh these credentials. No long-term access key needs to be placed in a file on the instance.

A role has two important policy areas:

1. Trust policy: Defines who or what can assume the role. For an EC2 instance profile, the trusted principal is generally the EC2 service, represented by ec2.amazonaws.com.
2. Permissions policy: Defines which AWS API actions the role can perform, such as read-only access to Amazon S3.

A role is attached to EC2 through an instance profile. In the console, this is commonly presented as attaching an IAM role to the instance, while the underlying EC2 association is an instance profile.

Role permissions and least privilege

If an EC2 instance needs to list or read objects from S3, attach a narrowly scoped policy rather than broad administrator permissions. For production systems, restrict access by:

• Specific S3 bucket and object ARNs.
• Required API actions.
• Resource tags or other conditions where appropriate.
• Encryption and data-access requirements.

For example, an application that only downloads configuration files should not receive unrestricted S3 access.

Credential provider precedence

The AWS CLI and SDKs can obtain credentials from several sources, including environment variables, shared credential files, and the EC2 instance metadata service. A static credential source may take precedence over the instance role depending on the SDK or CLI credential-provider chain.

If an instance role appears not to be working, check for stale environment variables or files under ~/.aws that are overriding role credentials.

Exam-Relevant Takeaways

• Use an IAM role attached to an EC2 instance instead of creating or distributing IAM user access keys.
• IAM roles provide temporary, automatically rotated credentials through AWS STS.
• Access keys configured with aws configure are long-term credentials unless rotated or deactivated.
• The trust policy controls who can assume a role; the permissions policy controls what the role can do.
• An EC2 role must trust the EC2 service.
• The role must be attached to the instance through an instance profile.
• An EC2 instance does not inherit the permissions of the IAM user who launched it or connected through EC2 Instance Connect.
• An IAM role does not bypass resource policies, explicit denies, SCPs, permission boundaries, or other applicable authorization controls.
• If credentials are exposed, deactivate or delete the access key and investigate possible use. Removing the local file alone does not invalidate a key that may already have been copied.
• Prefer IMDSv2 for instance metadata access and protect the metadata service from SSRF-style attacks.

Architecture Decision Guide

Requirement	Recommended approach	Reason
EC2 application needs to call S3, SQS, DynamoDB, or another AWS service	Attach an IAM role to the instance	Temporary credentials without storing secrets on disk
Human administrator needs command-line access from a workstation	IAM Identity Center or another federated identity solution	Centralized authentication and short-lived credentials
A legacy external system requires programmatic IAM credentials	Use a dedicated IAM principal with narrowly scoped, rotated access keys, or federation if supported	Limits blast radius when roles cannot be used
A workload in one AWS account needs access to another account	Use a cross-account IAM role and sts:AssumeRole	Avoids sharing access keys between accounts
EC2 role is attached but the CLI still uses old credentials	Inspect environment variables and ~/.aws profiles	Credential-provider precedence may override IMDS credentials
Instance must access metadata	Require IMDSv2 and restrict metadata access	Reduces credential-exfiltration risk

Common Exam Traps

• Confusing console permissions with instance permissions: The user launching an instance and the application running on that instance are separate security principals.
• Treating an access key as harmless configuration: The access key ID is not secret by itself, but the secret access key is highly sensitive. Together they can authorize AWS API calls.
• Focusing only on the permissions policy: A role also requires a compatible trust policy. If EC2 is not trusted, the instance cannot use the role.
• Assuming role credentials are permanently stored on disk: EC2 role credentials are temporary and retrieved through metadata; applications should use the SDK or CLI provider chain.
• Attaching an IAM policy directly to an instance: Policies are attached to IAM users, groups, or roles. EC2 receives a role through an instance profile.
• Deleting a local credentials file and considering the incident resolved: The key may have been copied or used already. Deactivate or delete the IAM access key and review CloudTrail activity.
• Granting administrator access for convenience: SAP-C02 scenarios generally favor least privilege and resource-scoped policies.
• Forgetting service and resource policies: An identity policy alone may not grant access if the resource policy, SCP, KMS key policy, or explicit deny prevents it.

Real-World Engineer Notes

• Enable CloudTrail and monitor for unusual use of IAM access keys, especially from unexpected Regions or IP addresses.
• Do not place access keys in AMIs, user data, source repositories, container images, or application configuration files.
• Use AWS Secrets Manager or Systems Manager Parameter Store for secrets that genuinely cannot be replaced by IAM authorization. These services do not make static credentials a preferred solution when an instance role is sufficient.
• Use separate roles for separate workloads. A web server, batch processor, and deployment agent usually should not share one broadly privileged role.
• When changing an instance role, verify both the attached instance profile and the role’s trust and permissions policies.
• Use aws sts get-caller-identity to determine which AWS principal the CLI is actually using:

aws sts get-caller-identity

• If a role is not being used, check AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_PROFILE, shared credential files, and application-specific credential configuration.
• Restrict access to IMDS from applications that do not need it, and configure instances to require IMDSv2.

Quick Reference Summary

• Access keys: Long-term IAM user credentials; avoid storing them on EC2.
• IAM role: AWS identity with temporary credentials and a trust policy.
• Instance profile: EC2 container that associates a role with an instance.
• Trust policy: Defines who can assume the role.
• Permissions policy: Defines permitted AWS API actions and resources.
• IMDS: Provides instance metadata and temporary role credentials to the instance.
• Best practice: Attach a least-privilege IAM role to EC2 and let the AWS CLI or SDK retrieve credentials automatically.
• Incident response: Deactivate or delete exposed access keys, investigate CloudTrail, and replace any affected credentials.

Flashcards

1. Q: Does an EC2 instance inherit the AWS permissions of the user who launched it?

A: No. The instance needs its own AWS identity, typically an attached IAM role.

1. Q: What two values make up an IAM access key credential?

A: An access key ID and a secret access key.

1. Q: Why are static access keys dangerous on EC2?

A: They are long-lived and can be exposed through files, images, logs, backups, or a compromised host.

1. Q: What is the recommended way for an EC2 application to call AWS APIs?

A: Use an IAM role attached to the instance.

1. Q: What does an IAM role trust policy define?

A: Which principal is allowed to assume the role.

1. Q: What does an IAM role permissions policy define?

A: The actions and resources the role is authorized to access.

1. Q: Which AWS service issues temporary role credentials?

A: AWS Security Token Service (AWS STS).

1. Q: Where does EC2 expose role credentials to applications?

A: Through the EC2 Instance Metadata Service.

1. Q: What EC2 construct associates an IAM role with an instance?

A: An instance profile.

1. Q: What command identifies the principal currently used by the AWS CLI?

A: aws sts get-caller-identity.

Practice Questions

Question 1

A company runs an application on EC2 that reads objects from one S3 bucket. Developers currently store an IAM user access key in the application configuration file. The security team wants to eliminate long-lived credentials and enforce least privilege. What is the best solution?

A. Store the access key in the EC2 user’s home directory with restrictive file permissions.
B. Attach an IAM role to the EC2 instance with a policy allowing read access to the required S3 bucket.
C. Add the EC2 instance’s public IP address to the S3 bucket policy.
D. Create an administrator role and configure it with aws configure.

Correct answer: B

Explanation: An EC2 instance role supplies temporary credentials through IMDS and can be restricted to the required S3 resources. File permissions do not eliminate the risk of long-lived credentials, and an IP address does not provide an appropriate workload identity.

Question 2

An EC2 instance has an IAM role attached, but aws s3 ls continues to use an old IAM user identity. What is the most likely cause?

A. EC2 roles cannot be used by the AWS CLI.
B. The instance must have a public IP address to use a role.
C. Environment variables or a shared credentials file are taking precedence over instance metadata credentials.
D. The IAM role must contain an access key ID and secret access key.

Correct answer: C

Explanation: The CLI may select credentials from environment variables or configured profiles before querying IMDS. Inspect and remove stale credentials or explicitly select the intended profile/provider behavior.

Question 3

An architect creates an IAM role with read-only access to Amazon S3 and attaches it to an EC2 instance. The instance cannot assume the role. Which policy should be checked first?

A. The role trust policy.
B. The S3 bucket lifecycle policy.
C. The VPC route table.
D. The IAM user’s password policy.

Correct answer: A

Explanation: The trust policy must allow the EC2 service principal to assume the role. The permissions policy controls what the role can do after assumption, but it does not establish who may assume it.

Question 4

An IAM access key used on an EC2 instance is accidentally committed to a public repository. What should be done first?

A. Delete the repository file only.
B. Reboot the EC2 instance.
C. Deactivate or delete the exposed access key, then investigate usage and replace credentials if necessary.
D. Restrict the instance security group to SSH from the corporate network.

Correct answer: C

Explanation: Anyone may have copied the key, so removing the file does not invalidate it. Immediately deactivate or delete the key, review CloudTrail and related telemetry, and migrate the workload to an IAM role.

Question 5

A workload in Account A must read a private S3 bucket in Account B. The company does not want to distribute Account B access keys. Which design is most appropriate?

A. Copy Account B access keys into the EC2 AMI.
B. Create a cross-account IAM role in Account B that the workload in Account A can assume.
C. Make the S3 bucket public.
D. Attach an IAM user policy in Account A referencing Account B without any trust relationship.

Correct answer: B

Explanation: A cross-account role uses AWS STS and an explicit trust relationship, avoiding shared long-term credentials. The role’s permissions and the bucket policy must both allow the intended access, subject to any applicable SCPs or explicit denies.