DOP-C02 SDLC 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.

• ✗

  Place the RDS instance in a public subnet with a public IP.

  Why it's wrong here

  Placing the RDS instance in a public subnet and assigning it a public IP directly exposes the database to the internet, which violates security best practices and is unnecessary for CodeBuild connectivity. Even with a public IP, CodeBuild would still need a routable path and would typically require a NAT gateway or internet gateway for outbound traffic, but this approach introduces a severe attack surface without resolving the core networking issue. RDS instances should reside in private subnets, with access controlled through security groups and VPC routing.

• ✓

  Ensure the security group attached to the RDS instance allows inbound traffic from the CodeBuild security group.

  Why this is correct

  Security groups act as a virtual firewall at the instance level. By referencing the CodeBuild project's security group as a source in the RDS security group's inbound rule, you allow traffic specifically from the Elastic Network Interfaces (ENIs) that CodeBuild uses when it runs inside the VPC. This is the most direct and least-privileged way to permit the integration tests to reach RDS, because it avoids opening the database to CIDR ranges or the entire VPC. It also updates automatically if CodeBuild's IP addresses change, as long as the security group ID remains the same.

• ✗

  Attach a NAT gateway to the VPC so that CodeBuild can route to RDS.

  Why it's wrong here

  A NAT gateway enables outbound internet connectivity from private subnets, allowing resources like CodeBuild to reach public endpoints (e.g., package registries or external APIs). It does not establish or improve routing between two private resources within the same VPC; RDS and CodeBuild communicate using VPC-internal routes and security groups. Adding a NAT gateway would neither help CodeBuild reach RDS nor mitigate any security group misconfiguration, so it is an unnecessary and costly addition.

• ✓

  Ensure the VPC's route tables have routes to allow traffic between CodeBuild subnets and RDS subnets.

  Why this is correct

  VPC route tables determine how traffic is forwarded between subnets and network boundaries. For CodeBuild (running in one or more subnets) to reach RDS (in possibly different subnets) within the same VPC, the route tables must contain entries that cover the destination RDS subnets' CIDR ranges; typically the local VPC route already provides this if both subnets are in the same VPC. If the local route is missing or the subnets are in different VPCs, explicit routes would be needed, but with a standard single-VPC setup this is usually already satisfied. This option is correct as a prerequisite, but it is not the sole control: the security group inbound rule is still required to authorize the traffic, making the security group configuration the definitive fix.

• ✓

  Configure the CodeBuild project to use a VPC that has access to the RDS instance.

  Why this is correct

  For CodeBuild to access private resources like an RDS instance, the build project must be configured to run in a VPC. CodeBuild then creates ENIs in the specified subnets and uses those subnets' route tables and the VPC's security groups for network access. Without VPC configuration, CodeBuild runs in AWS-managed infrastructure outside your VPC and cannot reach a private RDS endpoint, even with network ACLs or security groups permitting traffic. This is a foundational step—you must associate the CodeBuild project with the VPC that contains the RDS instance before any security group or route table rules can take effect.

Go deeper

Related to this question