SOA-C02 Deployment, Provisioning, and Automation 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.

• ✗

  Attach an internet gateway to the VPC to provide internet access.

  Why it's wrong here

  Attaching an internet gateway (IGW) to the VPC will not automatically make S3 accessible to CodeBuild unless the VPC route table has a 0.0.0.0/0 route to the IGW and the CodeBuild subnets have public IPs or a NAT device—but even then, S3 traffic would traverse the public internet, introducing additional exposure and still requiring the bucket policy to permit access from that public path. The question indicates that CodeBuild is running in the VPC and failing to reach S3, and the correct architecture is to use a VPC endpoint for S3 to keep the traffic private. An IGW is not needed for S3 access because an S3 VPC endpoint provides the required connectivity without an internet route, and adding an IGW could actually create unintended internet egress for the build environment.

• ✗

  Configure the security group for CodeBuild to allow outbound traffic to the S3 bucket.

  Why it's wrong here

  Security groups control traffic at the instance or elastic network interface level, but Amazon S3 is a regional service accessed through an HTTPS endpoint (like s3.amazonaws.com or a bucket-specific endpoint) and is not a resource that can be directly addressed by a security group rule. Even if the CodeBuild VPC security group already permits all outbound HTTPS traffic, the request cannot reach S3 because the VPC lacks a route to S3's public IP ranges—a security group rule does not create a network path. The issue is that CodeBuild in a VPC is not routing traffic to S3, so modifying the outbound security group rules cannot resolve the connectivity failure.

• ✓

  Create a VPC endpoint for Amazon S3 and associate it with the VPC where CodeBuild runs.

  Why this is correct

  Creating a VPC endpoint for Amazon S3 (gateway or interface type) and associating it with the VPC where CodeBuild runs gives the build container a private, routable path to S3 without traversing the public internet. Because CodeBuild runs inside the VPC on elastic network interfaces, outbound traffic to S3 will only succeed if the VPC has a route to S3 via a gateway endpoint or a NAT/internet gateway. The gateway endpoint uses prefix lists to route S3 traffic within the AWS network, which resolves the access denied error caused by the lack of network connectivity. This is the intended fix because the root cause is a network routing problem, not missing IAM permissions or security group misconfiguration.

• ✗

  Update the IAM role to include 's3:ListBucket' permission.

  Why it's wrong here

  Updating the IAM role to include 's3:ListBucket' is unnecessary because downloading a specific source artifact only requires s3:GetObject on the object key, and the existing role presumably already has that permission. The 's3:ListBucket' action allows the caller to enumerate the contents of a bucket, which is irrelevant when CodeBuild is fetching a known source zip from the CodeCommit-to-S3 pipeline. The reported access denied error is actually a network connectivity problem: CodeBuild running in a private VPC cannot reach S3 without a VPC endpoint or an internet route, regardless of IAM permissions. Adding this permission would not fix the failure because the request is being denied due to the network path, not an authorization policy.

Go deeper

Related to this question