AWS for DevOps — CI/CD Practice Exercises

4 minute read

6.6 — CI/CD Practice Exercises

Test your understanding of CodeBuild, CodeDeploy, CodePipeline, deployment strategies, and GitHub integration.

Exercise 1 — buildspec.yml Debugging

A team has this buildspec.yml but their Docker image never gets pushed to ECR. The build shows SUCCEEDED. What is wrong?

version: 0.2

phases:
  pre_build:
    commands:
      - echo Logging in to ECR...
      - aws ecr get-login-password --region ap-south-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.ap-south-1.amazonaws.com

  build:
    commands:
      - echo Building Docker image...
      - docker build -t my-app .

  post_build:
    commands:
      - echo Pushing image...
      - docker tag my-app:latest 123456789012.dkr.ecr.ap-south-1.amazonaws.com/my-app:latest
      - docker push 123456789012.dkr.ecr.ap-south-1.amazonaws.com/my-app:latest

The CodeBuild project has privilegedMode=false.

Show Answer

Two issues:

  1. privilegedMode is false — Docker-in-Docker requires privilegedMode=true on the CodeBuild project. Without it, docker build silently fails but doesn’t stop the build.

  2. post_build runs even if build fails — The post_build phase executes regardless of whether previous phases succeeded. The team should check $CODEBUILD_BUILD_SUCCEEDING in post_build:

  post_build:
    commands:
      - |
        if [ "$CODEBUILD_BUILD_SUCCEEDING" = "1" ]; then
          docker tag my-app:latest 123456789012.dkr.ecr.ap-south-1.amazonaws.com/my-app:latest
          docker push 123456789012.dkr.ecr.ap-south-1.amazonaws.com/my-app:latest
        else
          echo "Build failed, skipping push"
        fi

Fix: Set privilegedMode=true on the project and add the CODEBUILD_BUILD_SUCCEEDING check.

Exercise 2 — CodeDeploy Lifecycle

Put these CodeDeploy lifecycle events in the correct order:

  • ApplicationStart
  • ValidateService
  • BeforeInstall
  • Install
  • ApplicationStop
  • AfterInstall

Which events can you write hooks for, and which are handled internally by CodeDeploy?

Show Answer

Correct order:

  1. ApplicationStop — hook (your script)
  2. DownloadBundle — internal (CodeDeploy downloads revision from S3)
  3. BeforeInstall — hook (your script)
  4. Install — internal (CodeDeploy copies files per files: section)
  5. AfterInstall — hook (your script)
  6. ApplicationStart — hook (your script)
  7. ValidateService — hook (your script)

You can write hooks for: ApplicationStop, BeforeInstall, AfterInstall, ApplicationStart, ValidateService

Handled internally by CodeDeploy: DownloadBundle, Install

Exercise 3 — Choose the Deployment Strategy

For each scenario, recommend a deployment strategy and explain why.

# Scenario
A A startup’s development environment — fast iteration, cost matters
B A bank’s payment processing API — zero downtime, instant rollback required
C An e-commerce platform serving 10 million requests/day — zero downtime, gradual validation needed
D A batch processing worker that runs nightly — short downtime acceptable
Show Answer
# Strategy Why
A In-place / All-at-once Fast, cheap, downtime acceptable in dev
B Blue/Green Zero downtime + instant rollback by switching traffic back to Blue environment
C Canary Shift 5-10% traffic first, monitor error rates and latency, then shift 100% — minimises blast radius
D In-place (OneAtATime) Brief downtime is fine; simple and cost-effective for batch workers

Key insight: Production APIs with high traffic should always use Canary or Blue/Green. Development environments can use simpler (and cheaper) strategies.

Exercise 4 — Pipeline Artefact Troubleshooting

A pipeline has three stages:

Source (GitHub) → Build (CodeBuild) → Deploy (CodeDeploy)

The Build stage succeeds, but Deploy fails with:

ActionExecution failed. Error: Artifact 'SourceOutput' not found

The pipeline JSON shows:

  • Source action: outputArtifacts: [{ "name": "SourceCode" }]
  • Build action: inputArtifacts: [{ "name": "SourceOutput" }]

What is the problem and how do you fix it?

Show Answer

Problem: Artefact name mismatch.

The Source stage outputs an artefact named SourceCode, but the Build stage expects an artefact named SourceOutput. CodePipeline passes artefacts between stages by name — they must match exactly.

Fix: Make the names consistent:

// Source stage
"outputArtifacts": [{ "name": "SourceOutput" }]

// Build stage
"inputArtifacts": [{ "name": "SourceOutput" }]

Or change both to any matching name. The key rule: the outputArtifacts name of one action must exactly match the inputArtifacts name of the consuming action.

Exercise 5 — GitHub Integration Design

Your team wants to set up CI/CD for a microservice:

  • Source code on GitHub (main branch for releases, feature branches for PRs)
  • PRs: Run tests and report status back to GitHub ✅/❌
  • Merge to main: Build → Deploy to staging → Manual approval → Deploy to production
  • Use Blue/Green deployment for production

Design the AWS resources needed. List the services, how they connect, and any key configuration settings.

Show Answer

AWS Resources:

  1. CodeStar Connection — Connects AWS to GitHub org
    • Complete handshake in console after creating via CLI
  2. CodeBuild Project: my-app-pr-check — For pull requests
    • Source: GitHub with webhook
    • Webhook filter: EVENT=PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
    • reportBuildStatus=true (shows ✅/❌ on PRs)
    • Artefacts: None (test only)
  3. CodeBuild Project: my-app-build — For pipeline builds
    • Source: CodePipeline (receives artefact from Source stage)
    • Builds Docker image, pushes to ECR
    • Outputs deployment artefact (appspec.yml + scripts)
  4. CodePipeline: my-app-pipeline
    • Source stage: CodeStarSourceConnection → GitHub main branch, DetectChanges=true
    • Build stage: my-app-build CodeBuild project
    • Deploy-Staging stage: CodeDeploy to staging deployment group
    • Approval stage: Manual approval with SNS notification
    • Deploy-Production stage: CodeDeploy to production deployment group
  5. CodeDeploy Application: my-app
    • Staging deployment group: In-place, HalfAtATime
    • Production deployment group: Blue/Green with ALB traffic shift
    • Auto-rollback on failure and CloudWatch alarms
  6. Supporting resources:
    • S3 bucket for pipeline artefacts
    • ECR repository for Docker images
    • ALB with two target groups (Blue + Green)
    • SNS topic for approval notifications
    • IAM roles: CodePipeline, CodeBuild, CodeDeploy, EC2 instance profile

Next Chapter → Containers

Updated:

You may also enjoy