DevSecOps Real-World Project: Build and Operate CI/CD on EKS

Microservices-based pharmaceutical application with a front-end (Pharma UI) and eight back-end microservices, already committed to GitHub. Get introduced to the GitHub organization structure, the full DevOps tool stack (Terraform, GitHub Actions, Docker, ArgoCD, EKS), and the AWS services (VPC, EKS, ECR, RDS, IAM, Secrets Manager) you'll provision from scratch throughout this course.

See the complete architecture before you build it. This covers how infrastructure gets provisioned through Terraform modules (starting with dev, later QA and production), how Terraform runs through GitHub Actions with an approval gate for safety, and the full CI/CD pipeline flow — from code push through testing, image scanning, ECR, Helm charts, and automatic deployment to EKS via ArgoCD.

This video covers prerequisites for the project: installing AWS CLI v2, Terraform (≥1.1.1), kubectl, Helm v3, Git, Python 3, plus optional GitHub CLI and VS Code. Requires AWS and GitHub accounts. Recommends creating a ~/DevOps/ZenPharma directory structure exactly as shown to avoid path-related issues later.

Before writing any Terraform code, get the full roadmap for provisioning infrastructure — configuring AWS credentials, setting up GitHub organization and repositories (frontend, backend, infra, GitOps), enabling SSH authentication, creating an S3 backend for Terraform state (with separate paths for dev, QA, and prod), and building the VPC module. By the end of this section, all AWS resources — VPC, IAM, EKS, ECR, RDS, and Secrets Manager — will be provisioned.

A guided walkthrough of the documentation before diving into hands-on execution — covering AWS credential setup, GitHub organization and repository structure (forking front-end and back-end, creating infra and GitOps repos), passwordless SSH authentication, and creating the S3 bucket for Terraform state with versioning and encryption enabled. Understand each step conceptually here before executing it in the next video.

Hands-on setup: create an IAM admin user and configure AWS CLI credentials, clone the front-end and back-end repositories using SSH authentication, create the infra and GitOps repositories locally, and set up an S3 bucket with versioning, encryption, and public access blocked — the foundation Terraform needs before provisioning any infrastructure.

Before writing any code, understand how the VPC module is structured and why — the module/envs folder layout, required subnets (public for load balancers, private for EKS and RDS), key input variables (CIDR blocks, project, environment), and why we use Terraform's official AWS VPC registry module instead of writing one from scratch. Also covers the separate backend state file per environment (dev, QA, prod) and why that separation matters.

Hands-on: create the VPC module files (variables.tf, main.tf, output.tf) and the dev environment files (backend.tf, provider.tf, main.tf), then run terraform init to download the required modules and terraform plan to verify the code creates 24 resources as expected. Code is committed and tagged so you can pull it directly if you get stuck.

Run terraform apply to provision the VPC module's 24 resources — subnets, route tables, NAT gateway, internet gateway, security groups, and more — then validate everything in the AWS console. Includes an important cost note: NAT Gateway is chargeable, so remember to delete resources when not actively using them.

Build the IAM module with three key IRSA roles — External Secret Operator (to pull secrets from Secrets Manager), ArgoCD (to manage cluster resources), and AWS Load Balancer Controller — plus a GitHub Actions OIDC role for passwordless authentication between GitHub and ECR. Note: this module depends on the EKS module's OIDC provider, so it's written and committed here but can't be applied until EKS is created.

Build the EKS module using Terraform's official registry module — configuring the Kubernetes version, managed node group sizing (desired, min, max), and essential add-ons (VPC CNI, kube-proxy, CoreDNS, EKS Pod Identity Agent). Outputs include the cluster name, endpoint, and OIDC provider ARN needed by the IAM module.

Build the remaining three modules — ECR (creating registries for all nine microservices), RDS (PostgreSQL database with credentials pulled from Secrets Manager), and Secrets Manager (storing DB and JWT credentials). Then wire everything together in the root main.tf, calling all six modules (VPC, IAM, EKS, RDS, ECR, Secrets Manager), and see how easily the same setup can be replicated for a QA environment.

Run terraform init, plan, and apply across all six modules to provision the complete infrastructure — around 90 resources including the EKS cluster and RDS database. Covers creating terraform.tfvars for sensitive values, troubleshooting an S3 state lock issue, and fixing a missing output error before the full apply completes successfully in about 25-30 minutes.

Validate everything Terraform provisioned — nine ECR registries, the EKS cluster with its node group, two secrets in Secrets Manager, and the RDS database instance — confirming the infrastructure code works as expected. Then run terraform destroy to tear down all 99 resources, since going forward, infrastructure will be provisioned through pipelines instead of manual commands.

