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.

• ✗

  Create an IAM user with programmatic access and use those credentials in the application.

  Why it's wrong here

  Creating an IAM user with programmatic access produces a static access key ID and secret access key. Storing those credentials on an EC2 instance means they are long-lived secrets that require manual rotation and careful safeguarding, and any successful attack on the instance exposes them. This approach also forces separate credential management for each instance and completely bypasses AWS's temporary credential infrastructure, which is why it is not the recommended pattern.

• ✗

  Configure a security group that allows outbound traffic to the S3 bucket.

  Why it's wrong here

  Security groups control network traffic at the instance level, filtering by IP address and port, but they do not enforce API-level authorization. An S3 bucket is not a security group member; access to S3 is granted through IAM policies, bucket policies, or S3 access points. Even if an outbound security group rule allows HTTPS traffic to S3 endpoints, the application will still receive a 403 if it lacks valid AWS credentials to sign the request, so this option cannot grant S3 access.

• ✓

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

  Why this is correct

  Attaching an IAM role with the appropriate S3 access policy to the EC2 instance profile enables the instance to obtain temporary credentials from AWS STS via the instance metadata service (IMDSv2). The AWS SDK automatically retrieves and rotates these credentials, meaning the application never stores or manages long-lived keys. This follows the principle of least privilege and is the AWS-recommended pattern for granting EC2 instances access to S3, because it ties permissions to the instance itself rather than to a user or stored key.

• ✗

  Store AWS access keys in a configuration file on the EC2 instances.

  Why it's wrong here

  Storing AWS access keys in a configuration file on the EC2 instances hard-codes static credentials into the filesystem, making them vulnerable to accidental exposure, insider threats, or compromise via exploits like directory traversal or local file read. Unlike an IAM role, these keys do not auto-rotate and remain valid until manually revoked, requiring a cumbersome rotation process across all instances. This practice also couples the application to a single user identity, complicating audit trails and minimizing the ability to revoke permissions per instance without deactivating shared keys.

Go deeper

Related to this question