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.

• ✗

  Configure the security group of the EC2 instance to allow outbound HTTPS traffic to S3.

  Why it's wrong here

  Security groups are stateful network filters that control traffic based on IP addresses, ports, and protocols; they do not evaluate IAM permissions or identity. While outbound HTTPS to S3 is typically allowed by the default outbound rule, even if you narrowed it to S3's prefix list this change would only affect network reachability, not the instance's ability to authenticate or authorize a PutObject call. The root cause of a denied write is the absence of an IAM policy granting s3:PutObject, not a missing network path.

• ✗

  Create a VPC endpoint for S3 in the same subnet as the EC2 instance.

  Why it's wrong here

  Creating a VPC endpoint for S3 in the same subnet provides a private, low-latency network path to S3 and can be used with bucket policies that restrict access to the endpoint. However, a VPC endpoint is an optional networking component; it does not grant the EC2 instance any IAM identity or permissions to perform s3:PutObject. Without an IAM role and a bucket policy that authorize the write, the API call will still be denied even though traffic can reach S3.

• ✓

  Add a bucket policy that allows the IAM role to perform s3:PutObject.

  Why this is correct

  Adding a bucket policy that explicitly allows the IAM role to perform s3:PutObject is a correct and often necessary step because S3 uses resource-based policies to control access at the bucket level. Even if the role has an identity-based policy permitting s3:PutObject, a bucket policy can grant the role as an explicit principal, which is particularly important in cross-account scenarios or when the bucket's AWS account uses S3 bucket owner enforced settings. In a same-account setup, this policy and the role policy work together to ensure the API call is allowed under the S3 policy evaluation model.

• ✓

  Create an IAM role with a policy that allows s3:PutObject on the bucket and attach it to the EC2 instance.

  Why this is correct

  Creating an IAM role with a policy that allows s3:PutObject on the bucket and attaching it to the EC2 instance (via an instance profile) is correct because it gives the instance temporary credentials that the AWS SDK automatically retrieves from instance metadata. This identity-based policy defines what actions the principal (the role) is permitted to perform on the bucket. Without this role and its policy, the EC2 instance has no AWS credentials or permissions, so any write attempt fails with an AccessDenied error; the role is the foundation of the authorization scheme.

• ✗

  Enable AWS CloudTrail to capture log write events.

  Why it's wrong here

  Enabling AWS CloudTrail to capture log write events is not a mechanism for granting access; CloudTrail only records API activity for auditing, monitoring, and security analysis. After the EC2 instance begins writing, CloudTrail may log s3:PutObject events and show whether they were successful, but enabling it does not alter the IAM authorization outcome. It is a detective control, not a preventive control, so it cannot help the instance gain write permissions.

Go deeper

Related to this question