Several municipal microservices require Kubernetes APIs and custom controllers, while a simple batch job only needs containers without Kubernetes. How should orchestration be chosen?
Select an answer to reveal the explanation.
Short Explanation
Reach for EKS when you truly need the Kubernetes toolbox; for a plain box of containers, ECS/Fargate is the lighter city work van. Putting every chore on full Kubernetes—or ditching orchestrators—is overkill or underkill.
Full Explanation
Choose orchestration by need: Amazon EKS for municipal microservices that require Kubernetes APIs and custom controllers, and Amazon ECS on AWS Fargate for a simpler containerized batch job that does not need the Kubernetes control plane. That split avoids forcing Kubernetes operational weight onto trivial jobs while still giving K8s where controllers and Kubernetes APIs are genuine requirements.
Running every workload on Amazon EKS, including trivial jobs that never use Kubernetes APIs, fails by concept because it over-operates simple batch work on a full Kubernetes platform without benefit. Forcing both onto unmanaged EC2 User Data scripts with no container orchestrator fails because it abandons scheduling, health, and rollout features containers were meant to gain. Placing only the Kubernetes apps on Elastic Beanstalk single-instance environments without containers fails because Beanstalk single-instance without containers does not provide Kubernetes APIs or custom controllers.
Exam caveat: EKS when you need Kubernetes; ECS/Fargate when you need containers without Kubernetes. “Everything on EKS” and “no orchestrator” are common wrong extremes on the exam.
Operational check: Confirm EKS workloads actually use Kubernetes APIs/controllers, the batch job runs as ECS tasks (preferably Fargate) without a cluster ops burden it does not need, and platform runbooks match each orchestrator. If a simple nightly job requires kubectl and node groups, the split is wrong.