Task 4.3: Determine a new architecture for existing workloads.

• AAmazon EKS clusters with a node group for each application

  Incorrect

  EKS runs Kubernetes, which requires container images and Kubernetes skills that the team does not have.

• BAWS Elastic Beanstalk environments on the Tomcat platform

  Correct

  Elastic Beanstalk handles capacity provisioning, load balancing, scaling and health monitoring for web applications on supported platforms such as Tomcat, and you keep control of the underlying resources.

• CAWS Lambda functions behind Amazon API Gateway

  Incorrect

  Moving Tomcat applications to Lambda means rewriting them as functions, which is a refactor, not a new home for the existing applications.

• DEC2 instances built from custom AMIs that the team patches itself

  Incorrect

  Self-managed instances leave provisioning, scaling and platform updates to the team, which is what it wants to avoid.

For web applications on a standard platform without containers, Elastic Beanstalk gives managed operations while keeping the instances visible.

• AAmazon ECS on AWS Fargate, with each Kubernetes manifest converted into a task definition

  Incorrect

  ECS uses its own task definitions and APIs, so the Helm charts and kubectl workflows would have to be replaced.

• BA Kubernetes cluster on EC2 instances that the team installs and upgrades with an open-source tool

  Incorrect

  The team would keep running the control plane and the worker nodes, which it wants to stop doing.

• CAn Amazon EKS cluster with EKS Auto Mode turned on

  Correct

  EKS runs the Kubernetes control plane, and Auto Mode extends AWS management to the infrastructure for workloads, including compute nodes, so the team keeps standard Kubernetes tooling.

• DAmazon EKS Anywhere on the existing data center hardware

  Incorrect

  EKS Anywhere runs Kubernetes on infrastructure that the customer manages, so the company would still own the nodes.

Keep Kubernetes, drop control plane and node management: EKS with Auto Mode.

• AAWS Storage Gateway Volume Gateway with cached volumes

  Correct

  Cached volumes store data in Amazon S3, keep a local copy of frequently accessed data, present iSCSI devices to on-premises servers and support snapshots that can be restored as EBS volumes.

• BAmazon S3 File Gateway mounted over NFS by the application servers

  Incorrect

  S3 File Gateway presents files over NFS and SMB, not iSCSI block volumes, so the application would need changes.

• CAWS Storage Gateway Tape Gateway with virtual tapes

  Incorrect

  Tape Gateway replaces physical tape for backup software. Applications cannot run on virtual tapes as block storage.

• DAmazon FSx for Windows File Server shared to the factory over Direct Connect

  Incorrect

  FSx for Windows File Server provides SMB file shares, not iSCSI block volumes, and every read would cross the network to AWS.

On-premises iSCSI with cloud-backed primary data and EBS-ready snapshots is Volume Gateway in cached mode.

• AAmazon DynamoDB, with each collection modeled as a table

  Incorrect

  DynamoDB has its own API and data modeling, so the MongoDB queries and drivers would have to be rewritten.

• BAmazon DocumentDB (with MongoDB compatibility)

  Correct

  DocumentDB is a fully managed document database that supports MongoDB workloads, so applications can keep using MongoDB drivers and tools, while AWS manages the operations.

• CAmazon Keyspaces (for Apache Cassandra)

  Incorrect

  Keyspaces is compatible with Apache Cassandra and CQL, not with the MongoDB API.

• DMongoDB on EC2 instances in an Auto Scaling group across three Availability Zones

  Incorrect

  The team would still manage backups, patching and failover itself, which it wants to stop doing.

Managed operations with MongoDB compatibility point to Amazon DocumentDB.

• AAmazon DynamoDB

  Incorrect

  DynamoDB is a key-value database, not a SQL data warehouse.

• BAmazon RDS for PostgreSQL on a large instance

  Incorrect

  A single OLTP database instance is sized by hand and is not a data warehouse.

• CA self-managed warehouse on EC2

  Incorrect

  The team would size and manage the servers.

• DAmazon Redshift Serverless

  Correct

  Redshift Serverless provisions data warehouse capacity automatically and scales the underlying resources.

A data warehouse without capacity management is Redshift Serverless.

• AAmazon WorkSpaces Secure Browser portals that give contractors the internal web applications from their own browsers

  Incorrect

  WorkSpaces Secure Browser is a hosted browser for private websites and SaaS web applications, streamed to the user's browser. It does not provide a Windows desktop for installed engineering tools.

