Deployments for ECS and EKS: DOP-C02 study notes and practice questions
What to know about Deployments for ECS and EKS for the DOP-C02 exam, from the SDLC Automation domain (22% of the exam guide), then 2 free questions to test it. Part of the DOP-C02 study guide.
These questions ask how to release a new container version with no downtime and a fast rollback.
Amazon ECS
Strategy
How
Rolling update
Replaces tasks by minimumHealthyPercent and maximumPercent; the deployment circuit breaker detects failing deployments and rolls back automatically; CloudWatch alarms can also trigger rollback
Blue/green with CodeDeploy
A replacement task set behind a test listener, then traffic shifts all at once, canary or linear (such as Canary10Percent5Minutes) with alarm-based rollback; hooks include AfterAllowTestTraffic
ECS built-in blue/green
ECS itself shifts traffic between revisions with bake time, lifecycle hooks and rollback, without CodeDeploy
The task execution role pulls images and reads secrets at startup; the task role is what the app uses.
Deploy by image digest for repeatable releases.
Amazon EKS
Kubernetes rolling updates with maxUnavailable and maxSurge; maxUnavailable: 0 plus readiness probes keeps capacity during rollout.
Progressive delivery tools (such as Argo Rollouts or Flagger) for canaries.
Access entries give an IAM role Kubernetes permissions, limited to a namespace with access policies, without editing the aws-auth ConfigMap.
EKS Pod Identity or IRSA gives pods AWS credentials.
GitOps tools such as Argo CD or Flux sync the cluster from a Git repository.
Common traps
Rolling updates with no circuit breaker that keep failing.
All-at-once when the question wants a small share first. Use canary.
Readiness probes missing, so traffic hits pods that aren’t ready.
Granting the task role when ECS fails to fetch a secret at startup; that’s the execution role.
Tagging images latest, so a rollback redeploys the broken image.
A video streaming service runs its recommendations API as an Amazon ECS service on AWS Fargate, behind an Application Load Balancer. The team deploys the service with the default rolling update.
Last month a faulty image passed its health checks in the first minutes and then failed under load, and the rolling update had replaced most tasks before the alarms fired. The team wants a new version to receive live traffic first from a small share of users, to be shifted fully only if the alarms stay quiet for 10 minutes.
Any alarm on the 5xx error rate must return traffic to the previous version immediately, without a manual step.
Which deployment approach meets these requirements?
Choose one answer.
AA. Keep the rolling update and turn on the deployment circuit breaker with rollback, so that a deployment rolls back when tasks repeatedly fail to become healthy during the update.
BB. Switch the ECS service to the EXTERNAL deployment controller and shift listener weights with a script that adds 10 percent every minute, while an engineer watches the dashboard.
CC. Create a second ECS service with the new version, point a Route 53 weighted record at each service, and delete the old service once the change is complete.
DD. Use a CodeDeploy blue/green deployment for ECS with a canary traffic shift, and a CloudWatch alarm on 5xx errors that triggers automatic rollback.
B. Wrong: A script can shift weights, but the team would need to build its own rollback and alarm logic. An engineer watching a dashboard is too slow to meet the requirement for an immediate, automatic rollback.
C. Wrong: DNS weights are cached by clients and resolvers, so the shift is neither precise nor immediate. A rollback would wait for caches to expire, which fails the requirement to return traffic at once. Learn more: Configuring DNS failover (opens in a new tab)
D. Right: Correct. CodeDeploy starts a replacement task set, shifts a small share of listener traffic to it, waits the canary period, and then completes the shift. A CloudWatch alarm on 5xx errors can roll traffic back to the original task set automatically. Learn more: CodeDeploy blue/green deployments for Amazon ECS (opens in a new tab)
Explanation
CodeDeploy blue/green deployments for Amazon ECS run a replacement task set, shift listener traffic in stages and roll back when CloudWatch alarms fire. A canary configuration sends a small share first and the rest after a wait, which matches the requirement. The rolling update's circuit breaker reacts to failed tasks, and DNS weights and manual shifting cannot roll back quickly.
CodeDeploy starts a replacement task set, shifts a canary share of traffic to it, and rolls back on the 5xx alarm.
An airline runs its booking microservices on an Amazon EKS cluster. A CodeBuild project builds each service's image and then runs kubectl commands to roll the new image out to a namespace called bookings.
The pipeline's IAM role currently maps to cluster-admin through a hand-edited aws-auth ConfigMap, and the security team wants that role limited to the bookings namespace without any long-lived Kubernetes tokens. Deployments also cause short outages, because the current manifest removes every old pod before the new ones pass their readiness probes.
The rollout should keep at least the current number of healthy pods serving requests during each release.
Which TWO changes meet these requirements? (Choose two.)
Choose two answers.
AA. Store a Kubernetes service account token for the cluster-admin role in AWS Secrets Manager, and have the build fetch it at run time so that kubectl can apply manifests in any namespace.
BB. Create an EKS access entry for the pipeline role and attach an access policy scoped to the bookings namespace, so the role can deploy there and nowhere else, with no aws-auth edits.
CC. Change the Deployment to use the Recreate strategy, so that all old pods stop before the new ones start, and let the pipeline apply the manifest with a shorter timeout.
DD. Set the Deployment's rolling update to a maxUnavailable of zero and a maxSurge of one, and define readiness probes so that a new pod receives traffic only after it passes its checks.
EE. Add a CronJob that restarts every bookings pod each night and remove the readiness probes, so that stale pods are replaced before peak hours and unready pods are not a concern.
Show the answer and explanation
Answers: B, D
A. Wrong: A long-lived cluster-admin token is the opposite of what the security team asked for, and it reaches every namespace. Storing it in Secrets Manager does not reduce that access. Learn more: What is AWS Secrets Manager? (opens in a new tab)
B. Right: Correct. EKS access entries map IAM principals to Kubernetes access without editing the aws-auth ConfigMap, and an access policy can be limited to one namespace. The pipeline keeps working in bookings and cannot change other namespaces. Learn more: Associate access policies with access entries (opens in a new tab)
C. Wrong: Recreate removes every old pod before creating new ones, which causes the outage the airline wants to end. A shorter timeout does not change how many pods serve traffic.
D. Right: Correct. With maxUnavailable at zero, Kubernetes keeps every current pod running until a replacement is ready, and readiness probes keep unready pods out of service. Together they keep the healthy pod count at its current level during each release.
E. Wrong: Restarts add outages on their own schedule. Removing readiness probes also lets unready pods receive traffic, which makes each release less safe.
Explanation
Access entries let an IAM role receive Kubernetes permissions limited to one namespace, without shared tokens or hand-edited aws-auth data. A rolling update with maxUnavailable set to zero, plus readiness probes, keeps existing healthy pods in service until new ones pass their checks. Cluster-admin tokens and the Recreate strategy each miss one of the requirements.
Want more on Deployments for ECS and EKS? The 5 full-length practice sets have 8 more Deployments for ECS and EKS questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →