☰ All modules Tier 3 · Containers (ECS, ECR, Fargate) GuideCheat sheet ‹ monitorings3 ›
Contents
  1. How Containers (ECS, ECR, Fargate) appears on DVA-C02
  2. 1. ECS building blocks and capacity options
  3. 2. Task definitions and container settings
  4. 3. IAM roles for tasks and container instances
  5. 4. Environment variables and secrets
  6. 5. Services standalone tasks and load balancing
  7. 6. Service auto scaling and cluster capacity
  8. 7. Rolling and blue green deployments
  9. 8. Task placement strategies and constraints
  10. 9. Amazon ECR authentication images and lifecycle
  11. 10. Amazon EKS basics
  12. Quick decision rules
  13. Changed vs older material

Containers (ECS, ECR, Fargate) — DVA-C02 Mastery Guide

  • Sources: course chapter 09 (Containers on AWS: Docker, Amazon ECS, AWS Fargate, Amazon ECR, Amazon EKS). The course serves as the syllabus only; all wording, examples and questions here are original.
  • Written 2026-10-12; values checked against AWS docs on 2026-10-12 (Amazon ECS Developer Guide and API Reference, Amazon ECR User Guide, Amazon EKS User Guide, AWS General Reference quotas, Application Auto Scaling and EventBridge Scheduler API references, the DVA-C02 exam guide and its revision history, What's New posts and the AWS Containers blog). The marker ⚠️ Changed: <current>. Older material may say <old>. flags a value or behaviour that differs from the course or older practice tests: learn the current value. ⚠️ unverified marks something AWS documentation did not confirm (or contradicts itself on): don't build an exam answer on it. Every change is listed in Changed vs older material; rows you confirm during /ingest are added to notes/current-facts.md.
  • Tier 3 (supporting), bank target 30 questions. Domains: Deployment (primary), Development with AWS Services.
  • How to use it: /explain <topic> teaches from these sections (concept → exam facts → developer angle → traps → 3 check questions); /quiz containers asks bank questions whose source_note links point at the ## N. headings below; /drill containers fires short recall prompts from notes/containers-cheat-sheet.md. Suggested loop: read a section and answer its practice questions before opening the answers → /explain what is still unclear → /quiz containers → /drill containers.
  • Owned by other modules (one-line pointers only here): instance profiles, the credential chain, IMDSv2 and the hop limit → notes/ec2-mastery-guide.md §1–§2; EFS mounts and modes → notes/ec2-mastery-guide.md §7; ALB/NLB listeners, target groups, deregistration delay and 502/503/504 → notes/ec2-mastery-guide.md §8; EC2 Auto Scaling groups → notes/ec2-mastery-guide.md §10; CodeDeploy AppSpec and ECS deployment configurations, CodePipeline imagedefinitions.json → notes/cicd-guide.md §4 and §8; Parameter Store vs Secrets Manager → notes/security-encryption-guide.md §8–§9; Lambda container images → notes/lambda-guide.md §8; Beanstalk Docker platforms → notes/beanstalk-guide.md §12; CDK ECS patterns such as ApplicationLoadBalancedFargateService → notes/cdk-guide.md §2; iam:PassRole in depth → notes/advanced-identity-guide.md §13; SQS worker semantics → notes/sqs-sns-kinesis-guide.md §2; EventBridge rules, Scheduler syntax, retries and DLQs → notes/monitoring-guide.md §6; X-Ray/ADOT sidecars on ECS → notes/monitoring-guide.md §8; subnets, NAT and VPC endpoint design → notes/vpc-guide.md §1 and §3.

How Containers (ECS, ECR, Fargate) appears on DVA-C02

DVA-C02 treats containers as one of the ways a developer packages and ships an application. It does not test cluster administration; it asks what a developer must declare, grant or choose so a containerised app builds, starts, gets its configuration, scales and deploys safely:

Typical question shapes: a short scenario with one deciding constraint; a stopped-task reason or service event message to diagnose; "Which TWO actions…" with five options; the exact parameter, CLI command or IAM action that does the job.

Domain map: Deployment → §1, §6, §7, §9 · Development with AWS Services → §2, §4, §5, §10 · Security (roles and secrets show up inside development and deployment questions) → §3, §4, §9 · Troubleshooting → §2, §5, §8, §9.

Out of scope: operating-system administration of container hosts (kernel tuning, Docker daemon internals, iptables beyond the one-line IMDS block shown in §3) and network infrastructure design (subnet layout, routing, NAT and endpoint architecture). Subnets, NAT gateways and VPC endpoints appear here only as blockers you must recognise.

# Topic Why it is on the exam
1 ECS building blocks and capacity options Cluster, task definition, task and service vocabulary; Fargate vs ECS Managed Instances vs EC2; Fargate Spot; Copilot's end of support and Express Mode
2 Task definitions and container settings CPU and memory limits, essential containers, health checks, logging, port mappings and storage choices decide whether a task starts and stays up
3 IAM roles for tasks and container instances Task role vs task execution role vs instance role is the most tested container security distinction; ECS Exec permissions
4 Environment variables and secrets environment, S3 environment files and secrets from Secrets Manager or Parameter Store, and why a rotated secret needs a new task
5 Services standalone tasks and load balancing Replica vs daemon services, ALB/NLB integration, dynamic host ports vs awsvpc, EventBridge-launched tasks
6 Service auto scaling and cluster capacity Application Auto Scaling policies and metrics, SQS backlog scaling, capacity providers for EC2
7 Rolling and blue green deployments Deployment arithmetic, circuit breaker and alarm rollbacks, ECS-native blue/green, linear and canary, CodeDeploy
8 Task placement strategies and constraints binpack, spread, random, distinctInstance, memberOf and why tasks stay PENDING
9 Amazon ECR authentication images and lifecycle Login tokens, push/pull permissions, repository policies, lifecycle and archive rules, immutability, scanning, replication
10 Amazon EKS basics When to pick EKS, node options including Auto Mode, Pod Identity vs IRSA, access entries, storage drivers

1. ECS building blocks and capacity options

Concept

Exam facts

Developer angle

Create a Fargate cluster with a default strategy, register a task definition, run a service across Fargate and Fargate Spot, and launch a one-off task:

aws ecs create-cluster --cluster-name orders \
  --capacity-providers FARGATE FARGATE_SPOT \
  --default-capacity-provider-strategy capacityProvider=FARGATE,base=2,weight=1 capacityProvider=FARGATE_SPOT,weight=3

aws ecs register-task-definition --cli-input-json file://orders-api-taskdef.json

aws ecs create-service --cluster orders --service-name orders-api \
  --task-definition orders-api:7 --desired-count 6 \
  --capacity-provider-strategy capacityProvider=FARGATE,base=2,weight=1 capacityProvider=FARGATE_SPOT,weight=3 \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-0a1b2c3d4e5f60718,subnet-0f1e2d3c4b5a69788],securityGroups=[sg-0123456789abcdef0],assignPublicIp=DISABLED}"

