DVA-C02 Development with AWS Services 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.

• ✓

  Launch the environment in a VPC with a NAT Gateway in a public subnet.

  Why this is correct

  This is the correct approach for instances in private subnets needing outbound internet access to third-party APIs while maintaining private IP addresses. A NAT Gateway, deployed in a public subnet, allows instances in private subnets to initiate outbound connections to the internet. All outbound traffic from these private instances will appear to originate from the NAT Gateway's Elastic IP address, providing a consistent and fixed public IP for the third-party API to whitelist, which is crucial for security policies.

• ✗

  Attach an Internet Gateway to the VPC.

  Why it's wrong here

  While an Internet Gateway (IGW) is essential for enabling general internet connectivity for a VPC, it does not inherently provide a fixed public IP address for outbound traffic originating from instances. Instances in public subnets would use their public IP or an Elastic IP, but instances in private subnets would still lack direct internet access without a NAT device. The IGW simply routes traffic between the VPC and the internet; it doesn't offer a single, stable source IP for whitelisting by external services.

• ✗

  Use a VPC endpoint for the third-party API.

  Why it's wrong here

  VPC endpoints are designed to provide private connectivity from a VPC to supported AWS services (interface endpoints) or services hosted by other AWS customers (gateway endpoints for S3/DynamoDB, or endpoint services for PrivateLink). They establish a private connection within the AWS network, bypassing the public internet entirely. A third-party API hosted outside of AWS or not explicitly offered as an AWS PrivateLink service cannot be accessed via a VPC endpoint, as it's not an AWS service.

• ✗

  Assign an Elastic IP to each EC2 instance.

  Why it's wrong here

  Assigning an Elastic IP (EIP) directly to each EC2 instance within an Elastic Beanstalk environment is generally not a recommended or practical solution. Elastic Beanstalk manages the lifecycle of EC2 instances, which are often ephemeral and scaled dynamically. Directly associating EIPs with individual instances would require complex custom scripting or manual intervention, which is outside Elastic Beanstalk's management scope, and would incur costs for unused EIPs if instances are terminated or stopped. Furthermore, it doesn't provide a single, consistent source IP for the entire application fleet.

Go deeper

Related to this question