Question
A DevOps engineer is creating an AWS CloudFormation template to deploy a web service. The web service will run on Amazon EC2 instances in a private subnet behind an Application Load Balancer (ALB). The DevOps engineer must ensure that the service can accept requests from clients that have IPv6 addresses.
What should the DevOps engineer do with the CloudFormation template so that IPv6 clients can access the web service?
- A. Add an IPv6 CIDR block to the VPC and the private subnet for the EC2 instances. Create route table entries for the IPv6 network, use EC2 instance types that support IPv6, and assign IPv6 addresses to each EC2 instance.
- B. Assign each EC2 instance an IPv6 Elastic IP address. Create a target group, and add the EC2 instances as targets. Create a listener on port 443 of the ALB, and associate the target group with the ALB.
- C. Replace the ALB with a Network Load Balancer (NLB). Add an IPv6 CIDR block to the VPC and subnets for the NLB, and assign the NLB an IPv6 Elastic IP address.
- D. Add an IPv6 CIDR block to the VPC and subnets for the ALB. Create a listener on port 443, and specify the dualstack IP address type on the ALB. Create a target group, and add the EC2 instances as targets. Associate the target group with the ALB. Correct
Explanation
The correct answer is D. For IPv6 clients to reach the web service, only the internet-facing ALB needs an IPv6 address: add an IPv6 CIDR block to the VPC and to the ALB's subnets, and set the ALB's IP address type to dualstack so it accepts both IPv4 and IPv6 requests. A listener on port 443 and a target group containing the EC2 instances complete the setup; the ALB keeps reaching the instances in the private subnet over IPv4. Option A gives the instances IPv6 addresses but does not make the ALB accept IPv6 clients. Option B is wrong because there are no IPv6 Elastic IP addresses and the ALB would still be IPv4-only. Option C is unnecessary, because an ALB supports dualstack and does not need to be replaced.
