A company has an ML model that generates text descriptions based on images that customers upload to the company's website. The images can be up to 50 MB in total size. An ML engineer decides to…

Question

Options

• ACreate an Amazon SageMaker batch transform job to process all the images in the S3 bucket.
• BCreate an Amazon SageMaker Asynchronous Inference endpoint and a scaling policy. Run a
• CCreate an Amazon Elastic Kubernetes Service (Amazon EKS) cluster that uses Karpenter for
• DCreate an AWS Batch job that uses an Amazon Elastic Container Service (Amazon ECS) cluster.

• A
  20% (11)
• B
  67% (37)
• C
  4% (2)
• D
  9% (5)

Explanation

SageMaker Asynchronous Inference is the correct choice because it is purpose-built for large-payload inference requests (up to 1 GB, well above the 50 MB images here), queues incoming requests automatically, and supports auto-scaling policies - including scaling to zero during idle periods - with no cluster management required from the engineer.

Option A (Batch Transform) is wrong because Batch Transform is designed for offline, scheduled batch jobs against a static dataset, not for processing individual customer uploads as they arrive in real time.

Option C (EKS + Karpenter) is wrong because while Karpenter handles node auto-scaling, running and managing a Kubernetes cluster carries significant operational overhead - the opposite of what the question asks.

Option D (AWS Batch + ECS) is wrong because AWS Batch is optimized for general compute batch workloads, and managing ECS clusters and job queues adds operational burden compared to a fully managed SageMaker endpoint.

Memory tip: When you see "large payloads + variable demand + least overhead" in an ML inference question, map it to Async Inference - think of it as a managed queue that handles bursty, heavy uploads so you don't have to run infrastructure yourself.

No community discussion yet for this question.