AWS DVA-C02 Drill: Container Deployment - Fargate ECS vs. EKS for Minimal Ops

Jeff’s Note

#

Jeff’s Note

#

“Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.”

“For DVA-C02 candidates, the confusion often lies in distinguishing between container packaging methods and the operational complexity of different orchestration platforms. In production, this is about knowing exactly which AWS container service aligns with your team’s Kubernetes expertise and how Fargate eliminates infrastructure management. Let’s drill down.”

The Certification Drill (Simulated Question)

#

Scenario

#

TechNova Solutions is building their inaugural cloud-native application on AWS. The development team lead needs to create a proof-of-concept to demonstrate the viability of their container-based architecture before committing to a full migration strategy. The leadership team has mandated that this POC should require minimal DevOps overhead, allowing developers to focus on application logic rather than infrastructure management. The proof-of-concept must validate the complete lifecycle: packaging, storing, and running containerized workloads.

The Requirement:

#

Select TWO actions that will deploy the containerized proof-of-concept application with the LEAST operational effort.

The Options

#

• A) Package the application into a .zip file by using a command line tool. Upload the package to Amazon S3.
• B) Package the application into a container image by using the Docker CLI. Upload the image to Amazon Elastic Container Registry (Amazon ECR).
• C) Deploy the application to an Amazon EC2 instance by using AWS CodeDeploy.
• D) Deploy the application to Amazon Elastic Kubernetes Service (Amazon EKS) on AWS Fargate.
• E) Deploy the application to Amazon Elastic Container Service (Amazon ECS) on AWS Fargate.

Correct Answer

#

B and E

Quick Insight: The Developer Efficiency Imperative

#

For DVA-C02, AWS evaluates your ability to choose implementation paths that minimize undifferentiated heavy lifting. Container deployment isn’t just about Docker commands—it’s about understanding:

• Image lifecycle management (ECR vs. S3 vs. third-party registries)
• Orchestration complexity (ECS native simplicity vs. EKS Kubernetes overhead)
• Infrastructure abstraction levels (Fargate serverless vs. EC2 self-managed)

The exam specifically tests whether you recognize that ECS on Fargate provides the fastest path to production for teams without Kubernetes expertise, while ECR is AWS’s native, integrated container registry optimized for both ECS and EKS.

Content Locked: The Expert Analysis

#

You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?

The Expert’s Analysis

#

Correct Answer

#

Options B and E

The Winning Logic

#

Option B (Amazon ECR + Docker CLI):

• Docker is the industry-standard containerization tool—the docker build and docker push commands are fundamental to any container workflow
• ECR provides native AWS integration with:
  • IAM-based authentication (no separate credential management)
  • Automatic image scanning for vulnerabilities
  • Lifecycle policies for automated image cleanup
  • Seamless integration with ECS/EKS task definitions

Developer Implementation:

# Authenticate Docker to ECR
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.us-east-1.amazonaws.com

# Build the container image
docker build -t technova-poc:v1.0 .

# Tag for ECR
docker tag technova-poc:v1.0 123456789012.dkr.ecr.us-east-1.amazonaws.com/technova-poc:v1.0

# Push to ECR
docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/technova-poc:v1.0

Option E (ECS on Fargate):

• Fargate eliminates ALL infrastructure management—no EC2 instances to patch, scale, or monitor
• ECS is AWS-native—simpler API surface than Kubernetes:
  • Task Definitions (JSON) vs. complex Kubernetes YAML manifests
  • Service auto-scaling without HPA/VPA complexity
  • Native integration with ALB/NLB for load balancing
• Fastest time-to-deployment for teams without Kubernetes expertise
• Pay-per-task pricing model—ideal for POCs with variable usage

ECS Task Definition Example:

