Amazon EKS — Deployments & CI/CD — Practice Exercises

3 minute read

Chapter 13 — Practice Exercises

Exercise 1: Rolling Update Strategy

Question: You have a Deployment with 10 replicas. You want to update the image with: zero downtime, maximum 2 extra pods at any time, and at least 8 pods always available. Write the strategy configuration.

Show Solution 
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2           # Up to 12 pods during update
      maxUnavailable: 2     # At least 8 pods available
  template:
    spec:
      containers:
        - name: web
          image: myapp:v2
          readinessProbe:    # Required for zero-downtime
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5

With maxSurge: 2 and maxUnavailable: 2:

  • Max pods at any time: 12 (10 + 2)
  • Min pods available: 8 (10 - 2)
  • Update completes faster than maxUnavailable: 0

Exercise 2: Blue/Green Cutover

Question: You have blue (v1) and green (v2) deployments running. The Service points to blue. Write the single command to switch all traffic to green, and the command to roll back.

Show Solution 
# Switch to green
$ kubectl patch service web -p '{"spec":{"selector":{"version":"green"}}}'

# Verify
$ kubectl get service web -o jsonpath='{.spec.selector.version}'
green

# Rollback to blue
$ kubectl patch service web -p '{"spec":{"selector":{"version":"blue"}}}'

This is instant (< 1 second) because it only changes the Service selector — no pods are created or destroyed.

Exercise 3: Helm Release Management

Question: You deployed my-app with Helm. The latest upgrade broke things. List the commands to: check the history, find which revision was working, and rollback.

Show Solution 
# 1. Check history
$ helm history my-app
REVISION    STATUS        DESCRIPTION
1           superseded    Install complete
2           superseded    Upgrade to v1.1
3           deployed      Upgrade to v1.2 (broken!)

# 2. Compare values between revisions
$ helm get values my-app --revision 2
$ helm get values my-app --revision 3

# 3. Rollback to revision 2
$ helm rollback my-app 2

# 4. Verify
$ helm status my-app
STATUS: deployed
REVISION: 4    # New revision created for rollback

Exercise 4: GitOps Architecture

Question: Design a GitOps workflow for an application with 3 environments (dev, staging, prod). What does the Git repo structure look like?

Show Solution 
k8s-manifests/
├── base/                    # Shared manifests
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
├── overlays/
│   ├── dev/
│   │   ├── kustomization.yaml
│   │   └── patch-replicas.yaml   # replicas: 1
│   ├── staging/
│   │   ├── kustomization.yaml
│   │   └── patch-replicas.yaml   # replicas: 2
│   └── production/
│       ├── kustomization.yaml
│       └── patch-replicas.yaml   # replicas: 5

ArgoCD Applications:

# One Application per environment
- name: my-app-dev
  source:
    path: overlays/dev
  destination:
    namespace: dev
  syncPolicy:
    automated: { prune: true, selfHeal: true }

- name: my-app-staging
  source:
    path: overlays/staging
  destination:
    namespace: staging

- name: my-app-production
  source:
    path: overlays/production
  destination:
    namespace: production
  # NO automated sync — require manual approval

Promotion flow: Merge to main → auto-deploy to dev → manual promote to staging → manual promote to production.

Exercise 5: CI/CD Pipeline Design

Question: Design a complete CI/CD pipeline for an EKS application that includes: building, testing, security scanning, and deploying. What tools would you use?

Show Solution 
Pipeline Stages:
┌──────────────────────────────────────────────┐
│ 1. Source: GitHub (main branch push)         │
│ 2. Build: Docker build                       │
│ 3. Unit Tests: Run in container              │
│ 4. Security Scan: Trivy (image scan)         │
│ 5. Push: ECR                                 │
│ 6. Update Manifest: Update image tag in Git  │
│ 7. Deploy: ArgoCD detects change → syncs     │
│ 8. Smoke Test: Run health checks             │
└──────────────────────────────────────────────┘

Tool choices: | Stage | Tool | Why | |——-|——|—–| | CI | GitHub Actions | Integrated with GitHub | | Registry | ECR | AWS-native, IAM auth | | Scan | Trivy | Free, comprehensive | | CD | ArgoCD | GitOps, audit trail | | Secrets | AWS Secrets Manager + ESO | No secrets in Git |

What’s Next?

Fix issues: Chapter 14 — Troubleshooting.

You may also enjoy