Q27 — AWS SAA-C03 Ch.15

Question 27 of 100 | ← Chapter 15

Q1127. A company runs a monolithic application in its on-premises data center. The company used Java/Tomcat to build the application. The application uses Microsoft SQL Server as a database.The company wants to migrate the application to AWS.Which solution will meet this requirement with the LEAST operational overhead?

Correct Answer: A. Use AWS App2Container to containerize the application. Deploy the application on Amazon Elastic Kubernetes Service (Amazon EKS). Deploy the database to Amazon RDS for SQL Server. Configure a Multi-AZ deployment.

Explanation

The solution that will meet the requirement to migrate the application to AWS with the LEAST operational overhead is:A. Use AWS App2Container to containerize the application. Deploy the application on Amazon Elastic Kubernetes Service (Amazon EKS). Deploy the database to Amazon RDS for SQL Server. Configure a Multi-AZ deployment.Explanation:AWS App2Container: This service simplifies the process of containerizing existing applications, reducing the operational effort required for migration.Amazon EKS: Using a managed Kubernetes service like Amazon EKS minimizes the operational overhead associated with managing the Kubernetes infrastructure, allowing the company to focus on the application itself.Amazon RDS for SQL Server: RDS manages the database, including backups, patching, and scaling, which significantly reduces operational overhead compared to managing a database on EC2 instances. The Multi-AZ deployment provides high availability and failover capabilities.Why Other Options Are Not Suitable:B: Setting up a self-managed Kubernetes cluster increases operational complexity and overhead, as the company would need to manage the entire Kubernetes infrastructure and SQL Server availability groups manually.C: This option involves significant changes to the application architecture, as it requires moving to a serverless architecture with Amazon S3 and DynamoDB, which may not be suitable for a monolithic application built on Java/Tomcat.D: Similar to option C, using DynamoDB for the database tier would require significant architectural changes from SQL Server to a NoSQL database, increasing complexity and operational overhead.Thus, option A provides the best balance of functionality and minimal operational overhead for migrating the application to AWS.To migrate a monolithic Java/Tomcat application with Microsoft SQL Server to AWS with the least operational overhead, the solution should:Minimize Rewrites/Rearchitecting: Avoid rewriting the application (e.g., converting to microservices or NoSQL).Leverage Managed Services: Use AWS-managed services (e.g., RDS) to reduce operational overhead. Preserve Existing Tech Stack: Keep the application running on Java/Tomcat with SQL Server (if possible).Key Requirements:Monolithic Application: Likely not designed for microservices or serverless. Java/Tomcat: Should run on a compatible compute service (e.g., EC2, ECS, or EKS). Microsoft SQL Server: Should run on a managed database service (if possible) or a compatible instance. Least Operational Overhead: Prefer managed services over self-managed infrastructure.Option Analysis:Option A:Use AWS App2Container to containerize the application. Deploy the application on Amazon Elastic Kubernetes Service (Amazon EKS). Deploy the database to Amazon RDS for SQL Server. Configure a Multi-AZ deployment.Why This Works:AWS App2Container: Automates containerization of the Java/Tomcat application (reduces manual effort). Amazon EKS: Managed Kubernetes (less operational overhead than self-managed Kubernetes). Amazon RDS for SQL Server: Fully managed SQL Server database (no need to manage backups, patches, or high availability).Multi-AZ RDS: Provides built-in high availability (DR) for the database. Best Balance: Leverages managed services while containerizing the app (minimal rewrites).Option B:Containerize the application and deploy the application on a self-managed Kubernetes cluster on an Amazon EC2 instance. Deploy the database on a separate EC2 instance. Set up Microsoft SQL Server Always On availability groups.Why This Fails:High Operational Overhead:Self-managed Kubernetes requires patching, scaling, and monitoring. SQL Server Always On requires manual setup, monitoring, and failover management.More Complexity: More moving parts than Option A.Not Least Overhead: This approach is more labor-intensive than using managed services.Option C:Deploy the frontend of the web application as a website on Amazon S3. Use Amazon DynamoDB for the database tier.Why This Fails:Major Rewrite Required:The app is monolithic Java/Tomcat (not static frontend-only).DynamoDB is NoSQL (incompatible with SQL Server schema).Not Suitable for Monolithic Apps: This approach would require a complete rearchitecture.Option D:Use AWS App2Container to containerize the application. Deploy the application on Amazon Elastic Kubernetes Service (Amazon EKS). Use Amazon DynamoDB for the database tier.Why This Fails:DynamoDB Incompatibility:The app uses SQL Server (relational), not DynamoDB (NoSQL). Migrating to DynamoDB would require a massive schema and query rewrite. Not Least Overhead: Rewriting the database layer adds significant complexity.Best Choice: Option AAWS App2Container + Amazon EKS + Amazon RDS for SQL Server (Multi-AZ) provides:Containerization (via App2Container) with minimal manual effort. Managed Kubernetes (EKS) (less overhead than self-managed). Managed SQL Server (RDS) (no need to manage DB operations).High Availability (Multi-AZ RDS) (built-in failover).Final Answer:A. Use AWS App2Container to containerize the application. Deploy the application on Amazon Elastic Kubernetes Service (Amazon EKS). Deploy the database to Amazon RDS for SQL Server. Configure a Multi-AZ deployment.Additional Notes:AWS App2Container simplifies containerization of legacy apps. RDS for SQL Server is the best managed database option for SQL Server workloads. EKS is more managed than self-hosted Kubernetes (reduces DevOps effort). Avoiding NoSQL (DynamoDB) ensures compatibility with the existing app.