Q5 — AWS SAP-C02 Ch.1
Question 5 of 75 | ← Chapter 1
Q80. A company is refactoring its on-premises order-processing platform in the AWS Cloud. The platform includes a web front end that is hosted on a fleet of VMs, RabbitMQ to connect the front end to the backend, and a Kubernetes cluster to run a containerized backend system to process the orders. The company does not want to make any major changes to the application. Which solution will meet these requirements with the LEAST operational overhead? 2022032562
- A. Create an AMI of the web server VM. Create an Amazon EC2Auto Scaling group that uses the AMI and an Application Load Balancer. Set up Amazon MQ to replace the on-premises messaging queue.Configure Amazon Elastic Kubernetes Service (Amazon EKS) to host the order-processing backend. ✓
- B. Create a custom AWS Lambda runtime to mimic the web server environment. Create an Amazon API Gateway API to replace the front-end web servers, Set up Amazon MQ to replace the on-premises messaging queue. Configure Amazon Elastic Kubernetes Service (Amazon EKS) to host the order- processing backend
- C. Create an AMl of the web server VM. Create an Amazon EC2 Auto Scaling group that uses the AMI and an Application Load Balancer. Set up Amazon MQ to replace the on-premises messaging queue.Install Kubernetes on a fleet of different EC2 instances to host the order-processing backend
- D. Create an AMI of the web server VM. Create an Amazon EC2 Auto Scaling group that uses the AMI and an Application Load Balancer. Set up an Amazon Simple Queue Service (Amazon SQS) queue to replace the on-premises messaging queue. Configure Amazon Elastic Kubernetes Service (Amazon EKS) to host the order-processing backend
Correct Answer: A. Create an AMI of the web server VM. Create an Amazon EC2Auto Scaling group that uses the AMI and an Application Load Balancer. Set up Amazon MQ to replace the on-premises messaging queue.Configure Amazon Elastic Kubernetes Service (Amazon EKS) to host the order-processing backend.
Explanation
The correct answer is: A. Create an AMI of the web server VM. Create an Amazon EC2 Auto Scaling group that uses the AMI and an Application Load Balancer. Set up Amazon MQ to replace the on-premises messaging queue. Configure Amazon Elastic Kubernetes Service (Amazon EKS) to host the order-processing backend. Option A provides a solution that meets the requirements of refactoring the on-premises order-processing platform in the AWS Cloud with the least operational overhead. By creating an AMI (Amazon Machine Image) of the web server VM, you can easily replicate the existing environment and ensure compatibility with minimal changes to the application. Creating an Amazon EC2 Auto Scaling group that uses the AMI and an Application Load Balancer allows you to automate the scaling of the web front end based on demand. The Application Load Balancer distributes incoming traffic across multiple instances, ensuring high availability and scalability. Setting up Amazon MQ to replace the on-premises RabbitMQ messaging queue provides a managed message broker service that supports different messaging patterns. This allows for seamless integration between the front end and the backend systems without major changes to the application. Configuring Amazon Elastic Kubernetes Service (Amazon EKS) to host the order-processing backend enables containerized deployment and management of the backend system. With Amazon EKS, you can leverage the benefits of Kubernetes orchestration while minimizing operational overhead. This solution allows for a smooth transition of the on-premises order-processing platform to the AWS Cloud with minimal operational changes. It maintains high availability, scalability, and compatibility with the existing application. Option B (using custom AWS Lambda runtime) introduces more complexity by mimicking the web server environment using AWS Lambda, which may not be necessary in this scenario. Option C (installing Kubernetes on a fleet of EC2 instances) requires additional operational effort to set up and manage the Kubernetes cluster, adding unnecessary overhead. Option D (using Amazon SQS instead of Amazon MQ) may not be a direct replacement for RabbitMQ and could require more application changes. Therefore, the best solution for this scenario is Option A.