# one-off job (database migration) as a standalone task
aws ecs run-task --cluster orders --task-definition orders-migrate:3 --count 1 \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-0a1b2c3d4e5f60718],securityGroups=[sg-0123456789abcdef0],assignPublicIp=DISABLED}"

With 6 tasks and that strategy, the first 2 go to FARGATE (base), and the remaining 4 split 1:3, so 1 more On-Demand task and 3 Spot tasks.

Spot-friendly (and deployment-friendly) code handles SIGTERM and finishes in-flight work before stopTimeout runs out:

import signal, sys

def shutdown(signum, frame):
    # stop taking new work, finish or checkpoint in-flight items, flush logs, then exit
    sys.exit(0)

signal.signal(signal.SIGTERM, shutdown)

Traps

Practice questions

  1. A team runs a stateless order API as an Amazon ECS service on AWS Fargate with 8 tasks. To cut cost, most tasks should run on spare capacity, but at least 2 tasks must keep serving even when no spare capacity is available, and the team wants the LEAST operational overhead. What should a developer configure?

    • A. A capacity provider strategy with FARGATE (base=2, weight=1) and FARGATE_SPOT (weight=3).
    • B. The FARGATE launch type plus a second service that uses only FARGATE_SPOT with a desired count of 6.
    • C. An Auto Scaling group of Spot Instances registered as a capacity provider with binpack placement.
    • D. A capacity provider strategy with only FARGATE_SPOT and a desired count raised from 8 to 12.

  2. A machine-learning team needs a specific GPU instance family for an inference service on Amazon ECS. They do not want to patch, scale or replace EC2 instances themselves, and each deployment restarts the tasks at least weekly. They are evaluating Amazon ECS Managed Instances. Which TWO statements are correct? (Select TWO.)

    • A. AWS provisions, patches and scales the instances, which run in the team's own AWS account.
    • B. Each task runs in a dedicated micro-VM and is billed per task vCPU and memory, as on Fargate.
    • C. A custom capacity provider can require instance attributes such as an accelerator type.
    • D. The team can install a custom AMI with its own GPU drivers and connect to instances over SSH.
    • E. Instances keep running until the team drains them, because AWS never replaces healthy instances.
Answers
  1. A. The base guarantees 2 On-Demand tasks and the weights put about three of every four further tasks on Fargate Spot, all in one managed service. B splits one workload into two services that scale and deploy separately; C adds instance management the team wanted to avoid (and binpack is irrelevant to the floor); D has no guaranteed capacity at all when Spot is reclaimed.
  2. A, C. Managed Instances are EC2 instances that AWS operates in your account, and custom capacity providers accept attribute-based requirements such as accelerators. Billing is per instance plus a management charge (B describes Fargate); custom AMIs and SSH aren't available (D); instances are drained after 14 days for patching (E).

2. Task definitions and container settings

Concept

Exam facts

Option Runs on Lifetime Typical use
Bind mount (volumes + mountPoints, volumesFrom) Fargate, EC2, Managed Instances Ephemeral: task lifetime on Fargate, instance lifetime on EC2 Share scratch files between containers of one task, e.g. a log-shipping sidecar reading the app's log directory
Fargate ephemeral storage Fargate Ephemeral 20 GiB default, raise to 200 GiB with ephemeralStorage.sizeInGiB (platform 1.4.0+); encrypted with AES-256 using an AWS owned key or your KMS key; the image itself uses part of it
Amazon EFS Fargate (1.4.0+), EC2, Managed Instances Persistent, shared across tasks and AZs Shared uploads or content; access points; IAM authorization through the task role; NFS on port 2049
Amazon EBS Fargate (1.4.0+, Linux), EC2 (Nitro), Managed Instances One new volume per task, configured at launch (configuredAtLaunch); always deleted when a service task ends, can be kept for a standalone task High-IOPS block storage such as a database or ETL scratch; needs the ECS infrastructure role
Amazon S3 Files Fargate, Managed Instances; EC2 ⚠️ unverified (AWS pages disagree) Persistent; synchronised with an S3 bucket File-system access to data already in S3; s3filesVolumeConfiguration, task role mandatory, TLS always on
Docker volumes EC2 only Per instance or driver Third-party volume drivers
FSx for Windows File Server EC2 (Windows) Persistent SMB shares for Windows tasks

Developer angle

A Fargate task definition with a health check, ordered start-up, CloudWatch logging and extra ephemeral storage:

{
  "family": "orders-api",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "1024", "memory": "2048",
  "runtimePlatform": { "operatingSystemFamily": "LINUX", "cpuArchitecture": "ARM64" },
  "executionRoleArn": "arn:aws:iam::111122223333:role/ordersTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::111122223333:role/ordersApiTaskRole",
  "ephemeralStorage": { "sizeInGiB": 40 },
  "containerDefinitions": [
    { "name": "migrate", "essential": false,
      "image": "111122223333.dkr.ecr.eu-west-1.amazonaws.com/orders-migrate:1.8.2" },
    {
      "name": "api",
      "image": "111122223333.dkr.ecr.eu-west-1.amazonaws.com/orders-api:1.8.2",
      "essential": true,
      "portMappings": [{ "containerPort": 8080, "protocol": "tcp" }],
      "dependsOn": [{ "containerName": "migrate", "condition": "SUCCESS" }],
      "healthCheck": { "command": ["CMD-SHELL", "curl -f http://localhost:8080/health || exit 1"],
                       "interval": 30, "timeout": 5, "retries": 3, "startPeriod": 60 },
      "stopTimeout": 60,
      "logConfiguration": { "logDriver": "awslogs", "options": {
        "awslogs-group": "/ecs/orders-api", "awslogs-region": "eu-west-1", "awslogs-stream-prefix": "orders" } }
    }
  ]
}

Revisions and stopped-task diagnosis:

aws ecs register-task-definition --cli-input-json file://orders-api-taskdef.json   # returns orders-api:<n+1>
aws ecs deregister-task-definition --task-definition orders-api:5
aws ecs delete-task-definitions --task-definitions orders-api:5

