DOP-C02 Configuration Management and IaC 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 Lambda function to be VPC-enabled and place it in the same subnet as the database.

  Why this is correct

  Correct. Enabling VPC integration for the Lambda function makes AWS attach a Hyperplane Elastic Network Interface directly inside your chosen subnets, so the function can communicate with the database over private IP addresses without crossing the internet. Placing the Lambda ENI in the same subnets (or at least with a valid local route to the DB subnet) lets traffic flow entirely within the VPC. You must still allow the Lambda ENI's security group in the database's security group inbound rule, and the subnets must have proper routing; this preserves the database's private posture, which is the key requirement for Secrets Manager rotation.

• ✗

  Assign a public IP address to the database and update the security group to allow access from the Lambda function.

  Why it's wrong here

  Wrong. Assigning a public IP to the database exposes the database directly to the internet, dramatically expanding the attack surface and requiring extra controls like Network ACLs and monitoring; this is a security risk and violates the principle of least privilege. Worse, it doesn't guarantee Lambda can actually reach it: a VPC-enabled Lambda has no internet path unless an Internet Gateway (or NAT with public IP) is configured, and a non-VPC Lambda has ephemeral public IPs that can't be reliably whitelisted in the security group. Thus this option both weakens security and fails to create a stable, private connection path.

• ✗

  Set up a VPC Peering connection between the Lambda service and the VPC.

  Why it's wrong here

  Wrong. VPC Peering connects two VPCs at the network layer, but the Lambda service itself is not hosted in a VPC you can peer with; Lambda execution environments run in an AWS-managed network, so there is no peering attachment to a service. You can only peer VPCs that you own (or that are shared with you), and even then the Lambda function would still need to be deployed into one of those VPCs to use the peering connection. The supported way to let Lambda reach a private database is to attach the Lambda's ENI to your VPC, not to try peering with the Lambda service.

• ✗

  Add a NAT Gateway to the VPC to allow Lambda to reach the database.

  Why it's wrong here

  Wrong. A NAT Gateway provides outbound internet connectivity from private subnets, not inbound or east-west access between a Lambda function and a database inside the same VPC. Even if you add a NAT Gateway, a non-VPC Lambda still has no ENI in your VPC and therefore cannot use private routes or the NAT at all; a VPC-enabled Lambda already has the VPC routes necessary to reach the database directly. NAT only becomes relevant if the Lambda must reach a public endpoint while also staying in the VPC, which is the opposite of what is needed for a private database.

Go deeper

Related to this question