SOA-C02 Security and Compliance Practice Question
An application running on an Amazon EC2 instance needs to access an Amazon S3 bucket. The company security policy requires that credentials are not stored on the instance. What is the most secure way to grant access?
⚠ Common exam trap
Watch out — candidates often think storing keys in environment variables or configuration files is acceptable because they are 'hidden' or 'temporary,' but the exam emphasizes that any form of long-term credential storage on the instance violates the principle of least privilege and the security policy.
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 permissions and attach it to the EC2 instance profile.
Attaching an IAM role to an EC2 instance via an instance profile allows the instance to obtain temporary security credentials from the AWS Security Token Service (STS). These credentials are automatically rotated and never stored on the instance, satisfying the security policy requirement. The EC2 instance retrieves the credentials through the instance metadata service (IMDS), eliminating the need for long-term access keys.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create an IAM role with S3 access permissions and attach it to the EC2 instance profile.
Why this is correct
Attaching an IAM role to the EC2 instance profile is the recommended pattern because the instance retrieves temporary, automatically rotating credentials from the instance metadata service (IMDSv2). These credentials are scoped by the role's trust policy and S3 permissions, so no long-lived access keys are ever written to disk, code, or configuration files. The AWS SDKs and CLI automatically assume the role, enabling secure access to S3 without manual credential management.
- ✗
Generate an access key and secret key for an IAM user, then store them in a configuration file on the instance.
Why it's wrong here
Generating an access key and secret key and saving them in a file on the instance embeds long-term IAM user credentials in a static location, which is a security risk if the instance is compromised or the AMI is copied. These credentials do not rotate unless manually rotated, and their exposure can lead to unauthorized use outside the instance. This approach also violates the principle of least privilege because the IAM user would typically have broader permissions than a narrowly scoped role, and it bypasses the best practice of using instance profiles for EC2 workloads.
- ✗
Create an S3 bucket policy that allows access from the instance's public IP address.
Why it's wrong here
An S3 bucket policy that grants access based on the instance's public IP address does not authenticate the principal; any user or resource with that IP could inherit the permission, and the public IP of an EC2 instance can change after stop/start or when using public IPv4 with certain network configurations. This approach also fails when the instance uses a NAT gateway or VPC endpoint without a stable public IP, and it ignores IAM's identity-based authentication, making it an insecure and brittle authorization method. The bucket policy could be used to restrict access to a VPC endpoint, but not to verify the instance's identity.
- ✗
Define the access keys as environment variables in the user data script when launching the instance.
Why it's wrong here
Defining access keys in environment variables within the user data script means the secret keys are visible in the instance's user-data, which is retrievable from the AWS API by anyone with ec2:DescribeInstanceAttribute permissions, and they also remain in the instance's process environment and shell history. These long-term credentials are not rotated and are shared with every process running on the instance, increasing the attack surface. The AWS SDKs might also log or persist them in credential caches, and storing credentials in user data clearly violates the AWS security best practice of no long-term keys on EC2 instances.
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
Related to this question
About these practice questions
One of 1,169 original SOA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.