-
Hi mohans49,
Great question! The key is to carefully align the scenario with what each option provides. The requirement in the question is to launch a web application served globally through CloudFront, with an EC2 instance acting as the origin to process and serve dynamic content, and to ensure high availability for that application.
Option 3 is the correct answer because provisioning two EC2 instances in different Availability Zones and configuring them as part of an origin group directly addresses high availability at the origin layer. By having instances in multiple AZs, you remove the single point of failure that exists with a single EC2 origin. If one instance or even an entire Availability Zone goes down, CloudFront can route traffic to the other healthy origin. This setup ensures that the application remains available to users while still serving dynamic content, which is critical since the workload cannot be offloaded to something like S3. CloudFront origin groups are designed to provide automatic failover between multiple origins.
Option 4, on the other hand, is not correct because Lambda@Edge is not an origin. Lambda@Edge runs at CloudFront edge locations to customize requests and responses, enforce security, or add business logic closer to users, but it cannot host or serve your application’s dynamic content. It cannot be configured as a member of an origin group, since origin groups are strictly for actual origins like EC2, ALB, or S3. Even if you use Lambda@Edge for performance enhancements, you would still need redundant EC2 origins to achieve the level of availability described in the question.
So, while Lambda@Edge improves performance and customization, it does not solve the underlying requirement for high origin availability. Option 3 is the only choice that directly fulfills the question.
Cheers,
Nikee @ Tutorials Dojo