In the previous section, we ran Terraform manually from our own computer. Now we shift to automation — this video previews how GitHub Actions will run Terraform for us, with built-in approval steps so changes to infrastructure are always reviewed before they happen.

Before building any pipeline, it helps to understand the basic vocabulary. This video breaks down what an "event" is (what starts a pipeline), what a "job" and "step" are (what the pipeline actually does), and what a "runner" is (the machine that does the work) — all explained in plain terms with simple examples.

Learn the real-world difference between opening a pull request and merging code — and why this distinction matters for infrastructure changes. A pull request lets you safely preview what Terraform will do, while merging is what actually applies the change to your cloud resources.

Time to build the actual pipeline file. This video walks through creating the workflow that runs Terraform plan automatically on a pull request, applies the change after approval when merged to main, and can even destroy infrastructure safely when triggered manually.

Your pipeline needs sensitive information like AWS credentials and database passwords to work — but you should never put these directly in your code. This video shows you how to securely store and use secrets and variables inside GitHub so your pipeline stays safe.

Prevent accidental or unreviewed changes to your infrastructure by setting up branch protection rules and an approval process. This ensures every change goes through a pull request and gets a manual "yes, go ahead" before anything actually happens in AWS.

Everything comes together here. Watch the complete pipeline run from start to finish — creating a feature branch, opening a pull request, reviewing the plan, merging, approving, and finally watching your infrastructure get created automatically in AWS.

Sometimes you want to run your pipeline without making a code change — this video shows you how to manually trigger plan, apply, or destroy directly from GitHub's interface, giving you full control whenever you need it.

A short recap of everything this section covered — from GitHub Actions basics, to secrets and approvals, to running and destroying infrastructure safely through automation. A good refresher before moving into the next module.

With infrastructure now provisioned, this video previews what's next — getting your empty EKS cluster ready for real workloads by installing ArgoCD (for deployments), External Secret Operator (for pulling secrets), and the AWS Load Balancer Controller (for routing traffic).

Learn how to connect your local computer to the EKS cluster for the first time using kubectl, then install the AWS Load Balancer Controller — the component that will let your applications be reached from the internet later on.

Our cluster runs into a resource crunch trying to install everything on too few nodes. This video shows how to safely increase the number and size of your EKS nodes using the same pull-request-and-approve pipeline you built earlier — just like you would in a real production environment.

Install the External Secret Operator, which will later let your applications securely pull passwords and secrets from AWS Secrets Manager. Then log into ArgoCD's dashboard for the first time and get a first look at the tool that will manage all your deployments.

Connect ArgoCD to your GitOps repository (where all deployment configuration lives) using a GitHub access token, then create an ArgoCD "project" — a container that defines which repositories, clusters, and namespaces your applications are allowed to use.

A hands-on walkthrough of generating a GitHub access token, creating the secret ArgoCD needs to read your repository, and applying the project configuration so it shows up correctly inside the ArgoCD dashboard.

Finish configuring the External Secret Operator by creating the namespace, permissions, and secret definitions needed to pull your database and application credentials from AWS Secrets Manager directly into your Kubernetes cluster — no manual copying required.

Before moving to the next section, this video shows the correct order to safely tear down everything created so far — secrets, ArgoCD, load balancer, and finally the infrastructure itself — helping you avoid unnecessary AWS costs between sessions.

With our cluster ready, this video previews how we'll take the front-end application (Pharma UI) and prepare it for deployment — creating a Docker file, setting up branch protection, adding secrets, and building a complete CI/CD pipeline using GitHub Actions.

Learn how to write a Dockerfile for a real Node.js front-end application using a multi-stage build — one stage to build the code, and a second lightweight stage to serve it using Nginx. You'll also test the image locally before deploying it anywhere.

Set up branch protection on the front-end repository and create a "develop" branch for ongoing work. This video also explains the full real-world promotion strategy — how code moves safely from a feature branch, to development, to QA, and finally to production.

Your pipeline needs permission to update files in your GitOps repository — this video shows you how to create a separate, secure access token specifically for that purpose, following the best practice of giving each tool only the access it truly needs.

Learn how to connect your project to SonarCloud, a free tool that automatically checks your code for quality issues and security problems. This video walks through creating an account, connecting your repository, and generating the values your pipeline will need.

With all the required tokens and keys collected, this video shows exactly where and how to add them as secrets and variables inside your GitHub repository, so your pipeline can use them securely when it runs.

Build the actual pipeline file for the front-end application — one that runs code quality checks and tests on every pull request, and additionally builds a Docker image, scans it for security issues, and pushes it to AWS once code is merged.

