Which combination of steps should the developer take to deploy the containerized proof-of-concept application with the LEAST operational effort?
(Choose two.)
Package the application into a .zip file by using a command line tool. Upload the package to Amazon S3.
Package the application into a container image by using the Docker CLI. Upload the image to Amazon Elastic Container Registry (Amazon ECR).
Deploy the application to an Amazon EC2 instance by using AWS CodeDeploy.
Deploy the application to Amazon Elastic Kubernetes Service (Amazon EKS) on AWS Fargate.
Deploy the application to Amazon Elastic Container Service (Amazon ECS) on AWS Fargate.
Explanations:
Packaging the application into a container image and uploading it to Amazon ECR is a common approach for containerized deployments on AWS. Amazon ECR is a fully managed Docker container registry that stores and manages Docker images, making it easy to deploy containers in AWS.
Amazon ECS on AWS Fargate provides a serverless compute engine to run containers without managing servers. This approach minimizes operational effort since the developer doesn’t need to manage EC2 instances. It is a suitable solution for containerized applications with low operational overhead.
Packaging the application into a .zip file is not suited for containerized applications. The .zip format is more appropriate for serverless functions or other deployment methods that do not rely on container images.
Deploying to Amazon EC2 using AWS CodeDeploy requires managing EC2 instances, which increases operational complexity. This method is not serverless and involves more management compared to ECS on Fargate or EKS on Fargate.
Amazon EKS on AWS Fargate provides serverless Kubernetes orchestration for containers, but it involves a more complex setup compared to ECS. It’s better suited for cases where Kubernetes is required, but it introduces more operational effort than using ECS with Fargate.