SAP-C02 - Accelerate Workload Migration and Modernization - Section 4.4

Identify opportunities to modernise by decoupling components and moving to serverless compute with AWS Lambda and containers with Amazon ECS, Amazon EKS and AWS Fargate.

Identify modernisation opportunities in monolithic workloads by decomposing tightly coupled components and migrating stateless logic to AWS Lambda or containerised services on Amazon EKS and AWS Fargate. Recognise when decoupling via event-driven integration reduces operational burden compared to running self-managed container infrastructure.

AWS LambdaAmazon EKSAWS FargateDecoupling

Practice question for this objective

Free sampleAccelerate Workload Migration and Modernizationhard

An insurer is rehosting a batch-processing application that already ships as a Docker image and runs as long-lived background workers reading jobs from a queue. Management wants the workers in AWS without buying, patching, or right-sizing any container host fleet, while keeping per-task CPU and memory isolation and paying only for the resources each running task consumes. The workload is steady but unpredictable in volume, and the platform team has no appetite for managing EC2 capacity. Which compute platform MOST cost-effectively and efficiently meets these requirements?

  • ARun the containers on an Amazon ECS cluster backed by an EC2 capacity provider, sizing an Auto Scaling group of container instances and patching the host operating system so the cluster can place the worker tasks.
  • BConvert the worker logic into AWS Lambda functions triggered by the queue, repackaging the container so each job runs as a short-lived invocation within the Lambda execution timeout instead of a long-lived process.
  • CDeploy the containers to a self-managed Kubernetes cluster on EC2 so the platform team controls scheduling and networking in detail, scaling worker nodes manually as the queue depth rises and falls over time.
  • DRun the existing container image as Amazon ECS tasks on AWS Fargate, letting Fargate provision isolated task capacity on demand so the team manages no host fleet and pays only for the vCPU and memory each task uses. Correct
Select AWS Fargate to run existing containers as ECS tasks when the goal is serverless, per-task billing with no host fleet to manage. Containerised long-lived workers that must run with per-task isolation and no host management map onto ECS on Fargate, which provisions serverless task capacity and bills per task, whereas ECS on EC2 keeps host toil, Lambda misfits long-running jobs, and self-managed Kubernetes adds cluster operations.

Why A is wrong: ECS on EC2 places the tasks correctly, but it leaves the team owning host capacity planning, patching, and right-sizing, which is exactly the undifferentiated work management asked to avoid in this rehost.

Why B is wrong: Lambda is serverless, but its bounded execution duration and event-driven model do not suit long-lived background workers and would force re-architecting the batch processes, exceeding the scope of a container rehost.

Why C is wrong: Self-managed Kubernetes on EC2 maximises control but adds substantial cluster and node operations, contradicting the explicit requirement to avoid managing host capacity and patching for this workload.

Why D is correct: Fargate runs the unchanged container image as ECS tasks with per-task CPU and memory isolation, provisions capacity serverlessly, and bills only for resources each task consumes, removing all host management for these queue workers.

See more SAP-C02 practice questions, answers explained.

More in this domain

Back to all Accelerate Workload Migration and Modernization objectives, or the SAP-C02 cert hub.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.