SOA-C02 Deployment, Provisioning, and Automation Practice Question

A SysOps administrator is tasked with automating the provisioning of EC2 instances that must be able to access an Amazon S3 bucket. The administrator needs to ensure that the instances have the necessary permissions without using long-term access keys. Which TWO actions should the administrator take? (Choose TWO.)

⚠ Common exam trap

The trap is that candidates may pick 'store keys in Parameter Store' as a 'secure' alternative, not realizing it still relies on long-term credentials and misses the point that IAM roles provide keyless, rotating credentials natively.

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

✓

Attach the IAM role to the EC2 instances using an instance profile.

Option D is correct because an IAM role is the identity that carries the S3 permission policy, and it is the prerequisite for granting temporary credentials to EC2. Option B is correct because the role must be delivered to the instances through an instance profile, which lets the EC2 instance metadata service (IMDS) vend rotating temporary credentials via AWS STS, satisfying the no-long-term-keys requirement. Option A is wrong because storing AWS access keys in a configuration file uses long-term credentials, which the scenario explicitly forbids. Option C is wrong because an S3 bucket policy cannot meaningfully grant access based on an instance's private IP address, which is not a valid principal identifier for EC2. Option E is wrong because Systems Manager Parameter Store is a secrets storage mechanism, not an automatic credential provider, so instances would still need long-term keys to retrieve the values.

Answer analysis

Option-by-option breakdown

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

✗
Store AWS access keys in a configuration file on the instances.
Why it's wrong here
Storing AWS access keys in a configuration file on the instances is a poor practice because it embeds long-lived, static credentials directly into the environment. If the file is exposed (e.g., via a misconfigured web server, logs, or a shared AMI), an attacker gains persistent access to the S3 bucket, and the admin must manually rotate keys across every instance. This approach also bypasses the AWS-recommended mechanism of temporary credentials and creates a significant operational and security burden.
✓
Attach the IAM role to the EC2 instances using an instance profile.
Why this is correct
Attaching an IAM role to the EC2 instances using an instance profile is the correct, secure mechanism for granting access to S3. When a role is attached, the instance can retrieve temporary, automatically rotating credentials from the instance metadata service (IMDSv2), which are assumed via STS. This eliminates the need to distribute or manage long-term access keys, reduces the risk of credential exposure, and simplifies permission updates because changes to the role policy take effect immediately for all associated instances.
✗
Create an S3 bucket policy that allows access from the instances' private IP addresses.
Why it's wrong here
Creating an S3 bucket policy that allows access from the instances' private IP addresses does not authenticate the instances or provide them with AWS credentials; S3 API requests require valid signatures from IAM principals. Private IP addresses can be reused across different AWS accounts or VPCs, making this an unreliable and insecure mechanism. Even if a VPC endpoint restricts access, the bucket policy still needs to reference an IAM principal (e.g., a role or condition with aws:SourceVpc), not merely an IP address, to authorize instance access.
✓
Create an IAM role that grants the necessary S3 permissions.
Why this is correct
Creating an IAM role that grants the necessary S3 permissions is a fundamental step in the correct solution because the role defines the scope of access (e.g., GetObject, ListBucket) and the trust policy that allows EC2 to assume it. This role acts as the IAM principal for all S3 requests, and when combined with an instance profile, it enables the instances to securely obtain temporary credentials. Without this role, there are no permissions to attach to an instance profile, so the role is a prerequisite for the entire automation workflow.
✗
Store the access keys in AWS Systems Manager Parameter Store.
Why it's wrong here
Storing access keys in AWS Systems Manager Parameter Store is better than storing them in a file, but it still involves managing long-term keys and is not as secure or seamless as using an IAM role.

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

SOA-C02 Deployment, Provisioning, and Automation Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question