A city evaluating containers hears Amazon ECS or Amazon EKS mentioned as options instead of building orchestration entirely on raw virtual machines. What should the Cloud Practitioner emphasize?
Select an answer to reveal the explanation.
Short Explanation
Building full orchestration on raw VMs is like forging your own subway control system; ECS or EKS is riding a managed line for containers. You still bring the apps, but you do not invent every control panel. That is managed-service thinking for containers.
Full Explanation
ECS and EKS are managed container orchestration options that reduce undifferentiated orchestration work compared with building everything on raw VMs. A city evaluating containers should hear that AWS operates more of the control-plane and orchestration heavy lifting so municipal teams focus on images, services, and application delivery—not reinventing schedulers on unmanaged fleets.
ECS and EKS are not object-storage services and do run containers. Raw VMs are not the only AWS-supported way to run containers. Choosing ECS or EKS does not remove customer responsibility for application code and IAM.
Exam caveat: Managed orchestration reduces toil; it does not erase shared responsibility for apps and access. Operational check: deploy a small civic API on ECS or EKS, compare operational tasks against a raw-VM compose/kube DIY path, and list IAM/network controls the city still owns.
Municipal teams should keep a one-page decision record linking this Cloud Practitioner concept to resident outcomes, revisit it after major traffic or compliance changes, and ensure runbooks still match the chosen design.
Municipal teams should keep a one-page decision record linking this Cloud Practitioner concept to resident outcomes, revisit it after major traffic or compliance changes, and ensure runbooks still match the chosen design.