Learn how to promote a tested image from one environment to the next without rebuilding it — this video creates two extra pipeline files that safely move your application from development to QA, and from QA to production.

Watch the complete front-end pipeline run for the very first time, step by step — and learn how to read and understand a failure when one of the steps doesn't succeed, an essential real-world troubleshooting skill.

This video previews Module 5 — creating the GitOps repository that will hold everything needed to deploy your applications, including folder structure, ArgoCD configuration, database setup files, and the Helm charts we'll build in this section.

First, deploy the front-end application using plain Kubernetes YAML files (deployment, service, ingress, and more) to understand exactly what's needed. Then see why this approach becomes difficult to manage once you have many microservices and environments — setting up why Helm charts are the better solution.

Learn how to build one reusable Helm chart that can be used for every microservice in the project — front-end and back-end alike — instead of repeating the same Kubernetes files over and over. You'll also create the first environment-specific values file to customize it.

A quick correction video — clarifying which GitHub tag to use for this module's code, after an earlier numbering mix-up, so you download the right version without confusion.

Create the ArgoCD "Application" file that tells ArgoCD exactly where to find your code, which values to use, and where to deploy it. This also covers the automatic sync settings that keep your cluster always matching what's in GitHub.

A handy reference for whenever you need to recreate your environment — run Terraform through the pipeline to rebuild your infrastructure, troubleshoot a real "resource already exists" error along the way, then run the three bootstrap scripts to reinstall the Load Balancer Controller, ArgoCD, and External Secret Operator, getting your cluster back to a ready state.

After five modules of setup, this is where things finally come together. This video previews the steps to make your very first real deployment — validating your cluster, initializing the database, running the CI pipeline, and deploying the front-end application through ArgoCD.

Before deploying anything, double-check that everything built so far actually works — the cluster, load balancer, ArgoCD, and External Secret Operator. Then connect to your database and create the schemas your application needs to store data.

Trigger your front-end pipeline for real and watch it run from start to finish — code quality checks, tests, building a Docker image, and pushing it to AWS — then confirm the new image is correctly picked up and ready for deployment.

See your application actually deployed and running on Kubernetes for the first time. This video also covers a real troubleshooting scenario — fixing a missing dependency issue — before successfully accessing the live front-end through your browser.

With the front-end fully working, this video previews Module 7 — bringing the eight backend microservices to life, including Docker files, reusable pipelines, values files, secrets, and finally testing the complete backend end to end.

Learn about the eight backend microservices and the important role the API gateway plays in connecting them. Then create Docker files for all of them — seven Java-based services and one Node.js service — using a helper script to save time.

Instead of writing eight separate pipelines, learn how to create reusable, shared workflow files for Java and Node.js services. Each microservice then uses a small file that calls these shared workflows — a smart way to avoid repeating the same pipeline code many times over.

Using the same shared Helm chart from Module 5, create a values file and an ArgoCD application file for each backend microservice — customizing only what's different (like image name and environment variables) for each one.

Prepare the backend repository the same way we did for the front-end — connect it to SonarCloud for code quality checks, add the required secrets and variables, protect the main branch, and create a develop branch for ongoing work.

Deploy ArgoCD applications for all eight backend microservices at once using an automation script. Since no Docker images exist yet, these deployments will initially fail — a good learning moment before the pipeline creates the actual images in the next video.

Test the entire backend pipeline end to end using one microservice as a proof of concept — from opening a pull request, to merging, to a Docker image being built and automatically deployed by ArgoCD — confirming everything works before rolling it out to the rest.

The big moment — scale up your cluster, connect the front-end to the backend, and deploy all remaining microservices. By the end, you'll successfully log into the complete GenPharma application with every service running and healthy.

With the application fully running in development, this video explains what comes next — how a tested image moves from dev to QA to production through approvals, and how to safely roll back to a previous version if something goes wrong.

Prepare the files needed to deploy the front-end application to a QA environment — creating a QA-specific values file and ArgoCD application file, mostly copied from the dev versions with a few key changes like namespace and hostname.

See the real image promotion process in action — running a manual workflow that takes the tested image from dev, opens a pull request to update QA, and lets ArgoCD automatically deploy it once approved. Includes real troubleshooting along the way.

Learn how easy it is to create a brand-new environment, like QA, once your infrastructure is built with reusable Terraform modules — just copy a folder and adjust a few values, instead of writing everything again from scratch.

Learn the correct, safe order to delete everything you've built — following a documented runbook to remove ArgoCD applications, load balancers, Helm installs, namespaces, and container images before finally destroying the infrastructure with Terraform.