# why did a task stop? stoppedReason, stopCode and per-container exit codes
aws ecs describe-tasks --cluster orders --tasks 0f1e2d3c4b5a49788796a5b4c3d2e1f0 \
  --query 'tasks[0].{reason:stoppedReason,code:stopCode,containers:containers[].{name:name,exit:exitCode,why:reason}}'

Traps

Practice questions

  1. An ECS task on Amazon EC2 runs a reporting container with memoryReservation set to 512 MiB and memory set to 1024 MiB. During month-end processing the task stops with the reason OutOfMemoryError: container killed due to memory usage. Other containers on the instance have plenty of headroom. What should the developer change?

    • A. Raise memoryReservation to 1024 MiB so ECS reserves more memory at placement time.
    • B. Add a healthCheck with more retries so ECS waits longer before stopping the container.
    • C. Mark the reporting container as essential: false so the task keeps running when it stops.
    • D. Raise the container's memory hard limit (and task memory, if set) to cover the month-end peak.

  2. A developer is choosing storage for two containers that run in the same ECS service on AWS Fargate. The web container writes log files that a log-shipping sidecar in the same task must read, and all tasks must share a common set of uploaded images that survive task replacement. Which TWO configurations meet these requirements? (Select TWO.)

    • A. An Amazon EBS volume attached to each task through configuredAtLaunch.
    • B. A bind mount volume shared by both containers of the task through mountPoints.
    • C. A Docker volume with the local driver declared in dockerVolumeConfiguration.
    • D. An Amazon EFS volume mounted by every task of the service.
    • E. Fargate ephemeral storage increased to 200 GiB with ephemeralStorage.
Answers
  1. D. The container is killed because it exceeds its hard limit; raising memory (and task memory) lets it use the instance headroom. A only changes placement reservation and leaves the 1024 MiB ceiling; B has nothing to do with memory kills; C would leave the task running without the work it exists to do.
  2. B, D. A bind mount shares files between containers of one task, and EFS gives every task the same persistent files. A creates a separate volume per task (and deletes it when the service task ends); C isn't supported on Fargate; E is per task and disappears with it.

3. IAM roles for tasks and container instances

Concept

Three roles answer three different questions, and exam distractors swap them:

Around them sit the infrastructure role (trusts ecs.amazonaws.com, passed with iam:PassedToService = ecs.amazonaws.com; ECS manages EBS volumes, Service Connect TLS, VPC Lattice targets, ECS-native blue/green listener changes, Managed Instances and Express Mode resources for you), the service-linked role AWSServiceRoleForECS (ENIs, target registration, scaling; created automatically) and roles that other services use to start tasks, such as the EventBridge role (§5).

Exam facts

Developer angle

Trust policy shared by task roles and execution roles (with confused-deputy protection):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow", "Principal": { "Service": "ecs-tasks.amazonaws.com" }, "Action": "sts:AssumeRole",
    "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:ecs:eu-west-1:111122223333:*" },
                   "StringEquals": { "aws:SourceAccount": "111122223333" } }
  }]
}

Policy for the CI role that deploys the service (it passes both roles, and only to ECS tasks):

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Resource": "*",
      "Action": ["ecs:RegisterTaskDefinition", "ecs:DescribeTaskDefinition", "ecs:UpdateService", "ecs:DescribeServices"] },
    { "Effect": "Allow", "Action": "iam:PassRole",
      "Resource": ["arn:aws:iam::111122223333:role/ordersApiTaskRole", "arn:aws:iam::111122223333:role/ordersTaskExecutionRole"],
      "Condition": { "StringEquals": { "iam:PassedToService": "ecs-tasks.amazonaws.com" } } }
  ]
}

Check identity from inside a container and open a shell with ECS Exec:

aws sts get-caller-identity          # expect assumed-role/ordersApiTaskRole/<task-id>
echo "$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"

aws ecs update-service --cluster orders --service orders-api \
  --enable-execute-command --force-new-deployment
aws ecs describe-tasks --cluster orders --tasks 0f1e2d3c4b5a49788796a5b4c3d2e1f0 \
  --query 'tasks[0].{exec:enableExecuteCommand,agents:containers[].managedAgents}'
aws ecs execute-command --cluster orders --task 0f1e2d3c4b5a49788796a5b4c3d2e1f0 \
  --container api --interactive --command "/bin/sh"

Traps

Practice questions

  1. A Python service runs as an Amazon ECS task on AWS Fargate. It must read objects from one S3 bucket. The developer attached a policy allowing s3:GetObject on that bucket to the role named in the task definition's executionRoleArn, but the application's GetObject calls still fail with AccessDenied. The image pulls and logs work. What is the MOST secure fix?

    • A. Attach AmazonS3ReadOnlyAccess to the execution role so that it covers every bucket.
    • B. Create a task role trusted by ecs-tasks.amazonaws.com with s3:GetObject on the bucket and set it as taskRoleArn.
    • C. Store an IAM user's access keys in Secrets Manager and inject them through the secrets parameter.
    • D. Add a bucket policy that allows s3:GetObject for the ecs-tasks.amazonaws.com service principal.

  2. A developer turned on ECS Exec for an existing Amazon ECS service on AWS Fargate with update-service --enable-execute-command. Running aws ecs execute-command against a task that started last week fails, and the task's enableExecuteCommand attribute is false. Which TWO actions are required to open a shell in the service's containers? (Select TWO.)

    • A. Add an inbound rule for port 22 to the task's security group and attach an EC2 key pair.
    • B. Add the ssmmessages permissions to the task execution role instead of the task role.
    • C. Start a new deployment of the service so that tasks are launched with ECS Exec enabled.
    • D. Set readonlyRootFilesystem to true so that the SSM agent cannot be tampered with.
    • E. Grant the task role the ssmmessages channel permissions that the managed SSM agent needs.
Answers
  1. B. Application code signs requests with the task role delivered through 169.254.170.2; a resource-scoped task role is least privilege. A grants broader access to a role the code never uses; C replaces temporary credentials with long-term keys; D names a service principal, not the task's role session, and grants too broadly.
  2. C, E. ECS Exec applies only to tasks started after it is enabled, and the agent inside the container uses the task role's ssmmessages permissions. A is unnecessary (no inbound ports or SSH); B is the wrong role; D breaks ECS Exec, which needs a writable root file system.

4. Environment variables and secrets

Concept

Exam facts

Developer angle

Container definition fragment that mixes all three mechanisms:

{
  "name": "api",
  "image": "111122223333.dkr.ecr.eu-west-1.amazonaws.com/orders-api:1.8.2",
  "environment": [
    { "name": "LOG_LEVEL", "value": "info" },
    { "name": "PAYMENTS_URL", "value": "https://payments.internal.example.com" }
  ],
  "environmentFiles": [
    { "value": "arn:aws:s3:::orders-config-111122223333/prod/orders-api.env", "type": "s3" }
  ],
  "secrets": [
    { "name": "DB_PASSWORD",
      "valueFrom": "arn:aws:secretsmanager:eu-west-1:111122223333:secret:prod/orders/db-AbCdEf:password::" },
    { "name": "PARTNER_API_KEY",
      "valueFrom": "arn:aws:ssm:eu-west-1:111122223333:parameter/orders/prod/partner-api-key" }
  ]
}

Inline policy for the task execution role (scoped to exactly what the definition references):

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:eu-west-1:111122223333:secret:prod/orders/db-AbCdEf" },
    { "Effect": "Allow", "Action": "ssm:GetParameters", "Resource": "arn:aws:ssm:eu-west-1:111122223333:parameter/orders/prod/partner-api-key" },
    { "Effect": "Allow", "Action": "kms:Decrypt", "Resource": "arn:aws:kms:eu-west-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" },
    { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::orders-config-111122223333/prod/orders-api.env" },
    { "Effect": "Allow", "Action": "s3:GetBucketLocation", "Resource": "arn:aws:s3:::orders-config-111122223333" }
  ]
}

Pick up a rotated secret, or read it at runtime instead (task role needs secretsmanager:GetSecretValue):

aws ecs update-service --cluster orders --service orders-api --force-new-deployment

import json, boto3

secrets = boto3.client("secretsmanager")

def db_credentials():
    # called at start-up and again after an authentication failure, so a rotation needs no redeploy
    response = secrets.get_secret_value(SecretId="prod/orders/db")
    return json.loads(response["SecretString"])

Traps

Practice questions

  1. An Amazon ECS service on AWS Fargate injects a database password from AWS Secrets Manager through the secrets parameter. After the security team rotated the secret, the running tasks keep failing to authenticate, while tasks that start later work. The team wants the new password in use within minutes with the LEAST effort and no code changes. What should a developer do?

    • A. Add secretsmanager:GetSecretValue for the secret to the task role of the service.
    • B. Shorten the secret's rotation schedule so that ECS refreshes the value more often.
    • C. Run aws ecs update-service with --force-new-deployment for the service.
    • D. Change valueFrom to reference the secret with the AWSPREVIOUS staging label.

  2. Fargate tasks in private subnets with no NAT gateway stop with ResourceInitializationError: unable to pull secrets or registry auth. The VPC has interface endpoints for Amazon ECR and an S3 gateway endpoint, and images pulled fine before a Secrets Manager reference was added to the task definition. The task execution role has only the AmazonECSTaskExecutionRolePolicy managed policy. Which TWO actions will resolve the error? (Select TWO.)

    • A. Add secretsmanager:GetSecretValue on the secret to the task role.
    • B. Create an interface VPC endpoint for Secrets Manager with private DNS enabled in the tasks' VPC.
    • C. Set assignPublicIp to ENABLED in the service's network configuration.
    • D. Raise the IMDS hop limit to 2 so that containers can obtain credentials.
    • E. Allow secretsmanager:GetSecretValue on the secret (and kms:Decrypt for its customer managed key) in the task execution role.
Answers
  1. C. A new deployment starts tasks that fetch the current secret value at container start, with no code change. A changes nothing for injected values (and the task role isn't used for valueFrom); B doesn't make ECS re-read values; D would inject the old password.
  2. B, E. The tasks need a private path to Secrets Manager and the execution role needs permission to read (and decrypt) the secret. A puts the permission on a role ECS doesn't use for secrets; C doesn't help in a private subnet without an internet route; D is an EC2 metadata setting that is irrelevant on Fargate.

5. Services standalone tasks and load balancing

Concept

Exam facts

Developer angle

Service behind an ALB target group (ip targets) with a start-up grace period:

aws ecs create-service --cluster orders --service-name orders-web \
  --task-definition orders-web:12 --desired-count 4 --launch-type FARGATE \
  --load-balancers targetGroupArn=arn:aws:elasticloadbalancing:eu-west-1:111122223333:targetgroup/orders-web/0123456789abcdef,containerName=web,containerPort=8080 \
  --health-check-grace-period-seconds 240 \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-0a1b2c3d4e5f60718,subnet-0f1e2d3c4b5a69788],securityGroups=[sg-0123456789abcdef0],assignPublicIp=DISABLED}"

