SCS-C02 Identity and Access Management Practice Question

A developer needs to run an application on an EC2 instance that accesses an S3 bucket. What is the best practice for granting permissions?

⚠ Common exam trap

SCS-C02 often tests the misconception that SCPs or bucket policies can directly grant permissions to EC2 instances, or that long-term access keys are acceptable for instance-based access, when the best practice is always to use IAM roles for EC2.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Create an IAM role with S3 access and attach it to the EC2 instance profile.

Attaching an IAM role to an EC2 instance profile provides temporary, automatically rotated credentials to the instance, eliminating the need to hardcode or manage long-term access keys. This follows the AWS best practice of using IAM roles for EC2 to grant least-privilege permissions to AWS services like S3. The instance profile acts as a container for the role and allows the EC2 instance to assume it, with credentials delivered via the Instance Metadata Service (IMDS).

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Use an SCP to allow S3 access for the instance.
Why it's wrong here
SCPs are governance tools that operate at the AWS Organizations level to restrict the maximum permissions for accounts or OUs—they cannot grant permissions to a resource like an EC2 instance. Even if you attached an SCP that allows S3 actions, it only sets a guardrail for principals in the account; the instance itself is not an IAM principal, so no S3 access is granted.
✗
Create a bucket policy that grants access to the instance ID.
Why it's wrong here
Amazon S3 bucket policies require a valid IAM principal (such as an IAM user, role, or account root) in the Principal element—an EC2 instance ID is not a recognized principal. AWS never evaluates requests as coming from an instance ID; the actual principal is the IAM role or access keys used by the instance, so this policy would be rejected or simply ineffective.
✗
Store AWS access keys on the instance and use them in the application.
Why it's wrong here
Storing long-term AWS access keys directly on an EC2 instance is a serious security risk because keys can be exfiltrated from the instance filesystem, require manual rotation, and are not automatically scoped to the instance's lifecycle. Best practice dictates using temporary credentials from STS via an instance profile role, which prevents the exposure of permanent, highly privileged keys and reduces the blast radius if the instance is compromised.
✓
Create an IAM role with S3 access and attach it to the EC2 instance profile.
Why this is correct
This is the correct approach because an IAM role attached to an EC2 instance profile securely provides the instance with temporary credentials through the instance metadata service. The role enforces least-privilege permissions for S3, automatically rotates credentials, and eliminates the need to embed long-term keys, aligning with AWS security best practices and following the principle of granting only the required access.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

SCS-C02 Identity and Access Management Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question