Containerized citizen-notification workers must roll out by registering a new task definition on Amazon ECS. Which deployment action aligns with that platform?
Select an answer to reveal the explanation.
Short Explanation
On ECS, a new task definition revision is the recipe card; updating the service cooks new tasks from it. Hiding images in RDS or living on one SSH box is not how city notification workers roll out.
Full Explanation
Containerized citizen-notification workers on Amazon ECS roll out by registering a new task definition revision and updating the service so ECS launches tasks from that revision. The task definition is the recipe—CPU, memory, image digests, environment—while the service continuously reconciles running tasks to the desired count and deployment configuration. Updating the service after registering the revision is the platform-aligned deploy action for notification workers that email or SMS citizens.
Updating only an EC2 user-data script ignores ECS services and task definitions when the workload is already containerized on ECS. Storing container images in Amazon RDS tables and expecting ECS to read SQL rows as images confuses a relational database with an image registry such as Amazon ECR. Disabling the ECS cluster and running containers exclusively via SSH docker run on one host abandons service scheduling, health checks, and civic capacity management.
Exam caveat: know the ECS objects—task definition revisions, services, clusters—and that deployments typically mean new revisions plus service updates (optionally with CodeDeploy blue/green), not ad-hoc SSH containers.
Operational check: push the notification image to ECR, register a new task definition revision pointing at that digest, update the ECS service, confirm new tasks become healthy and old tasks drain per the deployment settings, and verify a test citizen notification still sends.