Components & Configuration Deep Dive

The settings and concepts most likely to show up as the crux of a scenario question.

AWS Exam Thinking

Requirement → Keywords → Expected Answer → why every distractor fails.

Integrations & Architecture Example

Related Services

End-to-End Architecture Example

Best Practices & Common Exam Traps

When to Use / When NOT to Use

Comparison — ECS vs EKS

Comparison — ECS vs Fargate

Comparison — Fargate vs EC2 Launch Type

Common Exam Traps

Memory Anchors

• "Execution pulls, task calls." — Execution role pulls the image/writes logs; task role is what your code calls AWS with.
• "No host, no bridge." — Fargate has no shared EC2 host, so it can't use bridge/host networking — only awsvpc.
• "IP not instance." — Fargate ALB target groups register by task IP, never by EC2 instance ID.
• "Fargate is compute, not a competitor to ECS." — The real either/or is EC2 launch type vs Fargate, both running under ECS (or EKS).
• "Portability = EKS; simplicity = ECS." — If the scenario mentions existing Kubernetes tooling or multi-cloud, lean EKS; otherwise lean ECS.
• "Blue/green = CodeDeploy + alarms + instant rollback." — Whenever a question wants automatic rollback tied to error metrics, that's the blue/green + CodeDeploy pattern, not rolling.

Hands-On Lab — Build, Break, and Fix Containers on AWS

Three self-contained exercises using AWS CLI v2 in the eu-west-1 region. Exercise 1 builds the full path from a Docker image to a Fargate service behind an ALB. Exercise 2 deliberately breaks the task execution role to reproduce and diagnose a CannotPullContainerError — the hands-on version of the task-role-vs-execution-role trap covered in Components and Best Practices. Exercise 3 is a short EKS/Fargate comparison, kept brief since EKS is tested at the conceptual level on DVA-C02. Replace placeholder values (account ID, VPC/subnet/security-group IDs) with your own before running.

Exercise 1 — Docker Image → ECR → ECS Fargate Behind an ALB

1. Create a private ECR repository with scan-on-push enabled.

   aws ecr create-repository \
     --repository-name demo-web-app \
     --region eu-west-1 \
     --image-scanning-configuration scanOnPush=true

   the command returns a repository object whose repositoryUri looks like 123456789012.dkr.ecr.eu-west-1.amazonaws.com/demo-web-app
2. Build a minimal Docker image locally from a Dockerfile in the current directory (e.g. an nginx-based image serving a static page on port 80).

   docker build -t demo-web-app:v1 .

   docker images lists demo-web-app:v1
3. Authenticate Docker to ECR, then tag and push the image (replace 123456789012 with your account ID).

   aws ecr get-login-password --region eu-west-1 \
     | docker login --username AWS --password-stdin 123456789012.dkr.ecr.eu-west-1.amazonaws.com
   
   docker tag demo-web-app:v1 123456789012.dkr.ecr.eu-west-1.amazonaws.com/demo-web-app:v1
   
   docker push 123456789012.dkr.ecr.eu-west-1.amazonaws.com/demo-web-app:v1

   the pushed digest appears when you run aws ecr describe-images --repository-name demo-web-app --region eu-west-1

   The get-login-password token is valid for 12 hours — this is the same mechanism CI/CD pipelines use, just invoked manually here.

4. Create the task execution role — the identity the ECS agent (not your app) uses to pull the image and write logs.

   cat > ecs-trust-policy.json <<'EOF'
   {
     "Version": "2012-10-17",
     "Statement": [{
       "Effect": "Allow",
       "Principal": { "Service": "ecs-tasks.amazonaws.com" },
       "Action": "sts:AssumeRole"
     }]
   }
   EOF
   
   aws iam create-role \
     --role-name demoWebAppExecutionRole \
     --assume-role-policy-document file://ecs-trust-policy.json
   
   aws iam attach-role-policy \
     --role-name demoWebAppExecutionRole \
     --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy

   aws iam list-attached-role-policies --role-name demoWebAppExecutionRole shows AmazonECSTaskExecutionRolePolicy attached
5. Register a Fargate-compatible task definition referencing the pushed image and the execution role.

   cat > task-def.json <<'EOF'
   {
     "family": "demo-web-app",
     "networkMode": "awsvpc",
     "requiresCompatibilities": ["FARGATE"],
     "cpu": "256",
     "memory": "512",
     "executionRoleArn": "arn:aws:iam::123456789012:role/demoWebAppExecutionRole",
     "containerDefinitions": [{
       "name": "demo-web-app",
       "image": "123456789012.dkr.ecr.eu-west-1.amazonaws.com/demo-web-app:v1",
       "portMappings": [{ "containerPort": 80, "protocol": "tcp" }],
       "essential": true,
       "logConfiguration": {
         "logDriver": "awslogs",
         "options": {
           "awslogs-group": "/ecs/demo-web-app",
           "awslogs-region": "eu-west-1",
           "awslogs-stream-prefix": "demo"
         }
       }
     }]
   }
   EOF
   
   aws ecs register-task-definition \
     --cli-input-json file://task-def.json \
     --region eu-west-1

   response includes "taskDefinitionArn": ".../demo-web-app:1"
6. Create the ECS cluster and an ALB target group of type ip in your VPC (replace the vpc-id).

   aws ecs create-cluster --cluster-name demo-cluster --region eu-west-1
   
   aws elbv2 create-target-group \
     --name demo-web-app-tg \
     --protocol HTTP --port 80 \
     --vpc-id vpc-0123456789abcdef0 \
     --target-type ip \
     --health-check-path / \
     --region eu-west-1

   target group ARN is returned; note it for the next steps — target type ip is the only valid option because Fargate tasks have no backing EC2 instance