Email the team whenever a task in the cluster stops (this target has no RoleArn, so the SNS topic's access policy must allow events.amazonaws.com to publish):

aws events put-rule --name orders-task-stopped --event-pattern file://task-stopped.json
aws events put-targets --rule orders-task-stopped \
  --targets Id=ops-email,Arn=arn:aws:sns:eu-west-1:111122223333:ops-alerts

task-stopped.json:

{ "source": ["aws.ecs"], "detail-type": ["ECS Task State Change"],
  "detail": { "clusterArn": ["arn:aws:ecs:eu-west-1:111122223333:cluster/orders"], "lastStatus": ["STOPPED"] } }

⚠️ Changed: since 2025-03-11 an SNS target can use an IAM execution role instead (RoleArn=<role-arn> in --targets, the role allowing sns:Publish); EventBridge falls back to the topic's access policy only when no role is set (notes/monitoring-guide.md §6). Older material may say an SNS target always needs the topic's access policy.

A Fargate task as the target of a schedule (aws scheduler create-schedule … --target file://invoice-export-target.json; expression syntax in notes/monitoring-guide.md §6):

{
  "Arn": "arn:aws:ecs:eu-west-1:111122223333:cluster/reports",
  "RoleArn": "arn:aws:iam::111122223333:role/scheduler-run-invoice-export",
  "EcsParameters": {
    "TaskDefinitionArn": "arn:aws:ecs:eu-west-1:111122223333:task-definition/invoice-export:4",
    "LaunchType": "FARGATE", "TaskCount": 1,
    "NetworkConfiguration": { "awsvpcConfiguration": {
      "Subnets": ["subnet-0a1b2c3d4e5f60718"], "SecurityGroups": ["sg-0123456789abcdef0"], "AssignPublicIp": "DISABLED" } }
  }
}

Traps

Practice questions

  1. A web application runs as an Amazon ECS service on AWS Fargate behind an Application Load Balancer. After each deployment the new tasks need about three minutes to warm their caches before /health returns HTTP 200, and ECS keeps stopping them as unhealthy, so the deployment never finishes. Failures that happen later must still be detected quickly. What should a developer do?

    • A. Raise the target group's unhealthy threshold count and health check interval to their maximum values.
    • B. Add a container healthCheck with 10 retries to the task definition's application container.
    • C. Replace the Application Load Balancer with a Network Load Balancer that uses TCP health checks.
    • D. Set healthCheckGracePeriodSeconds on the service to a value longer than the warm-up time.

  2. An Amazon ECS service on self-managed EC2 instances uses the bridge network mode behind an Application Load Balancer. The developer wants several copies of the task on each instance, with every copy receiving traffic from the load balancer. Which TWO configurations are required? (Select TWO.)

    • A. Omit hostPort (or set it to 0) in the container's port mapping so each task gets a dynamic host port.
    • B. Change the target group to target type ip so that the load balancer reaches each container directly.
    • C. Set hostPort to the same value as containerPort in every task definition revision.
    • D. Allow the instances' ephemeral port range from the load balancer's security group in the instances' security group.
    • E. Replace the Application Load Balancer with a Classic Load Balancer that listens on each host port.
Answers
  1. D. The grace period makes the scheduler ignore failing health checks only during start-up, so later failures are still caught at the normal threshold. A slows detection for the whole life of every task; B adds a container check but the ALB check still fails; C changes protocols without fixing the warm-up problem.
  2. A, D. Dynamic host ports let several tasks share an instance, and the instances must accept the whole ephemeral range from the ALB. B is for awsvpc tasks (bridge-mode targets are instances plus ports); C pins one task per instance; E is legacy and doesn't support dynamic port mapping.

6. Service auto scaling and cluster capacity

Concept

Exam facts

Developer angle

Target tracking on average CPU for a service:

aws application-autoscaling register-scalable-target --service-namespace ecs \
  --resource-id service/orders/orders-api --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 --max-capacity 20

aws application-autoscaling put-scaling-policy --service-namespace ecs \
  --resource-id service/orders/orders-api --scalable-dimension ecs:service:DesiredCount \
  --policy-name cpu-60 --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration \
  '{"TargetValue":60.0,"PredefinedMetricSpecification":{"PredefinedMetricType":"ECSServiceAverageCPUUtilization"},"ScaleOutCooldown":60,"ScaleInCooldown":180}'

EC2 capacity that follows the tasks (managed scaling with 10 % headroom):

aws ecs create-capacity-provider --name orders-asg-cp \
  --auto-scaling-group-provider "autoScalingGroupArn=arn:aws:autoscaling:eu-west-1:111122223333:autoScalingGroup:7d3e9f4a-1b2c-4d5e-8f90-a1b2c3d4e5f6:autoScalingGroupName/orders-ecs-asg,managedScaling={status=ENABLED,targetCapacity=90}"

# replaces the cluster's whole provider list: include every provider the cluster should keep
aws ecs put-cluster-capacity-providers --cluster orders \
  --capacity-providers orders-asg-cp \
  --default-capacity-provider-strategy capacityProvider=orders-asg-cp,weight=1

Traps

Practice questions

  1. An Amazon ECS service on AWS Fargate processes jobs from an Amazon SQS queue. Each task handles about 10 messages per minute, and jobs must start within 5 minutes of arriving. Queue depth swings from almost zero to tens of thousands within an hour. Which scaling approach meets the latency goal MOST reliably?

    • A. Target tracking on ECSServiceAverageCPUUtilization with a target value of 50 percent.
    • B. Target tracking on a custom backlog-per-task metric with a target of about 50 messages per task.
    • C. Scheduled scaling actions that raise the maximum capacity every morning and lower it every evening.
    • D. Predictive scaling on ECSServiceAverageMemoryUtilization in forecast-only mode.

  2. A team runs an Amazon ECS service on self-managed EC2 instances in an Auto Scaling group. When service auto scaling raises the desired count, new tasks fail placement with no container instance met all of its requirements, and the team has been adding instances by hand. The team wants instances added and removed automatically, and new tasks should usually start without waiting for instances to boot. Which TWO actions meet these requirements? (Select TWO.)

    • A. Attach a target tracking policy on average CPU utilization directly to the Auto Scaling group.
    • B. Create an Auto Scaling group capacity provider with managed scaling turned on and use it in the service's capacity provider strategy.
    • C. Set the capacity provider's targetCapacity below 100 percent so that spare capacity stays available.
    • D. Change the service's scheduling strategy from REPLICA to DAEMON.
    • E. Raise the maximum capacity of the service's scalable target in Application Auto Scaling.
Answers
  1. B. Backlog per task ties the task count to the work waiting: with 10 messages per minute per task, 50 waiting messages each is about 5 minutes of work. A tracks CPU, which may not rise with queue depth (I/O-bound work); C can't follow unpredictable swings; D in forecast-only mode never scales, and memory doesn't reflect the backlog.
  2. B, C. A capacity provider with managed scaling grows and shrinks the group from the tasks' needs, and a targetCapacity below 100 keeps headroom so tasks rarely wait. A conflicts with the policy ECS manages and ignores pending tasks; D runs exactly one task per instance and drops the desired count; E only lets the task count rise further without adding instances.

7. Rolling and blue green deployments

Concept

Exam facts

Developer angle

Rolling deployment with both failure detectors and a watch on the rollout:

aws ecs update-service --cluster orders --service orders-api --task-definition orders-api:8 \
  --deployment-configuration '{"minimumHealthyPercent":100,"maximumPercent":150,"deploymentCircuitBreaker":{"enable":true,"rollback":true},"alarms":{"alarmNames":["orders-api-5xx-rate"],"enable":true,"rollback":true}}'

aws ecs describe-services --cluster orders --services orders-api \
  --query 'services[0].deployments[].{status:status,rollout:rolloutState,reason:rolloutStateReason,td:taskDefinition}'

ECS-native blue/green settings in a create-service/update-service input file:

{
  "loadBalancers": [{
    "targetGroupArn": "arn:aws:elasticloadbalancing:eu-west-1:111122223333:targetgroup/orders-blue/0123456789abcdef",
    "containerName": "api", "containerPort": 8080,
    "advancedConfiguration": {
      "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:eu-west-1:111122223333:targetgroup/orders-green/fedcba9876543210",
      "productionListenerRule": "arn:aws:elasticloadbalancing:eu-west-1:111122223333:listener-rule/app/orders-alb/50dc6c495c0c9188/f2f7dc8efc522ab2/9683b2d02a6cabee",
      "testListenerRule": "arn:aws:elasticloadbalancing:eu-west-1:111122223333:listener-rule/app/orders-alb/50dc6c495c0c9188/0467ef3c8400ae65/b2b1a5c7d1e04f3a",
      "roleArn": "arn:aws:iam::111122223333:role/ecsInfrastructureRoleForLoadBalancers"
    }
  }],
  "deploymentConfiguration": {
    "strategy": "BLUE_GREEN", "bakeTimeInMinutes": 15,
    "lifecycleHooks": [{
      "hookTargetArn": "arn:aws:lambda:eu-west-1:111122223333:function:orders-green-smoke-test",
      "roleArn": "arn:aws:iam::111122223333:role/ecsLifecycleHookInvokeRole",
      "lifecycleStages": ["POST_TEST_TRAFFIC_SHIFT"]
    }]
  }
}

A smoke-test hook that checks the green revision through the test listener:

import os, urllib.request

def handler(event, context):
    url = os.environ["GREEN_TEST_URL"]  # e.g. the ALB test listener plus /health
    try:
        with urllib.request.urlopen(url, timeout=5) as response:
            healthy = response.status == 200
    except Exception:
        healthy = False
    return {"hookStatus": "SUCCEEDED" if healthy else "FAILED"}

Traps

Practice questions

  1. An Amazon ECS service on EC2 has a desired count of 4. The cluster has no free capacity for even one extra task, and at least 2 tasks must keep serving traffic during every deployment. Which deployment configuration should the developer use?

    • A. minimumHealthyPercent 50 and maximumPercent 100.
    • B. minimumHealthyPercent 100 and maximumPercent 200.
    • C. minimumHealthyPercent 0 and maximumPercent 100.
    • D. minimumHealthyPercent 100 and maximumPercent 125.

  2. A developer wants Amazon ECS to run blue/green deployments for an existing service behind an Application Load Balancer, test the new revision through a test listener, and keep the old revision available for 15 minutes after the switch, without using AWS CodeDeploy. Which TWO configuration changes are required? (Select TWO.)

    • A. Change the service's deployment controller to CODE_DEPLOY and create a CodeDeploy deployment group.
    • B. Add an appspec.yaml file that names the task definition, container name and container port.
    • C. Turn on the deployment circuit breaker with rollback so that ECS can return to the blue revision.
    • D. Add an alternate target group, the production and test listener rules, and an infrastructure role in the load balancer's advancedConfiguration.
    • E. Set deploymentConfiguration.strategy to BLUE_GREEN with bakeTimeInMinutes set to 15.
Answers
  1. A. 50 % keeps 2 of 4 tasks (rounded up) running, and 100 % allows no extra task, so ECS replaces 2 at a time inside existing capacity. B needs room for 8 tasks; C allows every task to stop at once; D rounds down to 5 tasks, one more than the cluster can hold.
  2. D, E. ECS-native blue/green uses the ECS controller with the BLUE_GREEN strategy and bake time, and needs the alternate target group, listener rules and an infrastructure role to move traffic. A and B describe the CodeDeploy approach the team wants to avoid; C is optional failure detection (it also works with native blue/green) and delivers neither the test listener nor the 15-minute bake.

8. Task placement strategies and constraints

Concept

Exam facts

Developer angle

A service that survives an AZ failure but packs tasks tightly inside each AZ, restricted to Graviton general-purpose instances:

aws ecs create-service --cluster orders --service-name orders-batch \
  --task-definition orders-batch:4 --desired-count 6 --launch-type EC2 \
  --placement-strategy '[{"type":"spread","field":"attribute:ecs.availability-zone"},{"type":"binpack","field":"memory"}]' \
  --placement-constraints '[{"type":"memberOf","expression":"attribute:ecs.instance-type =~ m7g.*"}]'

Custom attributes and query-language filters:

aws ecs put-attributes --cluster orders \
  --attributes name=stack,value=prod,targetId=arn:aws:ecs:eu-west-1:111122223333:container-instance/orders/0a1b2c3d4e5f60718293a4b5c6d7e8f9

# which instances would a memberOf expression select?
aws ecs list-container-instances --cluster orders --filter "attribute:stack == prod"

# one copy per instance for a standalone job
aws ecs run-task --cluster orders --task-definition cache-warmer:2 --count 3 \
  --launch-type EC2 --placement-constraints type=distinctInstance

A constraint inside an EC2 task definition (allowed for memberOf only):

{
  "family": "gpu-inference",
  "requiresCompatibilities": ["EC2"],
  "placementConstraints": [{ "type": "memberOf", "expression": "attribute:ecs.instance-type =~ g5.*" }],
  "containerDefinitions": [{ "name": "model", "image": "111122223333.dkr.ecr.eu-west-1.amazonaws.com/model:3.1", "memory": 8192 }]
}

Traps

Practice questions

  1. An Amazon ECS service runs on EC2 instances spread over three Availability Zones. It must keep serving if one Availability Zone fails, and the team wants to use as few instances as possible inside each Availability Zone to cut cost. Which placement configuration should the developer use?

    • A. A single binpack strategy on memory.
    • B. A spread strategy on instanceId followed by a random strategy.
    • C. A spread strategy on attribute:ecs.availability-zone followed by a binpack strategy on memory.
    • D. A distinctInstance constraint combined with a random strategy.

  2. After a developer added the constraint memberOf with the expression attribute:ecs.instance-type =~ c7i.* to an EC2 task definition, new tasks stay in the PENDING state, while tasks from the previous revision run normally. Which TWO conditions could explain this? (Select TWO.)

    • A. No container instance registered in the cluster has an instance type that matches the expression.
    • B. The service's binpack strategy on memory is binding and rejects instances that would keep free memory.
    • C. A memberOf constraint only takes effect when a distinctInstance constraint is also present.
    • D. The cluster query language can't apply the =~ operator to built-in attributes.
    • E. The instances that match the expression lack enough unreserved CPU or memory for the new tasks.
Answers
  1. C. Spreading across Availability Zones first protects against an AZ failure, and bin packing on memory within each AZ minimises the instances in use. A may place every task in one AZ; B balances instances but ignores both AZs and cost; D forces one task per instance, which maximises the instance count.
  2. A, E. Constraints are binding: with no matching instance, or matching instances that fail the resource check, the task can't be placed and stays PENDING. B is wrong because strategies are best effort; C invents a dependency between constraints; D is wrong because =~ is a supported pattern-match operator.

9. Amazon ECR authentication images and lifecycle

Concept

Exam facts

Developer angle

Create a repository, log in, build, tag, push and read back the digest:

REGISTRY=111122223333.dkr.ecr.eu-west-1.amazonaws.com
aws ecr create-repository --repository-name orders-api \
  --image-tag-mutability IMMUTABLE --image-scanning-configuration scanOnPush=true
aws ecr get-login-password --region eu-west-1 | docker login --username AWS --password-stdin "$REGISTRY"
docker build -t orders-api:1.8.2 .
docker tag orders-api:1.8.2 "$REGISTRY/orders-api:1.8.2"
docker push "$REGISTRY/orders-api:1.8.2"
aws ecr describe-images --repository-name orders-api --image-ids imageTag=1.8.2 \
  --query 'imageDetails[0].imageDigest'

Lifecycle policy lifecycle.json, previewed before it is applied:

{
  "rules": [
    { "rulePriority": 1, "description": "untagged: expire 7 days after push", "action": { "type": "expire" },
      "selection": { "tagStatus": "untagged", "countType": "sinceImagePushed", "countUnit": "days", "countNumber": 7 } },
    { "rulePriority": 2, "description": "release-*: keep the newest 30", "action": { "type": "expire" },
      "selection": { "tagStatus": "tagged", "tagPatternList": ["release-*"], "countType": "imageCountMoreThan", "countNumber": 30 } },
    { "rulePriority": 3, "description": "feature-*: archive after 90 days without a pull", "action": { "type": "transition", "targetStorageClass": "archive" },
      "selection": { "tagStatus": "tagged", "tagPatternList": ["feature-*"], "countType": "sinceImagePulled", "countUnit": "days", "countNumber": 90 } }
  ]
}

aws ecr start-lifecycle-policy-preview --repository-name orders-api --lifecycle-policy-text file://lifecycle.json
aws ecr get-lifecycle-policy-preview --repository-name orders-api
aws ecr put-lifecycle-policy --repository-name orders-api --lifecycle-policy-text file://lifecycle.json

Let the production account pull from the tools account's repository (aws ecr set-repository-policy --repository-name orders-api --policy-text file://repo-policy.json):

{
  "Version": "2012-10-17",
  "Statement": [{ "Sid": "AllowProdAccountPull", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::444455556666:root" },
    "Action": ["ecr:BatchGetImage", "ecr:GetDownloadUrlForLayer", "ecr:BatchCheckLayerAvailability"], "Resource": "*" }]
}

Traps

Practice questions

  1. A CI pipeline pushes every build of an image as latest to an Amazon ECR repository. After the security team turned on tag immutability, pushes fail with ImageTagAlreadyExistsException. Tags must stay immutable, and each deployment must be traceable to the exact build. What should the developer change?

    • A. Set the repository's tag mutability back to MUTABLE so that latest can be overwritten.
    • B. Tag each build with a unique value such as the commit SHA and reference that tag in the task definition.
    • C. Call batch-delete-image for the latest tag before every push.
    • D. Add ecr:PutImage for the pipeline's role to the repository policy.

  2. Amazon ECS tasks on AWS Fargate run in private subnets that have no NAT gateway and must not get any path to the internet. The tasks fail to start with CannotPullContainerError and a context canceled message when pulling from Amazon ECR in the same Region. The task execution role already has AmazonECSTaskExecutionRolePolicy. Which TWO actions will fix the image pulls? (Select TWO.)

    • A. Set assignPublicIp to ENABLED in the service's awsvpcConfiguration.
    • B. Grant the task role ecr:BatchGetImage and ecr:GetDownloadUrlForLayer.
    • C. Create the com.amazonaws.<region>.ecr.dkr and com.amazonaws.<region>.ecr.api interface endpoints with private DNS enabled.
    • D. Create an Amazon S3 gateway endpoint and associate it with the private subnets' route tables.
    • E. Create a pull through cache rule that points at the repository's own registry.
Answers
  1. B. Unique, immutable tags keep every image traceable and never collide. A breaks the immutability requirement; C removes the rollback image and keeps an ambiguous tag; D addresses permissions, but the push is rejected because the tag exists.
  2. C, D. Fargate needs both ECR interface endpoints for the registry and API calls and an S3 gateway endpoint to download the layers. A gives no route in a private subnet and violates the no-internet rule; B is the wrong role and not a network fix; E doesn't create a network path (and pull through cache needs internet access for the first pull).

10. Amazon EKS basics

Concept

Exam facts

Developer angle

Connect kubectl and confirm which identity it uses:

aws eks update-kubeconfig --region eu-west-1 --name orders-prod
aws sts get-caller-identity
kubectl get pods -n orders

EKS Pod Identity: role trust policy and the association (no change inside the cluster):

{ "Version": "2012-10-17",
  "Statement": [{ "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": ["sts:AssumeRole", "sts:TagSession"] }] }

aws eks create-pod-identity-association --cluster-name orders-prod \
  --namespace orders --service-account orders-api \
  --role-arn arn:aws:iam::111122223333:role/orders-api-pod-role

IRSA instead (needed on Fargate): annotate the service account, then reference it from the workload:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: orders-api
  namespace: orders
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/orders-api-irsa
---
apiVersion: v1
kind: Pod
metadata:
  name: orders-api
  namespace: orders
spec:
  serviceAccountName: orders-api
  containers:
    - name: api
      image: 111122223333.dkr.ecr.eu-west-1.amazonaws.com/orders-api:1.8.2

Traps

Practice questions

  1. A team runs Amazon EKS managed node groups (Linux) in three clusters. The pods of one application must read a single DynamoDB table with least privilege. The platform team wants to reuse the same IAM role in all three clusters without editing its trust policy per cluster and without creating IAM OIDC providers. What should the developer do?

    • A. Add the DynamoDB permissions to the node IAM role used by the managed node groups.
    • B. Annotate the application's service account with eks.amazonaws.com/role-arn and trust each cluster's OIDC provider.
    • C. Store an IAM user's access keys in a Kubernetes Secret mounted into the application's pods.
    • D. Create an EKS Pod Identity association for the application's service account in each cluster.

  2. A team plans to move several workloads from Amazon EKS managed node groups to Fargate profiles. Which TWO statements about EKS pods on Fargate are correct? (Select TWO.)

    • A. Workloads that run as DaemonSets must be redesigned, for example as sidecar containers.
    • B. Pods that need AWS permissions must use IAM roles for service accounts, because EKS Pod Identity doesn't support Fargate.
    • C. Pods can mount Amazon EBS volumes through the EBS CSI driver for block storage.
    • D. Fargate Spot can be enabled on a Fargate profile to lower the cost of interruptible pods.
    • E. Pods can run in public subnets and receive public IP addresses for outbound access.
Answers
  1. D. Pod Identity associations need no OIDC provider, and a role trusting pods.eks.amazonaws.com works in any cluster unchanged while scoping permissions to one service account. A gives every pod on those nodes the permissions; B is IRSA, which requires an OIDC provider and a trust-policy entry per cluster; C uses long-term credentials.
  2. A, B. DaemonSets don't run on Fargate, and Pod Identity is limited to Linux EC2 nodes, so Fargate pods use IRSA. C is wrong (EBS can't be mounted on Fargate pods); D is wrong (EKS doesn't support Fargate Spot); E is wrong (Fargate pods run only in private subnets).

Quick decision rules

Capacity and task definitions (§1–§2)

Roles and secrets (§3–§4)

Services, scaling and deployments (§5–§7)

Placement, ECR and EKS (§8–§10)

Changed vs older material

Learn the Current column; older practice material may still show the Older material may say value. Rows you confirm during /ingest are added to notes/current-facts.md.

Topic Older material may say Current (verified 2026-10-12) Source
§1 · ECS capacity types ECS has two launch types, EC2 and Fargate Three capacity types: ECS Managed Instances (since 2025-09-30), Fargate and self-managed EC2, plus external instances AWS docs
§1 · AWS Copilot CLI Supported, recommended CLI for building and deploying ECS apps End of support 2026-06-12 (announced 2026-03-06): no updates, patches or support; deployed apps keep running; use ECS Express Mode (2025-11-21) or the AWS CDK AWS docs
§1 · AWS Copilot in the DVA-C02 scope Listed under Containers (exam guide version 1.x) Exam guide version 2.1 (2024-12-12) removed it; Containers = Amazon ECR, Amazon ECS, Amazon EKS AWS docs
§2 · Fargate maximum task size 16 vCPU and 120 GB 32 vCPU with 60, 120 or 244 GB (Linux, platform version 1.4.0) AWS docs
§2 · Default log delivery mode Blocking non-blocking since 2025-06-25 (max-buffer-size default 10m); set mode: blocking or the defaultLogDriverMode account setting to keep blocking AWS docs
§2 · EBS volumes for ECS tasks Tasks can't use EBS; EFS is the only persistent option on Fargate One new EBS volume per task, configured at launch (Fargate 1.4.0+, EC2 on Nitro, Managed Instances); deleted when a service task ends AWS docs
§2 · S3 Files volumes on the EC2 launch type Not supported (course) ⚠️ unverified: the S3 User Guide and the ECS storage table say Fargate and Managed Instances only; the ECS "Configuring S3 Files" page lists EC2 as fully supported AWS docs
§3 · Role that fetches task-definition secrets, pulls images and sends logs The EC2 instance profile Task execution role: secrets on Fargate and EC2; ECR pulls and awslogs on Fargate, Managed Instances and external instances (the instance role can still pull and log for EC2 tasks) AWS docs
§5 · Load balancers for ECS services ALB, NLB and Classic Load Balancer ALB (recommended), NLB and GWLB; Classic is legacy (EC2 only, 1 per service) AWS docs
§5 · EventBridge permission to publish to an SNS target The topic's access policy must allow EventBridge The topic's access policy (principal events.amazonaws.com) or, since 2025-03-11, an IAM execution role on the target (RoleArn allowing sns:Publish); with no role set, EventBridge uses the topic policy AWS docs
§6 · Service auto scaling policy types Target tracking, step and scheduled scaling Also predictive scaling; 20-second high-resolution CPU and memory metrics for target tracking AWS docs
§7 · ECS-native deployment strategies Rolling updates only; blue/green requires CodeDeploy ROLLING, BLUE_GREEN (2025-07-17), LINEAR and CANARY (2025-10-30) on the ECS controller, with lifecycle hooks and bake time; CodeDeploy still supported AWS docs
§7 · Circuit breaker failure threshold Always 50 % of the desired count, at least 3 and at most 200 Same default, but configurable: thresholdConfiguration (COUNT, BOUNDED_PERCENT, UNBOUNDED_PERCENT) and resetOnHealthyTask; works for rolling and ECS-native blue/green deployments AWS docs
§7 · Rolling update percentage ranges Minimum 0–100 %, maximum 100–200 % (course slides) ⚠️ unverified: the docs give the defaults (100 % and 200 %) and rounding rules but no fixed upper bound for maximumPercent AWS docs
§8 · Where placement strategies and constraints apply Only the EC2 launch type Strategies: EC2 only. Constraints: EC2 and ECS Managed Instances (attributes ecs.subnet-id, ecs.availability-zone, ecs.instance-type, ecs.cpu-architecture). Fargate: neither AWS docs
§9 · ECR login command aws ecr get-login aws ecr get-login-password piped into docker login --password-stdin; get-login is gone from AWS CLI v2 AWS docs
§9 · ECR lifecycle policy actions Expire only, by image count or age since push Also transition to the archive storage class, sinceImagePulled and sinceImageTransitioned; a restore typically completes within 20 minutes AWS docs
§9 · Tag immutability Applies to every tag or none Wildcard exclusion filters (IMMUTABLE_WITH_EXCLUSION, MUTABLE_WITH_EXCLUSION) AWS docs
§9 · Basic image scanning engine Open-source Clair AWS native scanning technology with the CVE database; read results with DescribeImageScanFindings AWS docs
§9 · Pushing to a repository that doesn't exist Always create the repository first A matching CREATE_ON_PUSH repository creation template creates it on push AWS docs
§10 · EKS compute options Managed node groups, self-managed nodes and Fargate Also EKS Auto Mode (launched 2024-12-01) and EKS Hybrid Nodes AWS docs
§10 · AWS permissions for pods IRSA (or the node role) EKS Pod Identity recommended; IRSA for Fargate pods and non-EKS Kubernetes AWS docs
§10 · IAM principals' access to the Kubernetes API Edit the aws-auth ConfigMap EKS access entries (recommended); aws-auth is legacy AWS docs
§10 · EKS storage drivers EBS, EFS, FSx for Lustre and FSx for NetApp ONTAP Also FSx for OpenZFS, File Cache, Mountpoint for Amazon S3, S3 Files (through the EFS CSI driver) and instance store AWS docs