{
  "family": "technova-poc",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [
    {
      "name": "app",
      "image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/technova-poc:v1.0",
      "portMappings": [
        {
          "containerPort": 8080,
          "protocol": "tcp"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/technova-poc",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

The Trap (Distractor Analysis)

#

Why not Option A (ZIP + S3)?

• Conceptual mismatch: This approach is for AWS Lambda deployment packages or Elastic Beanstalk source bundles, NOT container-based applications
• Containers require image registries: S3 doesn’t provide the container image manifest, layer caching, or registry API that Docker expects
• No container runtime: S3 is object storage—it can’t execute container images

Why not Option C (EC2 + CodeDeploy)?

• High operational overhead: You must:
  • Provision and manage EC2 instances (AMI selection, patching, monitoring)
  • Install and configure Docker runtime
  • Implement instance scaling logic
  • Configure CodeDeploy agents and deployment groups
• Violates “LEAST effort” constraint: While technically valid for container deployment, this is the most complex option
• CodeDeploy is designed for application code deployment, not container orchestration (use ECS/EKS native deployment instead)

Why not Option D (EKS on Fargate)?

• Excessive complexity for a POC: EKS requires understanding:
  • Kubernetes architecture (control plane, nodes, pods, services)
  • kubectl CLI and manifest management
  • RBAC and service accounts
  • Ingress controllers vs. ALB integration
• Longer learning curve: Developers need Kubernetes expertise
• Higher setup overhead: EKS cluster creation takes 15-20 minutes vs. ECS task launch in seconds
• Use EKS when you NEED Kubernetes features (Helm charts, existing K8s investments, multi-cloud portability)

The Technical Blueprint

#

Complete Deployment Workflow (Developer Perspective)

#

#!/bin/bash
# Step 1: Create ECR Repository
aws ecr create-repository \
    --repository-name technova-poc \
    --region us-east-1

# Step 2: Build and Push Container Image
$(aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.us-east-1.amazonaws.com)
docker build -t technova-poc:latest .
docker tag technova-poc:latest 123456789012.dkr.ecr.us-east-1.amazonaws.com/technova-poc:latest
docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/technova-poc:latest

# Step 3: Register ECS Task Definition
aws ecs register-task-definition \
    --cli-input-json file://task-definition.json

# Step 4: Create ECS Cluster (Fargate)
aws ecs create-cluster \
    --cluster-name technova-poc-cluster \
    --region us-east-1

# Step 5: Deploy ECS Service on Fargate
aws ecs create-service \
    --cluster technova-poc-cluster \
    --service-name technova-poc-service \
    --task-definition technova-poc:1 \
    --desired-count 2 \
    --launch-type FARGATE \
    --network-configuration "awsvpcConfiguration={subnets=[subnet-abc123,subnet-def456],securityGroups=[sg-0123456789abcdef0],assignPublicIp=ENABLED}"

IAM Policy for Developer (Least Privilege)

#

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:GetAuthorizationToken",
        "ecr:BatchCheckLayerAvailability",
        "ecr:GetDownloadUrlForLayer",
        "ecr:PutImage",
        "ecr:InitiateLayerUpload",
        "ecr:UploadLayerPart",
        "ecr:CompleteLayerUpload"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ecs:RegisterTaskDefinition",
        "ecs:CreateService",
        "ecs:UpdateService",
        "ecs:DescribeServices"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole"
      ],
      "Resource": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
    }
  ]
}

The Comparative Analysis

#

For DVA-C02 Exam:

• Choose ECS on Fargate when you see: “least operational effort,” “container-based,” “no Kubernetes requirement”
• Choose EKS when you see: “existing Kubernetes manifests,” “Helm charts,” “Kubernetes expertise”
• Choose ECR for ALL container image storage questions (unless explicitly integrating with DockerHub/Quay)

Real-World Application (Practitioner Insight)

#

Exam Rule

#

“For the exam, always pick ECS on Fargate + ECR when the question emphasizes ‘minimal operational overhead’ for container deployments WITHOUT mentioning Kubernetes.”

Real World

#

“In reality, we might use EKS on Fargate even for simpler workloads if:

• The company has standardized on Kubernetes across multi-cloud environments
• We need advanced features like Istio service mesh or Argo CD
• The team already has deep Kubernetes expertise and internal tooling built around kubectl

However, for true POCs and startups, ECS on Fargate remains the pragmatic choice—you can always migrate to EKS later if Kubernetes-specific features become necessary. The migration path exists through AWS Copilot CLI or manual task definition conversion.”

Production Considerations:

• Add Application Load Balancer for production traffic distribution
• Enable Container Insights for enhanced CloudWatch metrics
• Implement AWS Secrets Manager for sensitive environment variables (never hardcode in task definitions)
• Use ECS Service Auto Scaling with target tracking based on CPU/Memory or custom CloudWatch metrics
• Configure ECS Exec for secure debugging access (replaces SSH into containers)

Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the AWS DVA-C02 exam. Always refer to the official AWS documentation for the most current service features and best practices.