• BAmazon WorkSpaces Personal desktops for the contractors, set to hourly billing and joined to the company's directory

  Correct

  WorkSpaces Personal provides persistent virtual desktops assigned to one user, like a physical desktop, without hardware or complex software to deploy. Users reach them from personal devices without data being stored on those devices, and WorkSpaces offers monthly or hourly billing.

• CAn AWS Client VPN endpoint that connects each contractor's laptop to a Windows EC2 instance launched for that contractor

  Incorrect

  Client VPN gives laptops managed access to resources in AWS, and EC2 instances could host the desktops, but the company would build and run the desktop fleet itself, and connected laptops could copy data locally.

• DAmazon WorkSpaces Applications fleets that stream each engineering tool to the contractors' laptops on demand

  Incorrect

  WorkSpaces Applications streams desktop applications that administrators maintain in a single version, and no data is stored on users' devices. It does not give each contractor a persistent desktop where they install their own tools.

The constraints are a persistent personal Windows desktop with user-installed tools, unmanaged laptops that keep no data, hourly billing, and no desktop infrastructure to run. Secure Browser covers web applications only, application streaming offers administrator-managed apps rather than a personal desktop, and Client VPN with EC2 is infrastructure to operate. WorkSpaces Personal with hourly billing meets every constraint.

• ARun the jobs as applications in Amazon Managed Service for Apache Flink, reading from the migrated Kafka topics

  Correct

  Managed Service for Apache Flink runs Flink applications written in Java and other languages and provides the infrastructure: it provisions compute, scales automatically, handles Availability Zone failover, and backs up application state with checkpoints and snapshots.

• BRun the jobs on a long-running Amazon EMR cluster that hosts Flink as a YARN application

  Incorrect

  EMR supports Flink as a YARN application, so the code can stay as it is, but the team would still size, scale and maintain the EMR cluster that the jobs run on.

• CRewrite the jobs as AWS Glue streaming ETL jobs that read the Kafka topics with Spark Structured Streaming

  Incorrect

  Glue streaming jobs are serverless, but they run on the Apache Spark Structured Streaming engine, so every Flink job would have to be rewritten.

• DSend the transactions to Amazon Data Firehose and score them with a transformation Lambda function before delivery

  Incorrect

  Firehose is a fully managed service for delivering streaming data to destinations such as S3 and Redshift. It does not run Flink code or keep per-card state across events, so the jobs would be rebuilt without their windows.

The constraints are unchanged Flink code, managed state recovery, sub-second scoring and no cluster to operate. EMR keeps the code but not the operations savings, Glue requires a Spark rewrite, and Firehose delivers data rather than running stateful jobs. Managed Service for Apache Flink runs the existing applications with managed checkpoints, snapshots and scaling.

• ARun Airflow on EC2 instances in an Auto Scaling group that adds Celery workers as the task queue grows

  Incorrect

  This keeps the DAGs and scales workers, but on EC2 the customer manages the guest operating system, its patches and the installed software, so the team would still operate the Airflow servers.

• BReplace the DAG schedules with EventBridge Scheduler schedules that invoke the pipeline steps directly

  Incorrect

  EventBridge Scheduler is a serverless scheduler that invokes AWS service targets on cron or rate schedules with retries. It does not run Airflow DAGs, so the dependencies and custom operators would have to be rebuilt.

• CRewrite every DAG as an AWS Step Functions state machine that calls the same pipeline steps

  Incorrect

  Step Functions runs workflows as managed state machines, so nobody would patch servers, but every DAG and custom operator would have to be rewritten, which the team wants to avoid.

• DMove the DAGs and plugins to an Amazon Managed Workflows for Apache Airflow environment in the VPC

  Correct

  Amazon MWAA runs Apache Airflow without managing infrastructure for scalability, availability and security, and its automatic scaling adds workers in response to running and queued tasks and removes them when none remain.

The constraints are unchanged DAGs and plugins, workers that follow the queue, VPC access, and no Airflow servers to operate. Airflow on EC2 keeps the servers, and EventBridge Scheduler or Step Functions would mean rewriting the pipelines. Amazon MWAA runs the same DAGs with managed, automatically scaling workers.

• AAWS X-Ray traces

  Incorrect

  Traces follow requests; they do not replace Prometheus metrics.

• BCloudWatch Logs Insights only

  Incorrect

  Logs Insights queries logs, not Prometheus metrics with PromQL.

• CSelf-managed Prometheus on larger EC2 instances

  Incorrect

  The company would still run Prometheus servers.

• DAmazon Managed Service for Prometheus

  Correct

  It is a serverless, Prometheus-compatible monitoring service for container metrics.

Prometheus-compatible metrics without servers is Amazon Managed Service for Prometheus.