I agree with the suggested answer of BDE.
Here's a detailed breakdown of why these options are correct and why the others are not, based on AWS best practices and security considerations:

Option B: Create a certificate for service.example.com by using AWS Certificate Manager (ACM). Configure CloudFront to use this custom SSL/TLS certificate. Change the default behavior to redirect HTTP to HTTPS.

Reasoning: This is correct because ACM simplifies the management of SSL/TLS certificates for use with AWS services, including CloudFront. Using ACM to create a certificate for your domain (service.example.com) ensures that the certificate is trusted by browsers. Configuring CloudFront to use this certificate and redirecting HTTP to HTTPS enforces encryption for all traffic between users and CloudFront.

Option D: Create a public certificate from a third-party certificate provider with any domain name for the EC2 instances. Configure the backend to use this certificate for its HTTPS listener. Specify the instance target type during the creation of a new target group that uses the HTTPS protocol for its targets. Attach the existing Auto Scaling group to this new target group.

Reasoning: This is correct. While ACM is preferred, using a public certificate from a trusted third-party provider is also a valid method for securing the connection to the EC2 instances. Configuring the ALB to listen on HTTPS and using a target group with the HTTPS protocol ensures the traffic to the backend is encrypted. Specifying the instance target type and attaching the Auto Scaling group to the new target group ensures proper routing of traffic.

Option E: Create a certificate for service-alb.example.com by using AWS Certificate Manager (ACM). On the ALB add a new HTTPS listener that uses the new target group and the service-alb.example.com ACM certificate. Modify the CloudFront origin to use the HTTPS protocol only. Delete the HTTP listener on the ALB.

Reasoning: This option correctly addresses the need to encrypt traffic between CloudFront and the ALB. Creating an ACM certificate for the ALB's domain (service-alb.example.com) and configuring an HTTPS listener with that certificate ensures encryption in transit. Modifying the CloudFront origin to use HTTPS and deleting the HTTP listener enforces encryption and prevents unencrypted traffic.

Option A: Create a self-signed certificate for service.example.com. Import the certificate into AWS Certificate Manager (ACM). Configure CloudFront to use this imported SSL/TLS certificate. Change the default behavior to redirect HTTP to HTTPS.

Reasoning: This is incorrect because CloudFront does not support self-signed certificates. Self-signed certificates are not trusted by browsers, leading to security warnings. ACM is designed to work with trusted certificates, and while you can import certificates into ACM, self-signed certificates are not a viable solution for public-facing websites.

Option C: Create a certificate with any domain name by using AWS Certificate Manager (ACM) for the EC2 instances. Configure the backend to use this certificate for its HTTPS listener. Specify the instance target type during the creation of a new target group that uses the HTTPS protocol for its targets. Attach the existing Auto Scaling group to this new target group.

Reasoning: This is incorrect because ACM certificates are designed to be used with AWS services like ELB (ALB), CloudFront, and API Gateway, not directly on EC2 instances unless using a Nitro Enclave. While configuring an HTTPS listener on the ALB is correct (covered in option E), the premise of directly using an ACM certificate on the EC2 instance is flawed.

Option F: Create a self-signed certificate for service-alb.example.com. Import the certificate into AWS Certificate Manager (ACM). On the ALB add a new HTTPS listener that uses the new target group and the imported service-alb.example.com ACM certificate. Modify the CloudFront origin to use the HTTPS protocol only. Delete the HTTP listener on the ALB.

Reasoning: This is incorrect because self-signed certificates should not be used with public-facing services. While it’s possible to import a self-signed certificate into ACM, doing so will not make it trusted by client browsers. CloudFront and browsers expect certificates signed by a trusted Certificate Authority (CA). Using a self-signed certificate in this scenario would result in browser warnings and a broken security posture.

In summary, options B, D, and E provide a comprehensive solution for ensuring end-to-end encryption, leveraging ACM and proper ALB configuration to secure traffic between users, CloudFront, and the backend EC2 instances.

Suggested Answer: BDE

Citations:

AWS Certificate Manager (ACM), https://aws.amazon.com/certificate-manager/
Securing CloudFront with HTTPS, https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html
Application Load Balancer Listener Configuration, https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html