7. Create the ALB, a listener forwarding to the target group, then create the ECS service (replace subnet/security-group IDs and the target-group/execution-role ARNs).

   aws elbv2 create-load-balancer \
     --name demo-web-app-alb \
     --subnets subnet-aaa111 subnet-bbb222 \
     --security-groups sg-alb0001 \
     --scheme internet-facing --type application \
     --region eu-west-1
   
   aws elbv2 create-listener \
     --load-balancer-arn arn:aws:elasticloadbalancing:eu-west-1:123456789012:loadbalancer/app/demo-web-app-alb/abc123 \
     --protocol HTTP --port 80 \
     --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:eu-west-1:123456789012:targetgroup/demo-web-app-tg/def456 \
     --region eu-west-1
   
   aws ecs create-service \
     --cluster demo-cluster \
     --service-name demo-web-app-svc \
     --task-definition demo-web-app:1 \
     --desired-count 2 \
     --launch-type FARGATE \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-aaa111,subnet-bbb222],securityGroups=[sg-tasks0001],assignPublicIp=DISABLED}" \
     --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:eu-west-1:123456789012:targetgroup/demo-web-app-tg/def456,containerName=demo-web-app,containerPort=80" \
     --region eu-west-1

   aws ecs describe-services --cluster demo-cluster --services demo-web-app-svc --region eu-west-1 shows runningCount reach desiredCount, and aws elbv2 describe-target-health shows both targets healthy
8. Verify end to end by hitting the ALB's public DNS name.

   curl -I http://$(aws elbv2 describe-load-balancers \
     --names demo-web-app-alb --region eu-west-1 \
     --query "LoadBalancers[0].DNSName" --output text)

   HTTP/1.1 200 OK from your container, served through the ALB → target group (ip) → Fargate task path

Exercise 2 — Break the Task Execution Role, Reproduce CannotPullContainerError, Fix It

1. Detach the ECR/logs policy from the execution role used in Exercise 1, simulating a misconfiguration.

   aws iam detach-role-policy \
     --role-name demoWebAppExecutionRole \
     --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy

   aws iam list-attached-role-policies --role-name demoWebAppExecutionRole now returns an empty AttachedPolicies list
2. Force a new deployment so ECS launches fresh tasks under the now-crippled role.

   aws ecs update-service \
     --cluster demo-cluster \
     --service demo-web-app-svc \
     --force-new-deployment \
     --region eu-west-1

   the service's deployment stays stuck below desiredCount; new tasks appear briefly then disappear from RUNNING status
3. List the stopped tasks and inspect the stop reason.

   aws ecs list-tasks \
     --cluster demo-cluster \
     --desired-status STOPPED \
     --region eu-west-1
   
   aws ecs describe-tasks \
     --cluster demo-cluster \
     --tasks <task-arn-from-previous-command> \
     --region eu-west-1 \
     --query "tasks[0].{stoppedReason:stoppedReason,container:containers[0].reason}"

   stoppedReason contains something like CannotPullContainerError: ... 403: Forbidden or a ResourceInitializationError — the image pull failed before your application code ever ran
4. Diagnose using the same rule taught in the Components tab: if the failure happens before the container starts (image pull, log stream creation), it's the execution role, not the task role. Confirm by checking that no task role permission is involved in this failure path at all — the trust policy and role are the same one referenced as executionRoleArn in task-def.json. you can point at the exact task-definition field (executionRoleArn) responsible, not taskRoleArn
5. Fix it by reattaching the policy, then force another deployment.

   aws iam attach-role-policy \
     --role-name demoWebAppExecutionRole \
     --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
   
   aws ecs update-service \
     --cluster demo-cluster \
     --service demo-web-app-svc \
     --force-new-deployment \
     --region eu-west-1

   within a few minutes, runningCount returns to desiredCount and aws elbv2 describe-target-health shows targets healthy again

Exercise 3 — EKS + Fargate Comparison (Brief)

1. Create an EKS cluster with a default Fargate profile using eksctl.

   eksctl create cluster \
     --name demo-eks \
     --region eu-west-1 \
     --fargate

   cluster creation completes (10-15 minutes) and kubectl get nodes shows no visible EC2 nodes — pods run on AWS-managed Fargate compute instead
2. Add a Fargate profile scoped to a dedicated application namespace.

   eksctl create fargateprofile \
     --cluster demo-eks \
     --region eu-west-1 \
     --name demo-web-app-profile \
     --namespace demo-web-app

   eksctl get fargateprofile --cluster demo-eks --region eu-west-1 lists the new profile
3. Deploy the same ECR image as a Kubernetes Deployment into that namespace.

   kubectl create namespace demo-web-app
   
   cat > deployment.yaml <<'EOF'
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: demo-web-app
     namespace: demo-web-app
   spec:
     replicas: 2
     selector:
       matchLabels: { app: demo-web-app }
     template:
       metadata:
         labels: { app: demo-web-app }
       spec:
         containers:
         - name: demo-web-app
           image: 123456789012.dkr.ecr.eu-west-1.amazonaws.com/demo-web-app:v1
           ports:
           - containerPort: 80
   EOF
   
   kubectl apply -f deployment.yaml

   kubectl get pods -n demo-web-app shows 2 pods in Running state, each scheduled onto Fargate (no node name resembling an EC2 instance)

   Notice what stayed identical to Exercise 1: the ECR image URI and region. What changed: the API surface (Kubernetes manifests + kubectl instead of task definitions + aws ecs), and per-pod IAM would use IRSA rather than a task execution role.

Flashcards — 22 Cards

Click card to flip. Mark right or wrong to track score.

Practice Quiz — 12 Questions

DVA-C02 scenario style, Easy → Specialty. Select an answer to reveal the explanation.