SCS-C02 Infrastructure Security 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.

• ✗

  Generate an access key for an IAM user with permissions to the S3 bucket and store it in the EC2 instance.

  Why it's wrong here

  Generating a long-lived IAM access key and storing it on the EC2 instance is poor security practice because any process or user that compromises the instance can exfiltrate the static credentials and use them from anywhere. These keys do not expire, require manual rotation, and the application cannot distinguish between legitimate instance identity and malicious code running on the host. AWS recommends using temporary credentials delivered through an instance profile instead, which automatically rotate and reduce the exposure window if the instance is breached.

• ✗

  Create an S3 bucket policy that allows the EC2 instance's public IP address to access the bucket.

  Why it's wrong here

  An S3 bucket policy cannot grant access to an EC2 instance merely by its public IP address because S3 requests must be authenticated with AWS Signature v4 credentials; the policy can only act as an authorization layer over an already-authenticated principal such as an IAM role or user. While it is possible to write a bucket policy that allows anonymous access from a specific IP, that still does not supply the application with the required signing keys, and the IP may be shared or dynamic. Moreover, relying on a network location rather than an AWS identity violates least privilege and does not scale for multi-instance architectures where every instance has its own security context.

• ✓

  Create an IAM role with a policy that allows access to the specific S3 bucket, and attach the role to the EC2 instance profile.

  Why this is correct

  Creating an IAM role with a narrowly scoped policy and attaching it as the instance profile lets the EC2 instance securely obtain temporary credentials from AWS STS through the instance metadata service, with no keys embedded in the AMI or stored on disk. These credentials are rotated automatically and are valid only for a short duration, reducing the blast radius of any credentials leak. The policy can restrict actions to the specific S3 bucket (for example, s3:GetObject and s3:ListBucket), and the role's trust policy allows the EC2 service to assume it, ensuring the instance operates with least privilege and a clear audit trail in CloudTrail.

• ✗

  Use the root user's access keys to configure the application.

  Why it's wrong here

  AWS root user access keys are unrestricted master credentials that provide full administrative access to the entire account, so embedding them in an application is a catastrophic security risk because they cannot be scoped down to only the target S3 bucket. AWS best practice is to remove root user access keys entirely and instead use IAM roles or dedicated IAM users with only the necessary permissions. Additionally, root user keys are static, are not rotated automatically, and cannot be limited by service, resource, or condition, making them completely unsuitable for an EC2 workload.

Go deeper

Related to this question