Kubernetes / CI/CDIntermediate8-12 hours
Deploy a Containerised App to EKS with GitHub Actions
DockerAmazon EKSAmazon ECRGitHub ActionsKubernetesIAMHelm
Best for: Cloud/DevOps Engineer, Platform Engineer
Overview
Build a complete end-to-end deployment pipeline for a containerised application on Amazon EKS. You will write a production-ready Dockerfile, push images to ECR, define Kubernetes manifests with proper health checks and resource limits, and automate the entire process with GitHub Actions using OIDC for authentication - no long-lived access keys.
What you will build
- →Containerise a sample web application with a multi-stage, production-ready Dockerfile
- →Create an ECR repository and configure an OIDC-based IAM role for GitHub Actions
- →Provision an EKS cluster and deploy the application using a Kubernetes Deployment and Service
- →Write readiness and liveness probes to enable zero-downtime rolling updates
- →Build a GitHub Actions workflow: build + test on PR, build + push to ECR + deploy to EKS on merge to main
- →Configure resource requests and limits on the Deployment
Before you start
- •Basic Docker knowledge - building images and running containers
- •An AWS account with CLI access configured
- •Familiarity with basic Kubernetes concepts (Pods, Deployments, Services)
- •A GitHub account
Deliverables
A complete submission should include all of the following.
- ✓A multi-stage Dockerfile that produces a lean, minimal production image
- ✓Kubernetes manifests: Deployment with resource requests/limits, readiness and liveness probes; Service; optionally an Ingress
- ✓An OIDC-based IAM role for GitHub Actions with least-privilege ECR and EKS permissions
- ✓A GitHub Actions workflow that builds on PR and deploys on merge to main
- ✓A README documenting the pipeline, how to run locally, and how to roll back a bad deploy
Stretch goals
Optional extras that demonstrate deeper understanding and make your project stand out.
- +Package the Kubernetes manifests as a Helm chart
- +Add image vulnerability scanning with Trivy before the ECR push step
- +Add a staging environment with a manual approval gate before production
- +Configure Slack or email notifications on deploy success and failure
- +Add an HPA to auto-scale the Deployment based on CPU utilisation
Interview talking points
When you discuss this project in an interview, be ready to answer these questions specifically.
- 1Why you used OIDC for GitHub Actions instead of long-lived IAM access keys - no credentials to rotate or leak
- 2How readiness probes prevent traffic from reaching pods that are not ready, enabling zero-downtime rolling updates
- 3The difference between liveness and readiness probes and the consequences of misconfiguring each
- 4How you would roll back a bad deployment - kubectl rollout undo, and how to make rollback even safer with ArgoCD
- 5What happens to in-flight requests during a rolling update and how your terminationGracePeriodSeconds setting handles it
- 6Why you set both resource requests and limits, and what happens without them