Answers - A and B
This scenario requires you to set up the web servers so that the HTTPS clients must be authenticated by the client-side certificate (not the server-side certificate). There are two ways of architecting this - with ELB and without ELB. (a) With ELB, if you use HTTPS listeners, you have to deploy the server-side certificate - which is not desired. So, you need to use the TCP listener so that the HTTPS client requests do not terminate at the ELB. They pass through ELB and terminate at the webserver instances. (b) Alternatively, without ELB, you can directly use the webserver to communicate with the clients or set up a Route53 Record Set with the public IP address of the webserver(s) such that the client requests would be directly routed to the webserver(s).
Option A is CORRECT because it uses TCP (443) listener that relays requests to the backend instances as-is. This terminates the client certificate on the webserver instances rather than the ELB.Option B is CORRECT because it uses Route53 Record Set with the public IP address of the webserver(s) such that the client requests would be directly routed to the webserver(s).
Option C is INCORRECT because if you use HTTPS listeners, it does not support client certificates. HTTPS connections are terminated on the ELB rather than the backend web server instances.
Option D is incorrect because this setting should be an "origin" and not a "target". The phrase should be "Configure your web servers as the origins for a CloudFront distribution"
Please check below AWS docs for more details
https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/ssl-server-cert.html
https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-create-https-ssl-load-balancer.html#create-https-lb-console
Please refer to the following link to TCP to pass through traffic to the ELB "as-is"
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/https-tcp-passthrough.html