A transit digital team requires a managed platform that speaks standard Kubernetes APIs for their container workloads. Which AWS service should they choose?
Select an answer to reveal the explanation.
Short Explanation
If the must-have is real Kubernetes APIs, Amazon EKS is the managed answer on AWS. Queues, Beanstalk myths, and Athena queries do not stand in for a Kubernetes control plane for transit containers.
Full Explanation
A transit digital team that requires a managed platform speaking standard Kubernetes APIs for container workloads should choose Amazon EKS (Elastic Kubernetes Service). EKS provides a managed Kubernetes control plane on AWS so teams can use upstream-compatible Kubernetes tooling, manifests, and operational practices while AWS manages control-plane availability. That is the right answer when Kubernetes API compatibility is an explicit requirement.
Amazon SQS is a managed message queue, not a Kubernetes control plane. AWS Elastic Beanstalk deploys web applications and is not “only for bare-metal mainframes,” but it is not the managed Kubernetes service. Amazon Athena queries data in S3 with SQL; it does not schedule Kubernetes DaemonSets.
Exam caveat: Need Kubernetes APIs → EKS. Prefer AWS-native simpler orchestration without Kubernetes → ECS. Avoid managing servers for containers → Fargate (with ECS or EKS).
Operational check: create an EKS cluster in approved private networking, configure cluster IAM/IRSA patterns, deploy the transit workloads with the team’s existing Helm charts or manifests, enable control-plane and audit logging, and document how Kubernetes upgrades will be scheduled around transit service windows.