SCS-C02 Identity and Access Management Practice Question

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 IAM user access keys in a configuration file on the EC2 instance.

  Why it's wrong here

  Storing IAM user access keys in a configuration file is insecure because long-term credentials remain valid indefinitely and are difficult to rotate. If the file is exposed through a misconfigured user-data script, a snapshot, or a compromised dependency, an attacker can use those keys to access S3 from anywhere. This approach also requires manual credential management on every instance, whereas IAM roles provide automatic, temporary credentials through the instance metadata service.

• ✗

  Use a security group to allow the EC2 instance to access S3.

  Why it's wrong here

  Security groups are stateful virtual firewalls that filter traffic at the elastic network interface level, and they operate within a VPC; they do not govern API-level authorization for AWS services. S3 bucket access is granted via IAM policies or bucket policies, not by network rules. Even if you wanted to use a VPC gateway endpoint for S3, that requires a route-table entry and an endpoint policy, not a security group. The security group cannot allow an EC2 instance to call S3 APIs because S3 is a global AWS service with HTTP(S) endpoints, not a resource inside the VPC.

• ✗

  Attach an S3 bucket policy that grants access to the EC2 instance ID.

  Why it's wrong here

  An S3 bucket policy can only grant permissions to IAM principals, such as an IAM user, role, or federated identity; an EC2 instance ID is not a valid principal. The Principal field in a bucket policy must reference an IAM entity, and any attempt to put an instance ID there will be rejected as invalid. Moreover, a bucket policy cannot be used to authenticate a request; authentication must be done with IAM credentials, which an instance can only obtain by assuming an IAM role.

• ✓

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

  Why this is correct

  Create an IAM role with an S3 access policy, then place that role in an instance profile and attach the profile to the EC2 instance at launch or via the console/API. When the instance starts, it uses the role's trust policy to assume the role and receives temporary credentials from the instance metadata service (IMDSv1 or IMDSv2) that are automatically rotated. The SDK then uses these credentials to sign requests to S3 for the duration of the role session, enforcing the exact permissions granted by the role while avoiding the need to embed static keys.

Go deeper

Related to this question